idnits 2.17.1 draft-irtf-icnrg-ccninfo-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 8, 2019) is 1744 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 1384 -- Looks like a reference, but probably isn't: '-n' on line 1384 -- Looks like a reference, but probably isn't: '-o' on line 1384 -- Obsolete informational reference (is this intentional?): RFC 1393 (ref. '7') (Obsoleted by RFC 6814) == Outdated reference: A later version (-02) exists of draft-li-icnrg-hopauth-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group H. Asaeda 3 Internet-Draft A. Ooka 4 Intended status: Experimental NICT 5 Expires: January 9, 2020 X. Shao 6 Kitami Institute of Technology 7 July 8, 2019 9 CCNinfo: Discovering Content and Network Information in Content-Centric 10 Networks 11 draft-irtf-icnrg-ccninfo-02 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 January 9, 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . 21 72 5.1. User and Neighbor Verification . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . . . . 25 84 6.6. No Space . . . . . . . . . . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . 26 92 7.3. Access Control . . . . . . . . . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . . . . . . . . 27 99 8.6. Cache Hit Probability . . . . . . . . . . . . . . . . . . 27 100 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 101 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 102 10.1. Policy-Based Information Provisioning for Request . . . 27 103 10.2. Filtering of CCNinfo Users Located in Invalid Networks . 28 104 10.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 28 105 10.4. Characteristics of Content . . . . . . . . . . . . . . . 28 106 10.5. Longer or Shorter CCNinfo Reply Timeout . . . . . . . . 28 107 10.6. Limiting Request Rates . . . . . . . . . . . . . . . . . 29 108 10.7. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 29 109 10.8. Adjacency Verification . . . . . . . . . . . . . . . . . 29 110 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 111 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 112 12.1. Normative References . . . . . . . . . . . . . . . . . . 29 113 12.2. Informative References . . . . . . . . . . . . . . . . . 30 114 Appendix A. ccninfo Command and Options . . . . . . . . . . . . 30 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 117 1. Introduction 119 In Content-Centric Networks (CCN), publishers provide content through 120 the network, and receivers retrieve content by name. In this network 121 architecture, routers forward content requests by means of their 122 Forwarding Information Bases (FIBs), which are populated by name- 123 based routing protocols. CCN also enables receivers to retrieve 124 content from an in-network cache. 126 In CCN, while consumers do not generally need to know which content 127 forwarder is transmitting the content to them, operators and 128 developers may want to identify the content forwarder and observe the 129 routing path information per name prefix for troubleshooting or 130 investigating the network conditions. 132 Traceroute [7] is a useful tool for discovering the routing 133 conditions in IP networks as it provides intermediate router 134 addresses along the path between source and destination and the 135 Round-Trip Time (RTT) for the path. However, this IP-based network 136 tool cannot trace the name prefix paths used in CCN. Moreover, such 137 IP-based network tool does not obtain the states of the in-network 138 cache to be discovered. 140 This document describes the specification of "CCNinfo", an active 141 networking tool for discovering the path and content caching 142 information in CCN. CCNinfo is designed based on the work previously 143 published in [6]. 145 CCNinfo can be implemented with the ccninfo user command and the 146 forwarding function implementation on a content forwarder (e.g., 147 router). The CCNinfo user (e.g., consumer) invokes the ccninfo 148 command (described in Appendix A) with the name prefix of the 149 content. The ccninfo command initiates the "Request" message 150 (described in Section 3.1). The Request message, for example, 151 obtains routing path and cache information. When an appropriate 152 adjacent neighbor router receives the Request message, it retrieves 153 cache information. If the router is not the content forwarder for 154 the request, it inserts its "Report" block (described in 155 Section 3.1.2) into the Request message and forwards the Request 156 message to its upstream neighbor router(s) decided by its FIB. These 157 two message types, Request and Reply messages, are encoded in the 158 CCNx TLV format [1]. 160 In this way, the Request message is forwarded by routers toward the 161 content publisher, and the Report record is inserted by each 162 intermediate router. When the Request message reaches the content 163 forwarder (i.e., a router who can forward the specified cache or 164 content), the content forwarder forms the "Reply" message (described 165 in Section 3.2) and sends it to the downstream neighbor router. The 166 Reply message is forwarded back toward the user in a hop-by-hop 167 manner. This request-reply message flow, walking up the tree from a 168 consumer toward a publisher, is similar to the behavior of the IP 169 multicast traceroute facility [8]. 171 CCNinfo supports multipath forwarding. The Request messages can be 172 forwarded to multiple neighbor routers. When the Request messages 173 forwarded to multiple routers, the different Reply messages will be 174 forwarded from different routers or publisher. 176 1. Request 2. Request 3. Request 177 (+U) (U+A) (U+A+B) 178 +----+ +----+ +----+ 179 | | | | | | 180 | v | v | v 181 +--------+ +--------+ +--------+ +--------+ +---------+ 182 | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| 183 | user | | A | | B | | C | | | 184 +--------+ +--------+ +--------+ +--------+ +---------+ 185 \ 186 \ +-------+ 187 3. Request \ | Cache | 188 (U+A+B) \ +---------+ | 189 v| Caching |----+ 190 | router | 191 +---------+ 193 Figure 1: Request messages forwarded by consumer and routers. 194 CCNinfo user and routers (i.e., Router A,B,C) insert their own Report 195 blocks into the Request message and forward the message toward the 196 content forwarder (i.e., caching router and publisher) 198 3. Reply(P) 2. Reply(P) 1. Reply(P) 199 +----+ +----+ +----+ 200 | | | | | | 201 v | v | v | 202 +--------+ +--------+ +--------+ +--------+ +---------+ 203 | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| 204 | user | | A | | B | | C | | | 205 +--------+ +--------+ +--------+ +--------+ +---------+ 206 ^ 207 \ +-------+ 208 1. Reply(C) \ | Cache | 209 \ +---------+ | 210 \| Caching |----+ 211 | router | 212 +---------+ 214 Figure 2: Default behavior. Reply messages forwarded by routers. 215 Each router forwards the Reply message along its PIT entry, and 216 finally the CCNinfo user receives a Reply message from Router C, 217 which is the first-hop router for Publisher. Another Reply message 218 from Caching router is discarded at Router B as the corresponding 219 Reply message was already forwarded. 221 3. Reply(C) 2. Reply(C) 222 3. Reply(P) 2. Reply(P) 1. Reply(P) 223 +----+ +----+ +----+ 224 | | | | | | 225 v | v | v | 226 +--------+ +--------+ +--------+ +--------+ +---------+ 227 | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| 228 | user | | A | | B | | C | | | 229 +--------+ +--------+ +--------+ +--------+ +---------+ 230 ^ 231 \ +-------+ 232 1. Reply(C) \ | Cache | 233 \ +---------+ | 234 \| Caching |----+ 235 | router | 236 +---------+ 238 Figure 3: Full discovery request. Reply messages forwarded by 239 publisher and routers. Each router forwards the Reply message along 240 its PIT entry, and finally the CCNinfo user receives two Reply 241 messages: one from the first-hop router and the other from the 242 caching router. 244 CCNinfo facilitates the tracing of a routing path and provides: 1) 245 the RTT between content forwarder (i.e., caching router or first-hop 246 router) and consumer, 2) the states of in-network cache per name 247 prefix, and 3) the routing path information per name prefix. 249 In addition, CCNinfo identifies the states of the cache, such as the 250 following metrics for Content Store (CS) in the content forwarder: 1) 251 size of the cached content objects, 2) number of the cached content 252 objects, 3) number of the accesses (i.e., received Interests) per 253 content, and 4) elapsed cache time and remain cache lifetime of 254 content. 256 Furthermore, CCNinfo implements policy-based information provisioning 257 that enables administrators to "hide" secure or private information, 258 but does not disrupt the forwarding of messages. This policy-based 259 information provisioning reduces the deployment barrier faced by 260 operators in installing and running CCNinfo on their routers. 262 2. Terminology 264 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 265 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 266 and "OPTIONAL" are to be interpreted as described in RFC 2119 [3], 267 and indicate requirement levels for compliant CCNinfo 268 implementations. 270 2.1. Definitions 272 Since CCNinfo requests flow in the opposite direction to the data 273 flow, we refer to "upstream" and "downstream" with respect to data, 274 unless explicitly specified. 276 Router 277 It is a router facilitating CCN-based content retrieval in the 278 path between consumer and publisher. 280 Scheme name 281 It indicates a URI and protocol. This document only considers 282 "ccn:/" as the scheme name. 284 Prefix name 285 A prefix name, which is defined in [2], is a name that does not 286 uniquely identify a single content object, but rather a namespace 287 or prefix of an existing content object name. 289 Exact name 290 An exact name, which is defined in [2], is one which uniquely 291 identifies the name of a content object. 293 Node 294 It is a router, publisher, or consumer. 296 Content forwarder 297 It is either a caching router or a first-hop router that forwards 298 content objects to consumers. 300 CCNinfo user 301 It is a node that invokes the ccninfo command and initiates the 302 CCNinfo Request. 304 Incoming face 305 The face on which data is expected to arrive from the specified 306 name prefix. 308 Outgoing face 309 The face to which data from the publisher or router is expected to 310 transmit for the specified name prefix. It is also the face on 311 which the Request messages are received. 313 Upstream router 314 The router, connecting to the Incoming face of a router, which is 315 responsible for forwarding data for the specified name prefix to 316 the router. 318 First-hop router (FHR) 319 The router that is directly connected to the publisher. 321 Last-hop router (LHR) 322 The router that is directly connected to the consumers. 324 3. CCNinfo Message Formats 326 CCNinfo uses two message types: Request and Reply. Both messages are 327 encoded in the CCNx TLV format ([1], Figure 4). The Request message 328 consists of a fixed header, Request block TLV Figure 8, and Report 329 block TLV(s) Figure 11. The Reply message consists of a fixed 330 header, Request block TLV, Report block TLV(s), and Reply block/sub- 331 block TLV(s) Figure 14. 333 1 2 3 334 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 335 +---------------+---------------+---------------+---------------+ 336 | Version | PacketType | PacketLength | 337 +---------------+---------------+---------------+---------------+ 338 | PacketType specific fields | HeaderLength | 339 +---------------+---------------+---------------+---------------+ 340 / Optional Hop-by-hop header TLVs / 341 +---------------+---------------+---------------+---------------+ 342 / PacketPayload TLVs / 343 +---------------+---------------+---------------+---------------+ 344 / Optional CCNx ValidationAlgorithm TLV / 345 +---------------+---------------+---------------+---------------+ 346 / Optional CCNx ValidationPayload TLV (ValidationAlg required) / 347 +---------------+---------------+---------------+---------------+ 349 Figure 4: Packet format [1] 351 The Request and Reply Type values in the fixed header are PT_REQUEST 352 and PT_REPLY, respectively (Figure 5). These messages are forwarded 353 in a hop-by-hop manner. When the Request message reaches the content 354 forwarder, the content forwarder turns the Request message into a 355 Reply message by changing the Type field value in the fixed header 356 from PT_REQUEST to PT_REPLY and forwards back toward the node that 357 has initiated the Request message. 359 Code Type name 360 ======== ===================== 361 %x00 PT_INTEREST [1] 362 %x01 PT_CONTENT [1] 363 %x02 PT_RETURN [1] 364 %x03 PT_REQUEST 365 %x04 PT_REPLY 367 Figure 5: Packet Type Namespace 369 The CCNinfo Request and Reply messages MUST begin with a fixed header 370 with either a Request or Reply type value to specify whether it is a 371 Request message or Reply message. Following a fixed header, there 372 can be a sequence of optional hop-by-hop header TLV(s) for a Request 373 message. In the case of a Request message, it is followed by a 374 sequence of Report blocks, each from a router on the path toward the 375 publisher or caching router. 377 At the beginning of PacketPayload TLVs, one top-level TLV type, 378 T_DISCOVERY (Figure 6), exists at the outermost level of a CCNx 379 protocol message. This TLV indicates that the Name segment TLV(s) 380 and Reply block TLV(s) would follow in the Request or Reply message. 382 Code Type name 383 ============= ========================= 384 %x0000 Reserved [1] 385 %x0001 T_INTEREST [1] 386 %x0002 T_OBJECT [1] 387 %x0003 T_VALIDATION_ALG [1] 388 %x0004 T_VALIDATION_PAYLOAD [1] 389 %x0005 T_DISCOVERY 391 Figure 6: Top-Level Type Namespace 393 3.1. Request Message 395 When a CCNinfo user initiates a discovery request (e.g., by ccninfo 396 command described in Appendix A), a CCNinfo Request message is 397 created and forwarded to its upstream router through the Incoming 398 face(s) determined by its FIB. 400 The Request message format is as shown in Figure 7. It consists of a 401 fixed header, Request block TLV (Figure 8), Report block TLV(s) 402 (Figure 11), and Name TLV. The Type value of Top-Level type 403 namespace is T_DISCOVERY (Figure 6). The Type value for the Report 404 message is PT_REQUEST. 406 1 2 3 407 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 408 +---------------+---------------+---------------+---------------+ 409 | Version | PacketType | PacketLength | 410 +---------------+---------------+---------------+---------------+ 411 | HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength | 412 +===============+===============+===============+===============+ 413 | | 414 + Request block TLV + 415 | | 416 +---------------+---------------+---------------+---------------+ 417 / Report block TLV 1 / 418 +---------------+---------------+---------------+---------------+ 419 / Report block TLV 2 / 420 +---------------+---------------+---------------+---------------+ 421 / . / 422 / . / 423 +---------------+---------------+---------------+---------------+ 424 / Report block TLV n / 425 +===============+===============+===============+===============+ 426 | T_DISCOVERY | MessageLength | 427 +---------------+---------------+---------------+---------------+ 428 | T_NAME | Length | 429 +---------------+---------------+---------------+---------------+ 430 / Name segment TLVs (name prefix specified by ccninfo command) / 431 +---------------+---------------+---------------+---------------+ 433 Figure 7: Request message consists of a fixed header, Request block 434 TLV, Report block TLV(s), and Name TLV 436 HopLimit: 8 bits 438 HopLimit is a counter that is decremented with each hop whenever a 439 Request packet is forwarded. It limits the distance a Request may 440 travel on the network. 442 ReturnCode: 8 bits 444 ReturnCode is used for the Reply message. This value is replaced 445 by the content forwarder when the Request message is returned as 446 the Reply message (see Section 3.2). Until then, this field MUST 447 be transmitted as zeros and ignored on receipt. 449 Value Name Description 450 ----- --------------- ---------------------------------------------- 451 %x00 NO_ERROR No error 452 %x01 WRONG_IF CCNinfo Request arrived on an interface 453 to which this router would not forward for 454 the specified name/function toward the 455 publisher. 456 %x02 INVALID_REQUEST Invalid CCNinfo Request is received. 457 %x03 NO_ROUTE This router has no route for the name prefix 458 and no way to determine a potential route. 459 %x04 NO_INFO This router has no cache information for the 460 specified name prefix. 461 %x05 NO_SPACE There was not enough room to insert another 462 Report block in the packet. 463 %x06 INFO_HIDDEN Information is hidden from this discovery 464 because of some policy. 465 %x0E ADMIN_PROHIB CCNinfo Request is administratively 466 prohibited. 467 %x0F UNKNOWN_REQUEST This router does not support/recognize the 468 Request message. 469 %x80 FATAL_ERROR A fatal error is one where the router may 470 know the upstream router but cannot forward 471 the message to it. 473 Reserved (MBZ): 8 bits 475 The reserved fields in the Value field MUST be transmitted as 476 zeros and ignored on receipt. 478 3.1.1. Request Block 480 When a CCNinfo user transmits the Request message, it MUST insert the 481 Request block TLV (Figure 8) and the Report block TLV (Figure 11) of 482 its own to the Request message before sending it through the Incoming 483 face(s). 485 1 2 3 486 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 487 +---------------+---------------+---------------+---------------+ 488 | T_DISC_REQ | Length | 489 +---------------+---------------+----+----------+---------+-+-+-+ 490 | Request ID |SHC | Flags |F|O|C| 491 +---------------+---------------+----+----------+---------+-+-+-+ 492 | Request Arrival Time | 493 +---------------+---------------+---------------+---------------+ 494 / Node Identifier / 495 +---------------+---------------+---------------+---------------+ 497 Figure 8: Request block TLV (hop-by-hop header) 499 Code Type name 500 ============= ========================= 501 %x0000 Reserved [1] 502 %x0001 T_INTLIFE [1] 503 %x0002 T_CACHETIME [1] 504 %x0003 T_MSGHASH [1] 505 %x0004-%x0007 Reserved [1] 506 %x0008 T_DISC_REQ 507 %x0009 T_DISC_REPORT 508 %x0FFE T_PAD [1] 509 %x0FFF T_ORG [1] 510 %x1000-%x1FFF Reserved [1] 512 Figure 9: Hop-by-Hop Type Namespace 514 Type: 16 bits 516 Format of the Value field. For the single Request block TLV, the 517 type value MUST be T_DISC_REQ. For all the available types for 518 hop-by-hop type namespace, please see Figure 9. 520 Length: 16 bits 522 Length of Value field in octets. 524 Request ID: 16 bits 526 This field is used as a unique identifier for this CCNinfo Request 527 so that duplicate or delayed Reply messages can be detected. 529 SHC (Skip Hop Count): 4 bits 530 Number of skipped routers for a Request. This value MUST be lower 531 than the value of HopLimit at the fixed header. 533 Flags: 12 bits 535 Flags field is used to indicate the types of the content or path 536 discoveries. Currently, as shown in Figure 10, three bits, "C", 537 "O", and "F", are assigned, and the other 9 bits are reserved 538 (MBZ) for the future use. These flags are set by CCNinfo users 539 when they initiate Requests (see Appendix A), and routers that 540 receive the Requests deal with the flags and change the behaviors 541 (see Section 5 for details). Flag values defined in this Flags 542 field will match corresponding Reply sub-blocks. 544 Flag Value Description 545 ----- ----- ---------------------------------------------------- 546 C 0 Path discovery (i.e., no cache information retried) 547 C 1 Cache information retrieval (default) 548 O 0 Request to any content forwarder (default) 549 O 1 Publisher reachability (i.e., only FHR can reply). 550 Type of Reply sub-block will be T_DISC_CONTENT_OWNER 551 F 0 Request based on FIB's strategy (default) 552 F 1 Full discovery request. Request to multiple upstream 553 routers simultaneously 555 Figure 10: Codes and types specified in Flags field 557 3.1.2. Report Block 559 A CCNinfo user and each upstream router along the path would insert 560 its own Report block TLV without changing the Type field of the fixed 561 header of the Request message until one of these routers is ready to 562 send a Reply. In the Report block TLV (Figure 11), the Request 563 Arrival Time and the Node Identifier MUST be inserted. 565 1 2 3 566 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 567 +---------------+---------------+---------------+---------------+ 568 | T_DISC_REPORT | Length | 569 +---------------+---------------+---------------+---------------+ 570 | Request Arrival Time | 571 +---------------+---------------+---------------+---------------+ 572 / Node Identifier / 573 +---------------+---------------+---------------+---------------+ 575 Figure 11: Report block TLV (hop-by-hop header) 577 Type: 16 bits 578 Format of the Value field. For the Report block TLV, the type 579 value(s) MUST be T_DISC_REPORT in the current specification. 581 Length: 16 bits 583 Length of Value field in octets. 585 Request Arrival Time: 32 bits 587 The Request Arrival Time is a 32-bit NTP timestamp specifying the 588 arrival time of the CCNinfo Request packet at this router. The 589 32-bit form of an NTP timestamp consists of the middle 32 bits of 590 the full 64-bit form; that is, the low 16 bits of the integer part 591 and the high 16 bits of the fractional part. 593 The following formula converts from a UNIX timeval to a 32-bit NTP 594 timestamp: 596 request_arrival_time 597 = ((tv.tv_sec + 32384) << 16) + ((tv.tv_nsec << 7) / 1953125) 599 The constant 32384 is the number of seconds from Jan 1, 1900 to 600 Jan 1, 1970 truncated to 16 bits. ((tv.tv_nsec << 7) / 1953125) 601 is a reduction of ((tv.tv_nsec / 1000000000) << 16). 603 Note that it is RECOMMENDED that all the routers on the path to 604 have synchronized clocks; however, if they do not have 605 synchronized clocks, CCNinfo measures one-way latency. 607 Node Identifier: variable length 609 This field specifies the CCNinfo user or the router identifier 610 (e.g., IPv4 address) of the Incoming face on which packets from 611 the publisher are expected to arrive, or all-zeros if unknown or 612 unnumbered. Since we may not always rely on the IP addressing 613 architecture, it would be necessary to define the identifier 614 uniqueness (e.g., by specifying the protocol family) for this 615 field. However, defining such uniqueness is out of scope of this 616 document. Potentially, this field may be defined as a new TLV 617 based on the CCNx TLV format [1]. 619 3.2. Reply Message 621 When a content forwarder receives a CCNinfo Request message from the 622 appropriate adjacent neighbor router, it would insert a Reply block 623 TLV and Reply sub-block TLV(s) of its own to the Request message and 624 turn the Request into the Reply by changing the Type field of the 625 fixed header of the Request message from PT_REQUEST to PT_REPLY. The 626 Reply message (see Figure 12) would then be forwarded back toward the 627 CCNinfo user in a hop-by-hop manner. 629 1 2 3 630 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 631 +---------------+---------------+---------------+---------------+ 632 | Version | PacketType | PacketLength | 633 +---------------+---------------+-------------+-+---------------+ 634 | HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength | 635 +===============+===============+=============+=+===============+ 636 | | 637 + Request block TLV + 638 | | 639 +---------------+---------------+---------------+---------------+ 640 / . / 641 / . / 642 / n Report block TLVs / 643 / . / 644 / . / 645 +===============+===============+===============+===============+ 646 | T_DISCOVERY | MessageLength | 647 +---------------+---------------+---------------+---------------+ 648 | T_NAME | Length | 649 +---------------+---------------+---------------+---------------+ 650 / Name segment TLVs (name prefix specified by ccninfo command) / 651 +---------------+---------------+---------------+---------------+ 652 / Reply block TLV / 653 +---------------+---------------+---------------+---------------+ 654 / Reply sub-block TLV 1 / 655 +---------------+---------------+---------------+---------------+ 656 / Reply sub-block TLV 2 / 657 +---------------+---------------+---------------+---------------+ 658 / . / 659 / . / 660 +---------------+---------------+---------------+---------------+ 661 / Reply sub-block TLV k / 662 +---------------+---------------+---------------+---------------+ 664 Figure 12: Reply message consists of a fixed header, Request block 665 TLV, Report block TLV(s), Name TLV, and Reply block/sub-block TLV(s) 666 Code Type name 667 ============== =================== 668 %x0000 T_NAME [1] 669 %x0001 T_PAYLOAD [1] 670 %x0002 T_KEYIDRESTR [1] 671 %x0003 T_OBJHASHRESTR [1] 672 %x0005 T_PAYLDTYPE [1] 673 %x0006 T_EXPIRY [1] 674 %x0007 T_DISC_REPLY 675 %x0008-%x0012 Reserved [1] 676 %x0FFE T_PAD [1] 677 %x0FFF T_ORG [1] 678 %x1000-%x1FFF Reserved [1] 680 Figure 13: CCNx Message Type Namespace 682 3.2.1. Reply Block 684 The Reply block TLV is an envelope for Reply sub-block TLV(s) 685 (explained in Section 3.2.1.1). 687 1 2 3 688 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 689 +---------------+---------------+---------------+---------------+ 690 | T_DISC_REPLY | Length | 691 +---------------+---------------+---------------+---------------+ 693 Figure 14: Reply block TLV (packet payload) 695 Type: 16 bits 697 Format of the Value field. For the Reply block TLV, the type 698 value MUST be T_DISC_REPLY in the current specification. 700 Length: 16 bits 702 Length of Value field in octets. This length is a total length of 703 Reply sub-block(s). 705 3.2.1.1. Reply Sub-Block 707 In addition to the Reply block, a router on the traced path will add 708 one or multiple Reply sub-blocks followed by the Reply block before 709 sending the Reply to its neighbor router. 711 The Reply sub-block is flexible for various purposes. For instance, 712 operators and developers may want to obtain various characteristics 713 of content such as content's ownership and copyright, or other cache 714 states and conditions. In this document, Reply sub-block TLVs for 715 T_DISC_CONTENT and T_DISC_CONTENT_OWNER (Figure 15) are defined; 716 other Reply sub-block TLVs will be defined in separate document(s). 718 1 2 3 719 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 720 +---------------+---------------+---------------+---------------+ 721 | Type | Length | 722 +---------------+---------------+---------------+---------------+ 723 | Object Size | 724 +---------------+---------------+---------------+---------------+ 725 | Object Count | 726 +---------------+---------------+---------------+---------------+ 727 | # Received Interest | 728 +---------------+---------------+---------------+---------------+ 729 | First Seqnum | 730 +---------------+---------------+---------------+---------------+ 731 | Last Seqnum | 732 +---------------+---------------+---------------+---------------+ 733 | Elapsed Cache Time | 734 +---------------+---------------+---------------+---------------+ 735 | Remain Cache Lifetime | 736 +---------------+---------------+---------------+---------------+ 737 | T_NAME | Length | 738 +---------------+---------------+---------------+---------------+ 739 / Name Segment TLVs / 740 +---------------+---------------+---------------+---------------+ 742 Figure 15: Reply sub-block TLV for T_DISC_CONTENT and 743 T_DISC_CONTENT_OWNER (packet payload) 745 Code Type name 746 ============= =========================== 747 %x0000 T_DISC_CONTENT 748 %x0001 T_DISC_CONTENT_OWNER 749 %x0FFF T_ORG 750 %x1000-%x1FFF Reserved (Experimental Use) 752 Figure 16: CCNinfo Reply Type Namespace 754 Type: 16 bits 756 Format of the Value field. For the Reply sub-block TLV, the type 757 value MUST be one of the type value defined in the CCNinfo Reply 758 Type Namespace (Figure 16). T_DISC_CONTENT is specified when the 759 cache information is replied from a caching router. 760 T_DISC_CONTENT_OWNER is specified when the content information is 761 replied from a FHR attached to a publisher. 763 Length: 16 bits 765 Length of Value field in octets. 767 Object Size: 32 bits 769 The total size (KB) of the unexpired content objects. Note that 770 the maximum size expressed by 32 bit field is about 4.29 TB. This 771 value MAY be null because the router may not know the value or 772 cannot report the value due to its policy. If the cache is 773 refreshed after reboot, the counter MUST be refreshed (i.e., MUST 774 set to 0). If the cache remains after reboot, the counter MUST 775 NOT be refreshed (i.e., MUST kept as is). 777 Object Count: 32 bits 779 The number of the unexpired content objects. Note that the 780 maximum count expressed by 32 bit field is about 4.29 billion. 781 This value MAY be null because the router may not know the value 782 or cannot report the value due to its policy. If the cache is 783 refreshed after reboot, the counter MUST be refreshed (i.e., MUST 784 set to 0). If the cache remains after reboot, the counter MUST 785 NOT be refreshed (i.e., MUST kept as is). 787 # Received Interest: 32 bits 789 The total number of the received Interest messages to retrieve the 790 cached content objects. 792 First Seqnum: 32 bits 794 The first sequential number of the unexpired content objects. 795 This value MAY be null because the router may not know the value 796 or cannot report the value due to its policy. 798 Last Seqnum: 32 bits 800 The last sequential number of the unexpired content objects. 801 Above First Seqnum and this Last Seqnum do not guarantee the 802 consecutiveness of the cached content objects. This value MAY be 803 null because the router may not know the value or cannot report 804 the value due to its policy. 806 Elapsed Cache Time: 32 bits 808 The elapsed time (seconds) after the oldest content object of the 809 content is cached. This value MAY be null because the router may 810 not know the value or cannot report the value due to its policy. 812 Remain Cache Lifetime: 32 bits 814 The lifetime (seconds) of a content object, which is removed first 815 among the cached content objects. This value MAY be null because 816 the router may not know the value or cannot report the value due 817 to its policy. 819 Specification of the Name TLV (whose type value is T_NAME) and the 820 Name Segment TLVs are described in [1], and CCNinfo follows that 821 specification. CCNinfo also allows to specify the content name 822 either with a prefix name (such as "ccn:/news/today") or an exact 823 name (such as "ccn:/news/today/Chunk=10"). When a CCNinfo user 824 specifies a prefix name, s/he will obtain the summary information of 825 the matched content objects in the content forwarder. On the other 826 hand, when a CCNinfo user specifies an exact name, s/he will obtain 827 only about the specified content object in the content forwarder. 829 4. CCNinfo User Behavior 831 4.1. Sending CCNinfo Request 833 The CCNinfo user's program (e.g., ccninfo command) enables user to 834 obtain both the routing path information and in-network cache 835 information in a same time. 837 A CCNinfo user initiates a CCNinfo Request by sending the Request 838 message to the adjacent neighbor router(s) of interest. As a typical 839 example, a CCNinfo user invokes the ccninfo command (detailed in 840 Appendix A) that forms a Request message and sends it to the user's 841 adjacent neighbor router(s). 843 When the CCNinfo user's program initiates a Request message, it MUST 844 insert the necessary values, the "Request ID" (in the Request block) 845 and the "Node Identifier" (in the Report block), in the Request and 846 Report blocks. The Request ID MUST be unique for the CCNinfo user 847 until s/he receives the corresponding Reply message(s) or times out 848 the Request. 850 Because of some policy, a router needs to validate CCNinfo Requests 851 (whether it accepts the Request or not) especially when the router 852 receives the "full discovery request" (see Section 5.3). To support 853 this requirement, the CCNinfo user's program MAY require appending 854 the user's signature into the CCNx ValidationPayload TLV. The router 855 then forwards the Request message or reply the Reply message whenever 856 it approves the Request. 858 After the CCNinfo user's program sends the Request message, until the 859 Reply times out or the expected numbers of Replies or a Reply message 860 having a non-zero ReturnCode in the fixed header is received, the 861 CCNinfo user's program MUST keep the following information; Request 862 ID and Flags specified in the Request block, Node Identifier and 863 Request Arrival Time specified in the Report block, and HopLimit 864 specified in the fixed header. 866 4.1.1. Routing Path Information 868 A CCNinfo user can send a CCNinfo Request for investigating routing 869 path information for the specified named content. By the Request, 870 the legitimate user can obtain; 1) identifiers (e.g., IP addresses) 871 of intermediate routers, 2) identifier of content forwarder, 3) 872 number of hops between content forwarder and consumer, and 4) RTT 873 between content forwarder and consumer, per name prefix. This 874 CCNinfo Request is terminated when it reaches the content forwarder. 876 4.1.2. In-Network Cache Information 878 A CCNinfo user can send a CCNinfo Request for investigating in- 879 network cache information. By the Request, the legitimate user can 880 obtain; 1) size of the cached content objects, 2) number of the 881 cached content objects, 3) number of the accesses (i.e., received 882 Interests) per content, and 4) lifetime and expiration time of the 883 cached content object, for Content Store (CS) in the content 884 forwarder. This CCNinfo Request is terminated when it reaches the 885 content forwarder. 887 4.2. Receiving CCNinfo Reply 889 A CCNinfo user's program will receive one or multiple CCNinfo Reply 890 messages from the adjacent neighbor router that has previously 891 received and forwarded the Request message(s). When the program 892 receives the Reply, it MUST compare the kept Request ID and Node 893 Identifier and the ones noted in the Request block TLV in the Reply. 894 If they do not match, the Reply message MUST be silently discarded. 896 If the number of the Report blocks in the received Reply is more than 897 the initial HopLimit value (which was inserted in the original 898 Request), the Reply MUST be silently ignored. 900 After the CCNinfo user has determined that s/he has traced the whole 901 path or as much as s/he can expect to, s/he might collect statistics 902 by waiting a timeout. Useful statistics provided by CCNinfo can be 903 seen in Section 8. 905 5. Router Behavior 907 5.1. User and Neighbor Verification 909 Upon receiving a CCNinfo Request message, a router MAY examine 910 whether the message comes from a valid CCNinfo user. If the router 911 recognizes that the Request sender's signature specified in the 912 Request is invalid, it terminates the Request as defined in 913 Section 6.3. 915 Upon receiving a CCNinfo Request/Reply message, a router MAY examine 916 whether the message comes from a valid adjacent neighbor node. If 917 the router recognizes that the Request/Reply sender is invalid, the 918 Request/Reply message MUST be silently ignored. See Section 10.8. 920 5.2. Receiving CCNinfo Request 922 5.2.1. Normal Processing 924 After the CCNinfo Request message verification, the router performs 925 the following steps. 927 1. The value of the "HopLimit" in the fixed header and the value of 928 the "SkipHopCount" in the Request block are counters that are 929 decremented with each hop. If the HopLimit value is zero, the 930 router terminates the Request as defined in Section 6.4. If the 931 SkipHopCount value is equal or more than the HopLimit value, the 932 router terminates the Request as defined in Section 6.3. 933 Otherwise, until the SkipHopCount value becomes zero, the router 934 forwards the Request message to the upstream router(s) without 935 adding its own Report block and without replying the Request. If 936 the router does not know the upstream router(s) for the specified 937 name prefix, it terminates the Request as defined in Section 6.4. 939 2. The router examines the Flags field (specified in Figure 10) in 940 the Request block of received CCNinfo Request. If the "C" flag 941 is set but the "O" flag is not set, that is categorized as the 942 "cache information discovery". If both the "C" and "O" flags are 943 not set, that is categorized as the "routing path information 944 discovery". If "O" flag is set, that is categorized as the 945 "publisher discovery". 947 3. If the Request is either the "cache information discovery" or the 948 "routing path information discovery", the router examines its FIB 949 and CS. If the router caches the specified content, it inserts 950 own Report block in the hop-by-hop header, and sends the Reply 951 message with own Reply block and sub-block(s) (in case of cache 952 information discovery) or sends the Reply message with own Reply 953 block without adding any Reply sub-block (in case of routing path 954 information discovery). If the router does not cache the 955 specified content but knows the upstream neighbor router(s) for 956 the specified name prefix, it inserts own Report block and 957 forwards the Request to the upstream neighbor(s). If the router 958 does not cache the specified content and does not know the 959 upstream neighbor router(s) for the specified name prefix, it 960 terminates the Request as defined in Section 6.4. 962 4. If the Request is the "publisher discovery", the router examines 963 whether it is the FHR for the requested content. If it is the 964 FHR, it sends the Reply message with own Report block and sub- 965 block. If the router is not the FHR but knows the upstream 966 neighbor router(s) for the specified name prefix, it adds the own 967 Report block and forwards the Request to the neighbor(s). If the 968 node is not the FHR and does not know the upstream neighbor 969 router(s) for the specified name prefix, it terminates the 970 Request as defined in Section 6.4. 972 5.3. Forwarding CCNinfo Request 974 When a router decides to forward a Request message with its Report 975 block to its upstream router(s), it specifies the Request Arrival 976 Time and Node Identifier in the Report block of the Request message. 977 The router then forwards the Request message upstream toward the 978 publisher or caching router based on the FIB entry. 980 When the router forwards the Request message, it MUST record the 981 Request ID, the F flag, and the Node Identifier specified in the 982 Request block at the corresponding PIT entry. The router can later 983 check the PIT entry to correctly forward back the Reply message(s). 984 (See below.) 986 CCNinfo supports multipath forwarding. The Request messages can be 987 forwarded to multiple neighbor routers. Some router may have 988 strategy for multipath forwarding; when it sends Interest messages to 989 multiple neighbor routers, it may delay or prioritize to send the 990 message to the upstream routers. The CCNinfo Request, as the 991 default, complies with such strategy; a CCNinfo user could trace the 992 actual forwarding path based on the forwarding strategy. 994 On the other hand, there may be the case that a CCNinfo user wants to 995 discover all potential forwarding paths based on routers' FIBs. The 996 "full discovery request" enables this function. If a CCNinfo user 997 sets the F flag in the Request block of the Request message (as seen 998 in Figure 10) to request the full discovery, the upstream routers 999 forward the Requests to the all multiple upstream routers based on 1000 the FIBs simultaneously. Then the CCNinfo user could trace the all 1001 potential forwarding paths. Note that some routers MAY ignore the 1002 full discovery request according to their policy. In that case, the 1003 router terminates the Request as defined in Section 6.10. 1005 When a CCNinfo user sets the F flag in the Request block of the 1006 Request message to request the full discovery, to receive the 1007 different Reply messages forwarded from different routers, PIT 1008 entries initiated by CCNinfo remain until the configured CCNinfo 1009 Reply Timeout (Section 7.1) passes. In other words, unlike the 1010 ordinary Interest-Data communications in CCN, if the router accepts 1011 the fill discovery request, the router SHOULD NOT remove the PIT 1012 entry created by the CCNinfo Request until the timeout value expires. 1014 CCNinfo Requests SHOULD NOT result in PIT aggregation in routers 1015 during the Request message transmission. On the other hand, CCNinfo 1016 Requests MAY result rate limit as described in Section 10.6. The 1017 router behavior looks similar but it is not PIT aggregation. 1019 5.4. Sending CCNinfo Reply 1021 When a router decides to send a Reply message to its downstream 1022 neighbor router or the CCNinfo user with NO_ERROR return code, it 1023 inserts a Report block having the Request Arrival Time and Node 1024 Identifier to the hop-by-hop TLV header of the Request message. And 1025 then the router inserts the corresponding Reply block with an 1026 appropriate type value (Figure 15) and Reply sub-block(s) to the 1027 payload. The router does not insert any Reply block/sub-block if 1028 there is an error. The router finally changes the Type field in the 1029 fixed header from PT_REQUEST to PT_REPLY and forwards the message 1030 back as the Reply toward the CCNinfo user in a hop-by-hop manner. 1032 If a router cannot continue the Request, it MUST put an appropriate 1033 ReturnCode in the Request message, change the Type field value in the 1034 fixed header from PT_REQUEST to PT_REPLY, and forward the Reply 1035 message back toward the CCNinfo user, to terminate the request. See 1036 Section 6. 1038 5.5. Forwarding CCNinfo Reply 1040 When a router receives a CCNinfo Reply whose Request ID and Node 1041 Identifier match the ones in the PIT entry and sent from a valid 1042 adjacent neighbor router, it forwards the CCNinfo Reply back toward 1043 the CCNinfo user. If the router does not receive the corresponding 1044 Reply within the [CCNinfo Reply Timeout] period, then it removes the 1045 corresponding PIT entry and terminates the trace. 1047 Flags field in the Request block TLV is used to indicate whether the 1048 router keeps the PIT entry during the CCNinfo Reply Timeout even 1049 after one or more corresponding Reply messages are forwarded. When 1050 the CCNinfo user does not set the F flag (i.e., "0"), the 1051 intermediate routers immediately remove the PIT entry whenever they 1052 forward the corresponding Reply message. When the CCNinfo user sets 1053 the F flag (i.e., "1"), which means the CCNinfo user chooses the 1054 "full discovery request", the intermediate routers keep the PIT entry 1055 within the [CCNinfo Reply Timeout] period. After this timeout, the 1056 PIT entry is removed. 1058 CCNinfo Replies MUST NOT be cached in routers upon the Reply message 1059 transmission. 1061 6. CCNinfo Termination 1063 When performing an expanding hop-by-hop trace, it is necessary to 1064 determine when to stop expanding. There are several cases an 1065 intermediate router might return a Reply before a Request reaches the 1066 caching router or the FHR as described in Section 3.2. 1068 6.1. Arriving at First-hop router 1070 A CCNinfo Request can be determined to have arrived at the first-hop 1071 router. 1073 6.2. Arriving at Router Having Cache 1075 A CCNinfo Request can be determined to have arrived at the router 1076 having the specified content cache within the specified HopLimit. 1078 6.3. Invalid Request 1080 If the router does not validate the Request, the router MUST note a 1081 ReturnCode of INVALID_REQUEST in the fixed header of the message and 1082 forward the message without appending any Reply (sub-)block TLV as 1083 the Reply back to the CCNinfo user. The router MAY, however, 1084 randomly ignore the received invalid messages. (See Section 10.6.) 1086 6.4. No Route 1088 If the router cannot determine the routing paths or neighbor routers 1089 for the specified name prefix within the specified HopLimit, the 1090 router MUST note a ReturnCode of NO_ROUTE in the fixed header of the 1091 message and forward the message as the Reply back to the CCNinfo 1092 user. 1094 6.5. No Information 1096 If the router does not have any information about the specified name 1097 prefix within the specified HopLimit, the router MUST note a 1098 ReturnCode of NO_INFO in the fixed header of the message and forward 1099 the message as the Reply back to the CCNinfo user. 1101 6.6. No Space 1103 If appending the Report block would make the Request packet longer 1104 than the MTU of the Incoming face, or longer than 1280 bytes (in the 1105 case of IPv6 as the payload [5]), the router MUST note a ReturnCode 1106 of NO_SPACE in the fixed header of the message and forward the 1107 message as the Reply back to the CCNinfo user. 1109 6.7. Fatal Error 1111 If a CCNinfo Request has encountered a fatal error, the router MUST 1112 note a ReturnCode of FATAL_ERROR in the fixed header of the message 1113 and forward the message as the Reply back to the CCNinfo user. 1115 6.8. CCNinfo Reply Timeout 1117 If a router receives the Request or Reply message that expires its 1118 own [CCNinfo Reply Timeout] value (Section 7.1), the router will 1119 silently discard the Request or Reply message. 1121 6.9. Non-Supported Node 1123 Cases will arise in which a router or a FHR along the path does not 1124 support CCNinfo. In such cases, a CCNinfo user and routers that 1125 forward the CCNinfo Request will time out the CCNinfo request. 1127 6.10. Administratively Prohibited 1129 If CCNinfo is administratively prohibited, the router rejects the 1130 Request message and MUST reply the CCNinfo Reply with the ReturnCode 1131 of ADMIN_PROHIB. The router MAY, however, randomly ignore the 1132 Request messages to be rejected. (See Section 10.6.) 1134 7. Configurations 1136 7.1. CCNinfo Reply Timeout 1138 The [CCNinfo Reply Timeout] value is used to time out a CCNinfo 1139 Reply. The value for a router can be statically configured by the 1140 router's administrators/operators. The default value is 3 (seconds). 1142 The [CCNinfo Reply Timeout] value SHOULD NOT be larger than 4 1143 (seconds) and SHOULD NOT be lower than 2 (seconds). 1145 7.2. HopLimit in Fixed Header 1147 If a CCNinfo user does not specify the HopLimit value in a fixed 1148 header for a Request message as the HopLimit, the HopLimit is set to 1149 32. Note that 0 HopLimit is an invalid Request; hence the router in 1150 this case follows the way defined in Section 6.3. 1152 7.3. Access Control 1154 A router MAY configure the valid or invalid networks to enable an 1155 access control. The access control can be defined per name prefix, 1156 such as "who can retrieve which name prefix". See Section 10.2. 1158 8. Diagnosis and Analysis 1160 8.1. Number of Hops 1162 A CCNinfo Request message is forwarded in a hop-by-hop manner and 1163 each forwarding router appended its own Report block. We can then 1164 verify the number of hops to reach the content forwarder or the 1165 publisher. 1167 8.2. Caching Router Identification 1169 It is possible to identify the routers in the path from the CCNinfo 1170 user to the content forwarder, while some routers may hide their 1171 identifier (e.g., IP address) with all-zeros in the Report blocks 1172 (Section 10.1). 1174 8.3. TTL or Hop Limit 1176 By taking the HopLimit from the content forwarder and forwarding TTL 1177 threshold over all hops, it is possible to discover the TTL or hop 1178 limit required for the content forwarder to reach the CCNinfo user. 1180 8.4. Time Delay 1182 If the routers have synchronized clocks, it is possible to estimate 1183 propagation and queuing delay from the differences between the 1184 timestamps at successive hops. However, this delay includes control 1185 processing overhead, so is not necessarily indicative of the delay 1186 that data traffic would experience. 1188 8.5. Path Stretch 1190 By getting the path stretch "d / P", where "d" is the hop count of 1191 the data and "P" is the hop count from the consumer to the publisher, 1192 we can measure the improvement in path stretch in various cases, such 1193 as different caching and routing algorithms. We can then facilitate 1194 investigation of the performance of the protocol. 1196 8.6. Cache Hit Probability 1198 CCNinfo can show the number of received interests per cache or chunk 1199 on a router. By this, CCNinfo measures the content popularity (i.e., 1200 the number of accesses for each content/cache), and you can 1201 investigate the routing/caching strategy in networks. 1203 9. IANA Considerations 1205 New assignments can only be made via a Standards Action as specified 1206 in [4]. The current document does not intend to be the standard 1207 document. However, the new assignments such as ReturnCode and 1208 various type values will be considered when this specification 1209 becomes the RFC. 1211 10. Security Considerations 1213 This section addresses some of the security considerations. 1215 10.1. Policy-Based Information Provisioning for Request 1217 Although CCNinfo gives excellent troubleshooting cues, some network 1218 administrators or operators may not want to disclose everything about 1219 their network to the public, or may wish to securely transmit private 1220 information to specific members of their networks. CCNinfo provides 1221 policy-based information provisioning allowing network administrators 1222 to specify their response policy for each router. 1224 The access policy regarding "who is allowed to retrieve" and/or "what 1225 kind of information" can be defined for each router. For the former 1226 access policy, routers having the specified content MAY examine the 1227 signature enclosed in the Request message and decide whether they 1228 should notify the content information in the Reply or not. If the 1229 routers decide to not notify the content information, they MUST reply 1230 the CCNinfo Reply with the ReturnCode of ADMIN_PROHIB without 1231 appending any Reply (sub-)block TLV. For the latter policy, the 1232 permission, whether (1) All (all cache information is disclosed), (2) 1233 Partial (cache information with the particular name prefix can (or 1234 cannot) be disclosed), or (3) Deny (no cache information is 1235 disclosed), is defined at routers. 1237 On the other hand, we entail that each router does not disrupt 1238 forwarding CCNinfo Request and Reply messages. When a Request 1239 message is received, the router SHOULD insert Report block if the 1240 ReturnCode is NO_ERROR. Here, according to the policy configuration, 1241 the Node Identifier field in the Report block MAY be null (i.e., all- 1242 zeros), but the Request Arrival Time field SHOULD NOT be null. At 1243 last, the router SHOULD forward the Request message to the upstream 1244 router toward the content forwarder if the ReturnCode is kept with 1245 NO_ERROR. 1247 10.2. Filtering of CCNinfo Users Located in Invalid Networks 1249 A router MAY support an access control mechanism to filter out 1250 Requests from invalid CCNinfo users. For it, invalid networks (or 1251 domains) could, for example, be configured via a list of allowed/ 1252 disallowed networks (as seen in Section 7.3). If a Request is 1253 received from the disallowed network (according to the Node 1254 Identifier in the Request block), the Request MUST NOT be processed 1255 and the Reply with the ReturnCode of INFO_HIDDEN SHOULD be used to 1256 note that. The router MAY, however, perform rate-limited logging of 1257 such events. 1259 10.3. Topology Discovery 1261 CCNinfo can be used to discover actively-used topologies. If a 1262 network topology is a secret, CCNinfo Requests SHOULD be restricted 1263 at the border of the domain, using the ADMIN_PROHIB return code. 1265 10.4. Characteristics of Content 1267 CCNinfo can be used to discover what publishers are sending to what 1268 kinds of contents. If this information is a secret, CCNinfo Requests 1269 SHOULD be restricted at the border of the domain, using the 1270 ADMIN_PROHIB return code. 1272 10.5. Longer or Shorter CCNinfo Reply Timeout 1274 Routers can configure the CCNinfo Reply Timeout (Section 7.1), which 1275 is the allowable timeout value to keep the PIT entry. If routers 1276 configure the longer timeout value, there may be an attractive attack 1277 vector against PIT memory. Moreover, especially when the full 1278 discovery request option (Section 5.3) is specified for the CCNinfo 1279 Request, a number of Reply messages may come back and cause a 1280 response storm. (See Section 10.7 for rate limiting to avoid the 1281 storm). In order to avoid DoS attacks, routers MAY configure the 1282 timeout value, which is shorter than the user-configured CCNinfo 1283 timeout value. However, if it is too short, the Request may be timed 1284 out and the CCNinfo user does not receive the all Replies and only 1285 retrieves the partial path information (i.e., information about part 1286 of the tree). 1288 There may be the way to allow for incremental exploration (i.e., to 1289 explore the part of the tree the previous operation did not explore), 1290 whereas discussing such mechanism is out of scope of this document. 1292 10.6. Limiting Request Rates 1294 A router may limit CCNinfo Requests by ignoring some of the 1295 consecutive messages. The router MAY randomly ignore the received 1296 messages to minimize the processing overhead, i.e., to keep fairness 1297 in processing requests, or prevent traffic amplification. No error 1298 is returned. The rate limit is left to the router's implementation. 1300 10.7. Limiting Reply Rates 1302 CCNinfo supporting multipath forwarding may result in one Request 1303 returning multiple Reply messages. In order to prevent abuse, the 1304 routers in the traced path MAY need to rate-limit the Replies. No 1305 error is returned. The rate limit function is left to the router's 1306 implementation. 1308 10.8. Adjacency Verification 1310 It is assumed that CCNinfo Request and Reply messages are forwarded 1311 by adjacent neighbor nodes or routers. Defining the secure way to 1312 verify the adjacency cannot rely on the way specified in CCNx message 1313 format or semantics, yet specifying the mechanism to validate 1314 adjacent neighbor routers is out of scope of this document. An 1315 adjacency verification mechanism and the corresponding TLV for 1316 adjacency verification using hop-by-hop TLV header such as [9] is the 1317 potential way, and the corresponding router behaviors and messages 1318 are defined in [10]. 1320 11. Acknowledgements 1322 The authors would like to thank Spyridon Mastorakis, Ilya Moiseenko, 1323 David Oran, and Thierry Turletti for their valuable comments and 1324 suggestions on this document. 1326 12. References 1328 12.1. Normative References 1330 [1] Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 1331 Format", draft-irtf-icnrg-ccnxmessages-09 (work in 1332 progress), January 2019. 1334 [2] Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", 1335 draft-irtf-icnrg-ccnxsemantics-10 (work in progress), 1336 January 2019. 1338 [3] Bradner, S., "Key words for use in RFCs to Indicate 1339 Requirement Levels", BCP 14, RFC 2119, 1340 DOI 10.17487/RFC2119, March 1997, 1341 . 1343 [4] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1344 Writing an IANA Considerations Section in RFCs", BCP 26, 1345 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1346 . 1348 [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1349 (IPv6) Specification", RFC 8200, July 2017. 1351 12.2. Informative References 1353 [6] Asaeda, H., Matsuzono, K., and T. Turletti, "Contrace: A 1354 Tool for Measuring and Tracing Content-Centric Networks", 1355 IEEE Communications Magazine, Vol.53, No.3, pp.182-188, 1356 March 2015. 1358 [7] Malkin, G., "Traceroute Using an IP Option", RFC 1393, 1359 January 1993. 1361 [8] Asaeda, H., Mayer, K., and W. Lee, "Mtrace Version 2: 1362 Traceroute Facility for IP Multicast", RFC 8487, October 1363 2018. 1365 [9] Li, R., Asaeda, H., and J. Wu, "DCAuth: Data-Centric 1366 Authentication for Secure In-Network Big-Data Retrieval", 1367 IEEE Transactions on Network Science and Engineering 1368 (TNSE) , October 2018. 1370 [10] Li, R. and H. Asaeda, "Hop-by-Hop Authentication in 1371 Content-Centric Networking/Named Data Networking", draft- 1372 li-icnrg-hopauth-00 (work in progress), July 2019. 1374 Appendix A. ccninfo Command and Options 1376 The ccninfo command enables the CCNinfo user to investigate the 1377 routing path based on the name prefix of the content (e.g., 1378 ccn:/news/today). The name prefix is mandatory but exclusive 1379 options; that is, only one of them should be used with the ccninfo 1380 command at once. 1382 The usage of ccninfo command is as follows: 1384 Usage: ccninfo [-f] [-n] [-o] [-r hop_count] [-s hop_count] 1385 name_prefix 1387 name_prefix 1388 Prefix name of content (e.g., ccn:/news/today) or exact name of 1389 content (e.g., ccn:/news/today/Chunk=10) the CCNinfo user wants to 1390 trace. 1392 f option 1393 This option enables "full discovery request"; routers ignore the 1394 forwarding strategy and send CCNinfo Requests to multiple upstream 1395 routers simultaneously. The CCNinfo user could then trace the all 1396 potential forwarding paths. 1398 n option 1399 This option can be specified if a CCNinfo user only needs the 1400 routing path information to the specified content/cache and RTT 1401 between CCNinfo user and content forwarder; therefore, cache 1402 information is not given. 1404 o option 1405 This option enables to trace the path to the content publisher. 1406 Each router along the path to the publisher inserts each Report 1407 block and forwards the Request message. It does not send Reply 1408 even if it caches the specified content. FHR that attaches the 1409 publisher (who has the complete set of content and is not a 1410 caching router) replies the Reply message. 1412 r option 1413 Number of traced routers. If the CCNinfo user specifies this 1414 option, only the specified number of hops from the CCNinfo user 1415 trace the Request; each router inserts its own Report block and 1416 forwards the Request message to the upstream router(s), and the 1417 last router stops the trace and sends the Reply message back to 1418 the CCNinfo user. This value is set in the "HopLimit" field 1419 located in the fixed header of the Request. For example, when the 1420 CCNinfo user invokes the CCNinfo command with this option such as 1421 "-r 3", only three routers along the path examine their path and 1422 cache information. If there is a caching router or FHR within the 1423 hop count along the path, the caching router or FHR sends back the 1424 Reply message and terminates the trace request. If the last 1425 router does not have the corresponding cache, it replies the Reply 1426 message with NO_INFO return code (described in Section 3.1) with 1427 no Reply block TLV inserted. The Request messages are terminated 1428 at FHR; therefore, although the maximum value for this option a 1429 CCNinfo user can specify is 255, the Request messages should be in 1430 general reached at FHR within significantly lower than 255 hops. 1432 s option 1433 Number of skipped routers. If the CCNinfo user specifies this 1434 option, the number of hops from the CCNinfo user simply forward 1435 the CCNinfo Request messages without adding its own Report block 1436 and without replying the Request, and the next upstream router 1437 starts the trace. This value is set in the "SkipHopCount" field 1438 located in the Request block TLV. For example, when the CCNinfo 1439 user invokes the CCNinfo command with this option such as "-s 3", 1440 the three upstream routers along the path only forwards the 1441 Request message, but does not append their Report blocks in the 1442 hop-by-hop headers and does not send the Reply messages even 1443 though they have the corresponding cache. The Request messages 1444 are terminated at FHR; therefore, although the maximum value for 1445 this option a CCNinfo user can specify is 255, if the Request 1446 messages reaches FHR, the FHR silently discards the Request 1447 message and the request will be timed out. 1449 Authors' Addresses 1451 Hitoshi Asaeda 1452 National Institute of Information and Communications Technology 1453 4-2-1 Nukui-Kitamachi 1454 Koganei, Tokyo 184-8795 1455 Japan 1457 Email: asaeda@nict.go.jp 1459 Atsushi Ooka 1460 National Institute of Information and Communications Technology 1461 4-2-1 Nukui-Kitamachi 1462 Koganei, Tokyo 184-8795 1463 Japan 1465 Email: a-ooka@nict.go.jp 1467 Xun Shao 1468 Kitami Institute of Technology 1469 165 Koen-cho 1470 Kitami, Hokkaido 090-8507 1471 Japan 1473 Email: x-shao@mail.kitami-it.ac.jp