idnits 2.17.1 draft-asaeda-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 (June 30, 2018) is 2127 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: '-P' on line 1354 -- Looks like a reference, but probably isn't: '-g' on line 1354 -- Looks like a reference, but probably isn't: '-f' on line 1354 -- Looks like a reference, but probably isn't: '-n' on line 1354 -- Looks like a reference, but probably isn't: '-o' on line 1354 -- Looks like a reference, but probably isn't: 'TBD' on line 1383 == Outdated reference: A later version (-09) exists of draft-irtf-icnrg-ccnxmessages-07 -- Obsolete informational reference (is this intentional?): RFC 1393 (ref. '5') (Obsoleted by RFC 6814) == Outdated reference: A later version (-26) exists of draft-ietf-mboned-mtrace-v2-24 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group H. Asaeda 3 Internet-Draft NICT 4 Intended status: Experimental X. Shao 5 Expires: January 1, 2019 Kitami Institute of Technology 6 June 30, 2018 8 CCNinfo: Discovering Content and Network Information in Content-Centric 9 Networks 10 draft-asaeda-icnrg-ccninfo-01 12 Abstract 14 This document describes a mechanism named "CCNinfo" that discovers 15 information about the network topology and in-network cache in 16 Content-Centric Networks (CCN). CCNinfo investigates: 1) the CCN 17 routing path information per name prefix, device name, and function/ 18 application, 2) the Round-Trip Time (RTT) between content forwarder 19 and consumer, and 3) the states of in-network cache per name prefix. 20 In addition, it discovers a gateway that supports different protocols 21 such as CCN and Named-Data Networks (NDN). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 1, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 60 3. CCNinfo Message Formats . . . . . . . . . . . . . . . . . . . 7 61 3.1. Request Message . . . . . . . . . . . . . . . . . . . . . 8 62 3.1.1. Request Block . . . . . . . . . . . . . . . . . . . . 10 63 3.1.2. Report Block . . . . . . . . . . . . . . . . . . . . 12 64 3.2. Reply Message . . . . . . . . . . . . . . . . . . . . . . 14 65 3.2.1. Reply Block . . . . . . . . . . . . . . . . . . . . . 16 66 3.2.1.1. Reply Sub-Block . . . . . . . . . . . . . . . . . 16 67 4. CCNinfo User Behavior . . . . . . . . . . . . . . . . . . . . 19 68 4.1. Sending CCNinfo Request . . . . . . . . . . . . . . . . . 19 69 4.1.1. Gateway Discovery . . . . . . . . . . . . . . . . . . 19 70 4.1.2. Routing Path Information . . . . . . . . . . . . . . 20 71 4.1.3. In-Network Cache Information . . . . . . . . . . . . 20 72 4.2. Receiving CCNinfo Reply . . . . . . . . . . . . . . . . . 20 73 5. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 21 74 5.1. Receiving CCNinfo Request . . . . . . . . . . . . . . . . 21 75 5.1.1. Request Packet Verification . . . . . . . . . . . . . 21 76 5.1.2. Request Normal Processing . . . . . . . . . . . . . . 21 77 5.2. Forwarding CCNinfo Request . . . . . . . . . . . . . . . 22 78 5.3. Sending CCNinfo Reply . . . . . . . . . . . . . . . . . . 23 79 5.4. Forwarding CCNinfo Reply . . . . . . . . . . . . . . . . 24 80 6. Publisher Behavior . . . . . . . . . . . . . . . . . . . . . 24 81 7. CCNinfo Termination . . . . . . . . . . . . . . . . . . . . . 25 82 7.1. Arriving at Publisher or Gateway . . . . . . . . . . . . 25 83 7.2. Arriving at Router Having Cache . . . . . . . . . . . . . 25 84 7.3. No Route . . . . . . . . . . . . . . . . . . . . . . . . 25 85 7.4. No Information . . . . . . . . . . . . . . . . . . . . . 25 86 7.5. No Space . . . . . . . . . . . . . . . . . . . . . . . . 25 87 7.6. Fatal Error . . . . . . . . . . . . . . . . . . . . . . . 25 88 7.7. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 26 89 7.8. Non-Supported Node . . . . . . . . . . . . . . . . . . . 26 90 7.9. Administratively Prohibited . . . . . . . . . . . . . . . 26 91 8. Configurations . . . . . . . . . . . . . . . . . . . . . . . 26 92 8.1. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 26 93 8.2. HopLimit in Fixed Header . . . . . . . . . . . . . . . . 26 94 8.3. Access Control . . . . . . . . . . . . . . . . . . . . . 26 95 9. Diagnosis and Analysis . . . . . . . . . . . . . . . . . . . 26 96 9.1. Number of Hops . . . . . . . . . . . . . . . . . . . . . 26 97 9.2. Caching Router and Gateway Identification . . . . . . . . 27 98 9.3. TTL or Hop Limit . . . . . . . . . . . . . . . . . . . . 27 99 9.4. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 27 100 9.5. Path Stretch . . . . . . . . . . . . . . . . . . . . . . 27 101 9.6. Cache Hit Probability . . . . . . . . . . . . . . . . . . 27 102 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 103 10.1. Policy-Based Information Provisioning for Request . . . 27 104 10.2. Filtering of CCNinfo Users Located in Invalid Networks . 28 105 10.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 28 106 10.4. Characteristics of Content . . . . . . . . . . . . . . . 29 107 10.5. Longer or Shorter CCNinfo Reply Timeout . . . . . . . . 29 108 10.6. Limiting Request Rates . . . . . . . . . . . . . . . . . 29 109 10.7. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 29 110 10.8. Adjacency Verification . . . . . . . . . . . . . . . . . 29 111 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 113 12.1. Normative References . . . . . . . . . . . . . . . . . . 30 114 12.2. Informative References . . . . . . . . . . . . . . . . . 30 115 Appendix A. ccninfo Command and Options . . . . . . . . . . . . 30 116 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 33 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 119 1. Introduction 121 In Content-Centric Networks (CCN), publishers provide content through 122 the network, and receivers retrieve content by name. In this network 123 architecture, routers forward content requests by means of their 124 Forwarding Information Bases (FIBs), which are populated by name- 125 based routing protocols. CCN also enables receivers to retrieve 126 content from an in-network cache. 128 In CCN, while consumers do not generally need to know which content 129 forwarder is transmitting the content to them, operators and 130 developers may want to identify the content forwarder and observe the 131 routing path information per name prefix for troubleshooting or 132 investigating the network conditions. 134 Traceroute [5] is a useful tool for discovering the routing 135 conditions in IP networks as it provides intermediate router 136 addresses along the path between source and destination and the 137 Round-Trip Time (RTT) for the path. However, this IP-based network 138 tool cannot trace the name prefix paths used in CCN. Moreover, such 139 IP-based network tool does not obtain the states of the in-network 140 cache to be discovered. 142 This document describes the specification of "CCNinfo", an active 143 networking tool for discovering the path and content caching 144 information in CCN. CCNinfo potentially discovers devices and 145 functions/applications in CCN. CCNinfo is designed based on the work 146 previously published in [4]. 148 CCNinfo can be implemented with the ccninfo user command and the 149 forwarding function implementation on a content forwarder (e.g., 150 router or publisher). The CCNinfo user (e.g., consumer) invokes the 151 ccninfo command (described in Appendix A) with the name prefix of the 152 content, the device name, or the function (or application) name. The 153 ccninfo command initiates the "Request" message (described in 154 Section 3.1). The Request message, for example, obtains routing path 155 and cache information. When an appropriate adjacent neighbor router 156 receives the Request message, it retrieves cache information. If the 157 router is not the content forwarder for the request, it inserts its 158 "Report" block (described in Section 3.1.2) into the Request message 159 and forwards the Request message to its upstream neighbor router(s) 160 decided by its FIB. These two message types, Request and Reply 161 messages, are encoded in the CCNx TLV format [1]. 163 In this way, the Request message is forwarded by routers toward the 164 content publisher, and the Report record is inserted by each 165 intermediate router. When the Request message reaches the content 166 forwarder (i.e., a router or the publisher who has the specified 167 cache or content), the content forwarder forms the "Reply" message 168 (described in Section 3.2) and sends it to the downstream neighbor 169 router. The Reply message is forwarded back toward the user in a 170 hop-by-hop manner. This request-reply message flow, walking up the 171 tree from a consumer toward a publisher, is inspired by the design of 172 the IP multicast traceroute facility [6]. 174 CCNinfo supports multipath forwarding. The Request messages can be 175 forwarded to multiple neighbor routers. When the Request messages 176 forwarded to multiple routers, the different Reply messages will be 177 forwarded from different routers or publisher. To support this case, 178 PIT entries initiated by CCNinfo remain until the defined timeout 179 value is expired. 181 1. Request 2. Request 3. Request 4. Request 182 (+U) (U+A) (U+A+B) (U+A+B+C) 183 +----+ +----+ +----+ +----+ 184 | | | | | | | | 185 | v | v | v | v 186 +--------+ +--------+ +--------+ +--------+ +---------+ 187 | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| 188 | user | | A | | B | | C | | | 189 +--------+ +--------+ +--------+ +--------+ +---------+ 190 \ 191 \ +-------+ 192 3. Request \ | Cache | 193 (U+A+B) \ +---------+ | 194 v| Caching |----+ 195 | router | 196 +---------+ 198 Figure 1: Request messages forwarded by consumer and routers. 199 CCNinfo user and routers (i.e., Router A,B,C) insert their own Report 200 blocks into the Request message and forward the message toward the 201 content forwarder (i.e., caching router and publisher) 203 3. Reply(C) 2. Reply(C) 204 4. Reply(P) 3. Reply(P) 2. Reply(P) 1. Reply(P) 205 +----+ +----+ +----+ +----+ 206 | | | | | | | | 207 v | v | v | v | 208 +--------+ +--------+ +--------+ +--------+ +---------+ 209 | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| 210 | user | | A | | B | | C | | | 211 +--------+ +--------+ +--------+ +--------+ +---------+ 212 ^ 213 \ +-------+ 214 1. Reply(C) \ | Cache | 215 \ +---------+ | 216 \| Caching |----+ 217 | router | 218 +---------+ 220 Figure 2: Reply messages forwarded by publisher and routers. Each 221 router forwards the Reply message, and finally the CCNinfo user 222 receives two Reply messages: one from the publisher and the other 223 from the caching router. 225 CCNinfo facilitates the tracing of a routing path and provides: 1) 226 the RTT between content forwarder (i.e., caching router or publisher) 227 and consumer, 2) the states of in-network cache per name prefix, and 228 3) the routing path information per name prefix. 230 In addition, CCNinfo identifies the states of the cache, such as the 231 following metrics for Content Store (CS) in the content forwarder: 1) 232 size of the cached content, 2) number of the cached chunks of the 233 content, 3) number of the accesses (i.e., received Interests) per 234 cache or chunk, and 4) lifetime and expiration time per cache or 235 chunk. The number of received Interests per cache or chunk on the 236 routers indicates the popularity of the content. 238 Furthermore, CCNinfo implements policy-based information provisioning 239 that enables administrators to "hide" secure or private information, 240 but does not disrupt the forwarding of messages. This policy-based 241 information provisioning reduces the deployment barrier faced by 242 operators in installing and running CCNinfo on their routers. 244 2. Terminology 246 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 247 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 248 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2], 249 and indicate requirement levels for compliant CCNinfo 250 implementations. 252 2.1. Definitions 254 Since CCNinfo requests flow in the opposite direction to the data 255 flow, we refer to "upstream" and "downstream" with respect to data, 256 unless explicitly specified. 258 Router 259 It is a router facilitating name-based content/device/function 260 name or characteristic retrieval in the path between consumer and 261 publisher. 263 Scheme name 264 It indicates a URI and protocol such as "ccn:/" and "ndn:/". This 265 document considers the protocol for name-based content/device/ 266 function name or characteristic retrieval. 268 Gateway 269 It is a router supporting multiple scheme names in the path 270 between consumer and publisher. The router has multiple FIBs for 271 different protocols and establishes the connections with different 272 neighbor routers for each protocol. 274 Node 275 It is a router, gateway, publisher, or consumer. 277 Content forwarder 278 It is either a caching router or a publisher that holds the cache 279 (or content) and forwards it to consumers. 281 CCNinfo user 282 It is a node that invokes the ccninfo command and initiates the 283 CCNinfo Request. 285 Incoming face 286 The face on which data is expected to arrive from the specified 287 name prefix. 289 Outgoing face 290 The face to which data from the publisher or router is expected to 291 transmit for the specified name prefix. It is also the face on 292 which the Request messages are received. 294 3. CCNinfo Message Formats 296 CCNinfo uses two message types: Request and Reply. Both messages are 297 encoded in the CCNx TLV format ([1], Figure 3). The Request message 298 consists of a fixed header, Request block TLV Figure 7, and Report 299 block TLV(s) Figure 11. The Reply message consists of a fixed 300 header, Request block TLV, Report block TLV(s), and Reply block/sub- 301 block TLV(s) Figure 14. 303 1 2 3 304 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 305 +---------------+---------------+---------------+---------------+ 306 | Version | PacketType | PacketLength | 307 +---------------+---------------+---------------+---------------+ 308 | PacketType specific fields | HeaderLength | 309 +---------------+---------------+---------------+---------------+ 310 / Optional Hop-by-hop header TLVs / 311 +---------------+---------------+---------------+---------------+ 312 / PacketPayload TLVs / 313 +---------------+---------------+---------------+---------------+ 314 / Optional CCNx ValidationAlgorithm TLV / 315 +---------------+---------------+---------------+---------------+ 316 / Optional CCNx ValidationPayload TLV (ValidationAlg required) / 317 +---------------+---------------+---------------+---------------+ 319 Figure 3: Packet format [1] 321 The Request and Reply Type values in the fixed header are PT_REQUEST 322 and PT_REPLY, respectively (Figure 4). These messages are forwarded 323 in a hop-by-hop manner. When the Request message reaches the content 324 forwarder, the content forwarder turns the Request message into a 325 Reply message by changing the Type field value in the fixed header 326 from PT_REQUEST to PT_REPLY and forwards back to the node that has 327 initiated the Request message. 329 Code Type name 330 ======== ===================== 331 1 PT_INTEREST [1] 332 2 PT_CONTENT [1] 333 3 PT_RETURN [1] 334 4 PT_REQUEST 335 5 PT_REPLY 337 Figure 4: Packet Type Namespace 339 The CCNinfo Request and Reply messages MUST begin with a fixed header 340 with either a Request or Reply type value to specify whether it is a 341 Request message or Reply message. Following a fixed header, there 342 can be a sequence of optional hop-by-hop header TLV(s) for a Request 343 message. In the case of a Request message, it is followed by a 344 sequence of Report blocks, each from a router on the path toward the 345 publisher or caching router. 347 At the beginning of PacketPayload TLVs, one top-level TLV type, 348 T_DISCOVERY (Figure 5), exists at the outermost level of a CCNx 349 protocol message. This TLV indicates that the Name segment TLV(s) 350 and Reply block TLV(s) would follow in the Request or Reply message. 352 Code Type name 353 ======== ========================= 354 1 T_INTEREST [1] 355 2 T_OBJECT [1] 356 3 T_VALIDATION_ALG [1] 357 4 T_VALIDATION_PAYLOAD [1] 358 5 T_DISCOVERY 360 Figure 5: Top-Level Type Namespace 362 3.1. Request Message 364 When a CCNinfo user initiates a discovery request (e.g., by ccninfo 365 command described in Appendix A), a CCNinfo Request message is 366 created and forwarded to its upstream router through the Incoming 367 face(s) determined by its FIB. 369 The Request message format is as shown in Figure 6. It consists of a 370 fixed header, Request block TLV (Figure 7), Report block TLV(s) 371 (Figure 11), and Name TLV. The Type value of Top-Level type 372 namespace is T_DISCOVERY (Figure 5). The Type value for the Report 373 message is PT_REQUEST. 375 1 2 3 376 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 377 +---------------+---------------+---------------+---------------+ 378 | Version | PacketType | PacketLength | 379 +---------------+---------------+---------------+---------------+ 380 | HopLimit | ReturnCode |Reserved (MBZ) | HeaderLength | 381 +===============+===============+===============+===============+ 382 | | 383 + Request block TLV + 384 | | 385 +---------------+---------------+---------------+---------------+ 386 / Report block TLV 1 / 387 +---------------+---------------+---------------+---------------+ 388 / Report block TLV 2 / 389 +---------------+---------------+---------------+---------------+ 390 / . / 391 / . / 392 +---------------+---------------+---------------+---------------+ 393 / Report block TLV n / 394 +===============+===============+===============+===============+ 395 | T_DISCOVERY | MessageLength | 396 +---------------+---------------+---------------+---------------+ 397 | T_NAME | Length | 398 +---------------+---------------+---------------+---------------+ 399 / Name segment TLVs (name prefix specified by ccninfo command) / 400 +---------------+---------------+---------------+---------------+ 402 Figure 6: Request message consists of a fixed header, Request block 403 TLV, Report block TLV(s), and Name TLV 405 HopLimit: 8 bits 407 HopLimit is a counter that is decremented with each hop. It 408 limits the distance a Request may travel on the network. 410 ReturnCode: 8 bits 412 ReturnCode is used for the Reply message. This value is replaced 413 by the content forwarder when the Request message is returned as 414 the Reply message (see Section 3.2). Until then, this field MUST 415 be transmitted as zeros and ignored on receipt. 417 Value Name Description 418 ----- --------------- ---------------------------------------------- 419 0x00 NO_ERROR No error 420 0x01 WRONG_IF CCNinfo Request arrived on an interface 421 to which this router would not forward for 422 the specified name/function toward the 423 publisher. 424 0x02 INVALID_REQUEST Invalid CCNinfo Request is received. 425 0x03 NO_ROUTE This router has no route for the name prefix 426 and no way to determine a potential route. 427 0x04 NO_INFO This router has no cache information for the 428 specified name prefix, device information, or 429 function. 430 0x05 NO_SPACE There was not enough room to insert another 431 Report block in the packet. 432 0x06 NO_GATAWAY CCNinfo Request arrived on a non-gateway 433 router. 434 0x07 INFO_HIDDEN Information is hidden from this discovery 435 because of some policy. 436 0x0E ADMIN_PROHIB CCNinfo Request is administratively 437 prohibited. 438 0x0F UNKNOWN_REQUEST This router does not support/recognize the 439 Request message. 440 0x80 FATAL_ERROR A fatal error is one where the router may 441 know the upstream router but cannot forward 442 the message to it. 444 Reserved (MBZ): 8 bits 446 The reserved fields in the Value field MUST be transmitted as 447 zeros and ignored on receipt. 449 3.1.1. Request Block 451 When a CCNinfo user transmits the Request message, it MUST insert the 452 Request block TLV (Figure 7) and the Report block TLV (Figure 11) of 453 its own to the Request message before sending it through the Incoming 454 face(s). 456 1 2 3 457 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 458 +---------------+---------------+---------------+---------------+ 459 | T_DISC_REQ | Length | 460 +---------------+---------------+-------------------------------+ 461 | SchemeName | SkipHopCount | Reserved (MBZ) | 462 +---------------+---------------+-------------------------------+ 463 | Request ID | Flags | 464 +---------------+---------------+-------------------------------+ 466 Figure 7: Request block TLV (hop-by-hop header) 468 Code Type name 469 ============= ===================== 470 1 T_INTLIFE [1] 471 2 T_CACHETIME [1] 472 3 T_MSGHASH [1] 473 4 - 7 Reserved [1] 474 8 T_DISC_REQ 475 9 T_DISC_REPORT 476 %x0FFE T_PAD [1] 477 %x0FFF T_ORG [1] 478 %x1000-%x1FFF Reserved [1] 480 Figure 8: Hop-by-Hop Type Namespace 482 Type: 16 bits 484 Format of the Value field. For the single Request block TLV, the 485 type value MUST be T_DISC_REQ. For all the available types for 486 hop-by-hop type namespace, please see Figure 8. 488 Length: 16 bits 490 Length of Value field in octets. For the Request block, it MUST 491 be 4 in the current specification. 493 SchemeName: 8 bits 495 Currently, the following scheme names are defined. 497 Code Scheme name 498 ============= =============== 499 0 ccn:/ 500 1 ndn:/ 501 %x02-%FF Not assigned 503 Figure 9: Scheme Names 505 SkipHopCount: 8 bits 507 Number of skipped routers. This value MUST be lower than the 508 value of HopLimit at the fixed header. 510 Request ID: 16 bits 512 This field is used as a unique identifier for this CCNinfo Request 513 so that duplicate or delayed Reply messages can be detected. 515 Flags: 16 bits 517 The discovery conditions specified as the ccninfo command options 518 (described in Appendix A) are transferred in the Flags field. The 519 discovery conditions depend on the specified name (i.e., 520 name_prefix, device_name, or function_name) as shown in Figure 10. 521 Note that code %x01 and %x02 are exclusive options; that is, only 522 one of them should be turned on at once. 524 Code Type name 525 ============ ===================================================== 526 %x01 Cache retrieval allowing partial match (name_prefix) 527 %x02 No cache information required (name_prefix) 528 %x04 Publisher reachability (name_prefix and device_name) 529 %x08 Parallel request. Request to multiple upstream 530 routers simultaneously (name_prefix, device_name, 531 and function_name) 532 %x16 Discovery of gateway supporting specified scheme 533 name (name_prefix, device_name, and function_name) 534 %x32 Function's or application's version number retrieval 535 (function_name) 536 %x64-%x32768 Not assigned 538 Figure 10: Codes and types specified in Flags field 540 3.1.2. Report Block 542 A CCNinfo user and each upstream router along the path would insert 543 its own Report block TLV without changing the Type field of the fixed 544 header of the Request message until one of these routers is ready to 545 send a Reply. In the Report block TLV (Figure 11), the Request 546 Arrival Time and the Node Identifier MUST be inserted. 548 1 2 3 549 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 550 +---------------+---------------+---------------+---------------+ 551 | T_DISC_REPORT | Length | 552 +---------------+---------------+---------------+---------------+ 553 | Request Arrival Time | 554 +---------------+---------------+---------------+---------------+ 555 / Node Identifier / 556 +---------------+---------------+---------------+---------------+ 558 Figure 11: Report block TLV (hop-by-hop header) 560 Type: 16 bits 562 Format of the Value field. For the Request block TLV(s), the type 563 value(s) MUST be T_DISC_REPORT. 565 Length: 16 bits 567 Length of Value field in octets. 569 Request Arrival Time: 32 bits 571 The Request Arrival Time is a 32-bit NTP timestamp specifying the 572 arrival time of the CCNinfo Request packet at this router. The 573 32-bit form of an NTP timestamp consists of the middle 32 bits of 574 the full 64-bit form; that is, the low 16 bits of the integer part 575 and the high 16 bits of the fractional part. 577 The following formula converts from a UNIX timeval to a 32-bit NTP 578 timestamp: 580 request_arrival_time 581 = ((tv.tv_sec + 32384) << 16) + ((tv.tv_nsec << 7) / 1953125) 583 The constant 32384 is the number of seconds from Jan 1, 1900 to 584 Jan 1, 1970 truncated to 16 bits. ((tv.tv_nsec << 7) / 1953125) 585 is a reduction of ((tv.tv_nsec / 1000000000) << 16). 587 Note that CCNinfo does not require all the routers on the path to 588 have synchronized clocks in order to measure one-way latency. 590 Node Identifier: variable length 592 This field specifies the CCNinfo user or the router identifier 593 (e.g., IPv4 address) of the Incoming face on which packets from 594 the publisher are expected to arrive, or all-zeros if unknown or 595 unnumbered. Since we may not always rely on the IP addressing 596 architecture, it would be necessary to define the identifier 597 uniqueness (e.g., by specifying the protocol family) for this 598 field. However, defining such uniqueness is out of scope of this 599 document. Potentially, this field may be defined as a new TLV, 600 which might be defined in the document for the CCNx TLV format[1]. 602 3.2. Reply Message 604 When a content forwarder receives a CCNinfo Request message from the 605 appropriate adjacent neighbor router, it would insert a Reply block 606 TLV and Reply sub-block TLV(s) of its own to the Request message and 607 turn the Request into the Reply by changing the Type field of the 608 fixed header of the Request message from PT_REQUEST to PT_REPLY. The 609 Reply message (see Figure 12) would then be forwarded back toward the 610 CCNinfo user in a hop-by-hop manner. 612 1 2 3 613 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 614 +---------------+---------------+---------------+---------------+ 615 | Version | PacketType | PacketLength | 616 +---------------+---------------+---------------+---------------+ 617 | HopLimit | ReturnCode |Reserved (MBZ) | HeaderLength | 618 +===============+===============+===============+===============+ 619 | | 620 + Request block TLV + 621 | | 622 +---------------+---------------+---------------+---------------+ 623 / . / 624 / . / 625 / n Report block TLVs / 626 / . / 627 / . / 628 +===============+===============+===============+===============+ 629 | T_DISCOVERY | MessageLength | 630 +---------------+---------------+---------------+---------------+ 631 | T_NAME | Length | 632 +---------------+---------------+---------------+---------------+ 633 / Name segment TLVs (name prefix specified by ccninfo command) / 634 +---------------+---------------+---------------+---------------+ 635 / Reply block TLV / 636 +---------------+---------------+---------------+---------------+ 637 / Reply sub-block TLV 1 / 638 +---------------+---------------+---------------+---------------+ 639 / Reply sub-block TLV 2 / 640 +---------------+---------------+---------------+---------------+ 641 / . / 642 / . / 643 +---------------+---------------+---------------+---------------+ 644 / Reply sub-block TLV k / 645 +---------------+---------------+---------------+---------------+ 647 Figure 12: Reply message consists of a fixed header, Request block 648 TLV, Report block TLV(s), Name TLV, and Reply block/sub-block TLV(s) 649 Code Type name 650 ============= ===================== 651 0 T_NAME [1] 652 1 T_PAYLOAD [1] 653 2 T_KEYIDRESTR [1] 654 3 T_OBJHASHRESTR [1] 655 5 T_PAYLDTYPE [1] 656 6 T_EXPIRY [1] 657 7 T_DISC_REPLY 658 8 - 12 Reserved [1] 659 %x0FFE T_PAD [1] 660 %x0FFF T_ORG [1] 661 %x1000-%x1FFF Reserved [1] 663 Figure 13: CCNx Message Type Namespace 665 3.2.1. Reply Block 667 The Reply block TLV is an envelope for Reply sub-block TLV(s) 668 (explained in Section 3.2.1.1). 670 1 2 3 671 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 672 +---------------+---------------+---------------+---------------+ 673 | T_DISC_REPLY | Length | 674 +---------------+---------------+---------------+---------------+ 676 Figure 14: Reply block TLV (packet payload) 678 Type: 16 bits 680 Format of the Value field. For the Report block TLV, the type 681 value MUST be T_DISC_REPLY. 683 Length: 16 bits 685 Length of Value field in octets. This length is a total length of 686 Reply sub-block(s). 688 3.2.1.1. Reply Sub-Block 690 In addition to the Reply block, a router on the traced path will add 691 one or multiple Reply sub-blocks followed by the Reply block before 692 sending the Reply to its neighbor router. 694 The Reply sub-block is flexible for various purposes. For instance, 695 operators and developers may want to obtain various characteristics 696 of content such as content's ownership and copyright, or other cache 697 states and conditions. Various information about device or function 698 (or application) may be also retrieved by the variety of Reply sub- 699 blocks. In this document, Reply sub-block TLVs for T_DISC_CONTENT 700 and T_DISC_CONTENT_OWNER (Figure 15) and for T_DISC_GATEWAY 701 (Figure 16) are defined; other Reply sub-block TLVs will be defined 702 in separate document(s). 704 1 2 3 705 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 706 +---------------+---------------+---------------+---------------+ 707 | Type | Length | 708 +---------------+---------------+---------------+---------------+ 709 | Content Size | 710 +---------------+---------------+---------------+---------------+ 711 | Object Count | 712 +---------------+---------------+---------------+---------------+ 713 | # Received Interest | 714 +---------------+---------------+---------------+---------------+ 715 | First Seqnum | 716 +---------------+---------------+---------------+---------------+ 717 | Last Seqnum | 718 +---------------+---------------+---------------+---------------+ 719 | Cache Lifetime | 720 +---------------+---------------+---------------+---------------+ 721 | Remain Cache Lifetime | 722 +---------------+---------------+---------------+---------------+ 723 | T_NAME | Length | 724 +---------------+---------------+---------------+---------------+ 725 / Name segment TLVs (name prefix partially/exactly matched) / 726 +---------------+---------------+---------------+---------------+ 728 Figure 15: Reply sub-block TLV for T_DISC_CONTENT and 729 T_DISC_CONTENT_OWNER (packet payload) 731 1 2 3 732 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 733 +---------------+---------------+---------------+---------------+ 734 | Type | Length | 735 +---------------+---------------+---------------+---------------+ 736 | Scheme Name | Reserved (MBZ) | 737 +---------------+---------------+---------------+---------------+ 739 Figure 16: Reply sub-block TLV for T_DISC_GATEWAY (packet payload) 740 Code Type name 741 ============= =========================== 742 0 T_DISC_CONTENT 743 1 T_DISC_CONTENT_OWNER 744 2 T_DISC_GATEWAY 745 3 T_DISC_DEVICE 746 4 T_DISC_FUNCTION 747 %x0FFF T_ORG 748 %x1000-%x1FFF Reserved (Experimental Use) 750 Figure 17: CCNinfo Reply Type Namespace 752 Type: 16 bits 754 Format of the Value field. For the Reply sub-block TLV, the type 755 value MUST be one of the type value defined in the CCNinfo Reply 756 Type Namespace (Figure 17). T_DISC_CONTENT is specified when the 757 cache information is replied from a caching router. 758 T_DISC_CONTENT_OWNER is specified when the content information is 759 replied from a publisher. T_DISC_GATEWAY is used to discover a 760 gateway that has a FIB for the specified scheme name. 762 Length: 16 bits 764 Length of Value field in octets. 766 Scheme Name: 8 bits 768 The code of the scheme name defined in Figure 9. 770 Content Size: 32 bits 772 The total size (MB) of the (cached) content objects. Note that 773 the maximum size expressed by 32 bit field is 65 GB. 775 Object Count: 32 bits 777 The number of the (cached) content objects. 779 # Received Interest: 32 bits 781 The number of the received Interest messages to retrieve the 782 content. 784 First Seqnum: 32 bits 786 The first sequential number of the (cached) content objects. 788 Last Seqnum: 32 bits 790 The last sequential number of the (cached) content objects. Above 791 First Seqnum and this Last Seqnum do not guarantee the 792 consecutiveness of the cached content objects. 794 Cache Lifetime: 32 bits 796 The elapsed time after the oldest content object in the cache is 797 stored. The Cache Lifetime is a 32-bit NTP timestamp, and the 798 formula converts from a UNIX timeval to a 32-bit NTP timestamp is 799 same as that of Section 3.1.2. 801 Remain Cache Lifetime: 32 bits 803 The lifetime of a content object, which is removed first among the 804 cached content objects. The Remain Cache Lifetime is a 32-bit NTP 805 timestamp. 807 4. CCNinfo User Behavior 809 4.1. Sending CCNinfo Request 811 A CCNinfo user initiates a CCNinfo Request by sending the Request 812 message to the adjacent neighbor router(s) of interest. As a typical 813 example, a CCNinfo user invokes the ccninfo command (detailed in 814 Appendix A) that forms a Request message and sends it to the user's 815 adjacent neighbor router(s). 817 When the CCNinfo user's program initiates a Request message, it MUST 818 insert the necessary values, the "Request ID" (in the Request block) 819 and the "Node Identifier" (in the Report block), in the Request and 820 Report blocks. CCNinfo user's program MUST also record the Request 821 ID at the corresponding PIT entry. The Request ID is a unique 822 identifier for the CCNinfo Request. 824 After the CCNinfo user's program sends the Request message, until the 825 Reply times out, the CCNinfo user's program MUST keep the following 826 information; Request ID and Flags specified in the Request block, 827 Node Identifier and Request Arrival Time specified in the Report 828 block, and HopLimit specified in the fixed header. 830 4.1.1. Gateway Discovery 832 A CCNinfo Request can be used for gateway discovery; if a CCNinfo 833 user invokes a CCNinfo Request with a scheme name (e.g., ccn:/ or 834 ndn:/) and the "gateway discovery" flag value (i.e., "%x16" bit as 835 seen in Figure 10), s/he could potentially discover a gateway that 836 supports different protocols such as CCN and NDN. The CCNinfo 837 Request for gateway discovery only indicates the routing path 838 information (see Section 4.1.2) and the scheme name whether the 839 router is a gateway or not; it does not provide other information, 840 e.g., cache information. 842 4.1.2. Routing Path Information 844 A CCNinfo user can send a CCNinfo Request for investigating routing 845 path information for the specified named content. By the Request, 846 the legitimate user can obtain; 1) identifiers (e.g., IP addresses) 847 of intermediate routers, 2) identifier of content forwarder, 3) 848 number of hops between content forwarder and consumer, and 4) RTT 849 between content forwarder and consumer, per name prefix. This 850 CCNinfo Request is terminated when it reaches the content forwarder. 851 The ccninfo command enables user to obtain both the routing path 852 information and in-network cache information (see below) in a same 853 time. 855 4.1.3. In-Network Cache Information 857 A CCNinfo user can send a CCNinfo Request for investigating in- 858 network cache information. By this Request, the legitimate user can 859 obtain; 1) size of the cached content, 2) number of the cached chunks 860 of the content, 3) number of the accesses (i.e., received Interests) 861 per cache or chunk, and 4) lifetime and expiration time per cache or 862 chunk, for Content Store (CS) in the content forwarder. This CCNinfo 863 Request is terminated when it reaches the content forwarder. 865 4.2. Receiving CCNinfo Reply 867 A CCNinfo user's program will receive one or multiple CCNinfo Reply 868 messages from the adjacent neighbor router that has previously 869 received and forwarded the Request message(s). When the program 870 receives the Reply, it MUST compare the kept Request ID and the 871 Request ID noted in the Reply. If they do not match, the Reply 872 message SHOULD be silently discarded. 874 If the number of the Report blocks in the received Reply is more than 875 the initial HopLimit value (which was inserted in the original 876 Request) + 1, the Reply SHOULD be silently ignored. 878 After the CCNinfo user has determined that s/he has traced the whole 879 path or as much as s/he can expect to, s/he might collect statistics 880 by waiting a timeout. Useful statistics provided by CCNinfo can be 881 seen in Section 9. 883 5. Router Behavior 885 5.1. Receiving CCNinfo Request 887 5.1.1. Request Packet Verification 889 Upon receiving a CCNinfo Request message, a router MUST examine 890 whether the message comes from a valid adjacent neighbor node. If it 891 is invalid, the Request MUST be silently ignored. The router next 892 examines the value of the "HopLimit" in the fixed header and the 893 value of the "SkipHopCount" in the Request block (Figure 7). If 894 SkipHopCount value is equal or more than the HopLimit value, the 895 Request MUST be silently ignored. 897 5.1.2. Request Normal Processing 899 When a router receives a CCNinfo Request message, it performs the 900 following steps. 902 1. HopLimit and SkipHopCount are counters that are decremented with 903 each hop. The router terminates the CCNinfo Request when the 904 HopLimit value becomes zero. Until the SkipHopCount value 905 becomes zero, the router forwards the CCNinfo Request messages to 906 the upstream router(s) (if it knows) without adding its own 907 Report block and without replying the Request. If the router 908 does not know the upstream router(s), without depending on the 909 SkipHopCount value, it replies the CCNinfo Reply message with 910 NO_ROUTE return code. 912 2. The router examines the Flags field of the Request block of 913 received CCNinfo Request. If the flag value indicates "%x00" or 914 "%x01" bit (as seen in Figure 10) for "cache information 915 discovery", the router examines its FIB and CS. If the router 916 caches the specified content, it inserts own Report block to the 917 message and sends the Reply message with own Reply block and sub- 918 block. If the router does not cache the specified content but 919 knows the neighbor router(s) for the specified name prefix, it 920 inserts own Report block and forwards the Request to the upstream 921 neighbor(s). If the router does not cache the specified content 922 and does not know the upstream neighbor router(s) for the 923 specified name prefix, it replies the CCNinfo Reply message with 924 NO_ROUTE return code. 926 3. If the flag value indicates "%x02" bit for "routing path 927 information discovery", the router examines its FIB and CS. If 928 the router caches the specified content, it inserts own Report 929 block to the message and sends the Reply message with own Reply 930 block. The router does not insert any Reply sub-block here. If 931 the router does not cache the specified content but knows the 932 neighbor router(s) for the specified name prefix, it inserts own 933 Report block and forwards the Request to the upstream 934 neighbor(s). If the router does not cache the specified content 935 and does not know the upstream neighbor router(s) for the 936 specified name prefix, it replies the CCNinfo Reply message with 937 NO_ROUTE return code. 939 4. If the flag value indicates "%x04" bit for "publisher discovery", 940 the node receiving the Request message examines whether it owns 941 the requested content as the publisher. If it is the publisher, 942 it sends the Reply message with own Report block and sub-block. 943 If the node is not the publisher but know the upstream neighbor 944 router(s) for the specified name prefix, it adds the own Report 945 block and forwards the Request to the neighbor(s). If the node 946 is not the publisher and does not know the upstream neighbor 947 router(s) for the specified name prefix, it replies the CCNinfo 948 Reply message with NO_ROUTE return code. 950 5. When a router receives a CCNinfo Request in which the "gateway 951 discovery" flag (i.e., "%x16") is set in the Flags field and a 952 scheme name is specified, the router examines whether it has the 953 FIB for the specified scheme name and the connections with the 954 neighbor router(s) for the scheme protocol. If the router is the 955 gateway, it sends the Reply message back toward the CCNinfo user. 956 If the router does not have the FIB for the specified scheme name 957 or does not connect to any neighbor router for the specified 958 scheme name, the router returns the Reply with NO_GATEWAY return 959 code. 961 5.2. Forwarding CCNinfo Request 963 When a router decides to forward a Request message with its Report 964 block to its upstream router(s), it specifies the Request Arrival 965 Time and Node Identifier in the Report block of the Request message. 966 The router then forwards the Request message upstream toward the 967 publisher or caching router based on the FIB entry. 969 When the router forwards the Request message, it MUST record the 970 Request ID at the corresponding PIT entry. The router can later 971 decide the PIT entry to correctly forward back the Reply message even 972 if it receives multiple Reply messages within the same timeout 973 period. (See below.) 975 CCNinfo supports multipath forwarding. The Request messages can be 976 forwarded to multiple neighbor routers. Some router may have 977 strategy for multipath forwarding; when it sends Interest messages to 978 multiple neighbor routers, it may delay or prioritize to send the 979 message to the upstream routers. The CCNinfo Request, as the 980 default, complies with such strategy; a CCNinfo user could trace the 981 actual forwarding path based on the strategy. On the other hand, 982 there may be the case that a CCNinfo user wants to discover all 983 potential forwarding paths based on routers' FIBs. If a CCNinfo user 984 invokes a CCNinfo Request with the parallel request flag (i.e., 985 "%x08" bit as seen in Figure 10), the forwarding strategy will be 986 ignored and the router sends Requests to multiple upstream routers 987 simultaneously, and the CCNinfo user could trace the all potential 988 forwarding paths. Note that this flag may be ignored according to 989 the router's policy. 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 8.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.3. 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 and Reply sub- 1009 block to the payload. The router does not insert any Reply block/ 1010 sub-block if there is an error. The router finally changes the Type 1011 field in the fixed header from PT_REQUEST to PT_REPLY and forwards 1012 the message back as the Reply toward the CCNinfo user in a hop-by-hop 1013 manner. 1015 When a router decides to send the Reply message for the Request for 1016 the cache or routing path information discovery, it forms the Reply 1017 message including a Reply block and a Reply sub-block with the 1018 T_DISC_CONTENT type value (Figure 15) and various cache information. 1019 After the router puts the NO_ERROR return code in the fixed header, 1020 it sends the Reply back toward the CCNinfo user. 1022 When a router decides to send the Reply message for the Request for 1023 the publisher discovery, it forms the Reply message including a Reply 1024 block and a Reply sub-block with the T_DISC_CONTENT_OWNER type value 1025 (Figure 15) and various cache information. After the router puts the 1026 NO_ERROR return code in the fixed header, it sends the Reply back 1027 toward the CCNinfo user. 1029 When a router decides to send the Reply message for the Request for 1030 the gateway discovery, it forms the Reply message including a Reply 1031 block and a Reply sub-block with the T_DISC_GATEWAY type value 1032 (Figure 16) and the scheme name (Figure 9). After the router puts 1033 the NO_ERROR return code in the fixed header, it sends the Reply back 1034 toward the CCNinfo user. 1036 If a router cannot continue the Request, it MUST put an appropriate 1037 ReturnCode in the Request message, change the Type field value in the 1038 fixed header from PT_REQUEST to PT_REPLY, and forward the Reply 1039 message back toward the CCNinfo user, to terminate the request. See 1040 Section 7. 1042 5.4. Forwarding CCNinfo Reply 1044 When a router receives a CCNinfo Reply whose Request ID matches the 1045 one in the original CCNinfo Request block TLV from a valid adjacent 1046 neighbor node, it MUST relay the CCNinfo Reply back to the CCNinfo 1047 user. If the router does not receive the corresponding Reply within 1048 the [CCNinfo Reply Timeout] period, then it removes the corresponding 1049 PIT entry and terminates the trace. 1051 CCNinfo Replies MUST NOT be cached in routers upon the Reply message 1052 transmission. 1054 6. Publisher Behavior 1056 Upon receiving a CCNinfo Request message, a publisher MUST examine 1057 whether the message comes from a valid adjacent neighbor node. If it 1058 is invalid, the Request SHOULD be silently ignored. 1060 If a publisher cannot accept the Request, it will note an appropriate 1061 ReturnCode in the Request message, change the Type field value in the 1062 fixed header from PT_REQUEST to PT_REPLY, and forward the message as 1063 the Reply back to the CCNinfo user. See Section 7 for details. 1065 If a publisher accepts the Request forwarded by a valid adjacent 1066 neighbor node, it retrieves the local content information. The Reply 1067 message having a Reply block and Reply sub-block is transmitted back 1068 to the neighbor node that had forwarded the Request message. 1070 7. CCNinfo Termination 1072 When performing an expanding hop-by-hop trace, it is necessary to 1073 determine when to stop expanding. There are several cases an 1074 intermediate router might return a Reply before a Request reaches the 1075 caching router or the publisher. 1077 7.1. Arriving at Publisher or Gateway 1079 A CCNinfo Request can be determined to have arrived at the publisher 1080 or gateway. 1082 7.2. Arriving at Router Having Cache 1084 A CCNinfo Request can be determined to have arrived at the router 1085 having the specified content cache within the specified HopLimit. 1087 7.3. No Route 1089 If the router cannot determine the routing paths or neighbor routers 1090 for the specified name prefix, device name, or function within the 1091 specified HopLimit, the router MUST note a ReturnCode of NO_ROUTE in 1092 the fixed header of the message, and forwards the message as the 1093 Reply back to the CCNinfo user. 1095 7.4. No Information 1097 If the router does not have any information about the specified name 1098 prefix, device name, or function within the specified HopLimit, the 1099 router MUST note a ReturnCode of NO_INFO in the fixed header of the 1100 message, and forwards the message as the Reply back to the CCNinfo 1101 user. 1103 7.5. No Space 1105 If appending the Report block would make the CCNinfo Request packet 1106 longer than the MTU of the Incoming face, or longer than 1280 bytes 1107 (especially in the situation supporting IPv6 as the payload [3]), the 1108 router MUST note a ReturnCode of NO_SPACE in the fixed header of the 1109 message, and forwards the message as the Reply back to the CCNinfo 1110 user. 1112 7.6. Fatal Error 1114 A CCNinfo Request has encountered a fatal error if the last 1115 ReturnCode in the trace has the 0x80 bit set (see Section 3.1). 1117 7.7. CCNinfo Reply Timeout 1119 If a router receives the Request or Reply message that expires its 1120 own [CCNinfo Reply Timeout] value (Section 8.1), the router will 1121 discard the Request or Reply message. 1123 7.8. Non-Supported Node 1125 Cases will arise in which a router or a publisher along the path does 1126 not support CCNinfo. In such cases, a CCNinfo user and routers that 1127 forward the CCNinfo Request will time out the CCNinfo request. 1129 7.9. Administratively Prohibited 1131 If CCNinfo is administratively prohibited, a router or a publisher 1132 rejects the Request message, and the router or the publisher, or its 1133 downstream router will reply the CCNinfo Reply with the ReturnCode of 1134 ADMIN_PROHIB. 1136 8. Configurations 1138 8.1. CCNinfo Reply Timeout 1140 The [CCNinfo Reply Timeout] value is used to time out a CCNinfo 1141 Reply. The value for a router can be statically configured by the 1142 router's administrators/operators. The default value is 4 (seconds). 1143 The [CCNinfo Reply Timeout] value SHOULD NOT be larger than 5 1144 (seconds) and SHOULD NOT be lower than 2 (seconds). 1146 8.2. HopLimit in Fixed Header 1148 If a CCNinfo user does not specify the HopLimit value in a fixed 1149 header for a Request message as the HopLimit, the HopLimit is set to 1150 32. Note that 0 HopLimit is an invalid Request and hence discarded. 1152 8.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 9. Diagnosis and Analysis 1160 9.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 9.2. Caching Router and Gateway Identification 1169 It is possible to identify the caching routers or a gateway in the 1170 path from the CCNinfo user to the content forwarder, while some 1171 routers may hide their identifier (with all-zeros) in the Report 1172 blocks (Section 10.1). 1174 9.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 9.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 9.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 9.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 10. Security Considerations 1205 This section addresses some of the security considerations. 1207 10.1. Policy-Based Information Provisioning for Request 1209 Although CCNinfo gives excellent troubleshooting cues, some network 1210 administrators or operators may not want to disclose everything about 1211 their network to the public, or may wish to securely transmit private 1212 information to specific members of their networks. CCNinfo provides 1213 policy-based information provisioning allowing network administrators 1214 to specify their response policy for each router. 1216 The access policy regarding "who is allowed to retrieve" and/or "what 1217 kind of information" can be defined for each router. For the former 1218 access policy, routers having the specified content can examine the 1219 signature enclosed in the Request message and decide whether they 1220 should notify the content information in the Reply or not. If the 1221 routers decide to not notify the content information, they reply the 1222 CCNinfo Reply with the ReturnCode of ADMIN_PROHIB without appending 1223 any Reply (sub-)block TLV. For the latter policy, the permission, 1224 whether (1) All (all cache information is disclosed), (2) Partial 1225 (cache information with the particular name prefix can (or cannot) be 1226 disclosed), or (3) Deny (no cache information is disclosed), is 1227 defined at routers. 1229 On the other hand, we entail that each router does not disrupt 1230 forwarding CCNinfo Request and Reply messages. When a Request 1231 message is received, the router SHOULD insert Report block. Here, 1232 according to the policy configuration, the Node Identifier field in 1233 the Report block MAY be null (i.e., all-zeros), but the Request 1234 Arrival Time field SHOULD NOT be null. At last, the router SHOULD 1235 forward the Request message to the upstream router toward the content 1236 forwarder if no fatal error occurs. 1238 10.2. Filtering of CCNinfo Users Located in Invalid Networks 1240 A router MAY support an access control mechanism to filter out 1241 Requests from invalid CCNinfo users. For it, invalid networks (or 1242 domains) could, for example, be configured via a list of allowed/ 1243 disallowed networks (as seen in Section 8.3). If a Request is 1244 received from the disallowed network (according to the Node 1245 Identifier in the Request block), the Request SHOULD NOT be processed 1246 and the Reply with the ReturnCode of INFO_HIDDEN may be used to note 1247 that. The router MAY, however, perform rate limited logging of such 1248 events. 1250 10.3. Topology Discovery 1252 CCNinfo can be used to discover actively-used topologies. If a 1253 network topology is a secret, CCNinfo Requests may be restricted at 1254 the border of the domain, using the ADMIN_PROHIB return code. 1256 10.4. Characteristics of Content 1258 CCNinfo can be used to discover what publishers are sending to what 1259 kinds of contents. If this information is a secret, CCNinfo Requests 1260 may be restricted at the border of the domain, using the ADMIN_PROHIB 1261 return code. 1263 10.5. Longer or Shorter CCNinfo Reply Timeout 1265 Routers can configure the CCNinfo Reply Timeout (Section 8.1), which 1266 is the allowable timeout value to keep the PIT entry. If routers 1267 configure the longer timeout value, there may be an attractive attack 1268 vector against PIT memory. Moreover, especially when the parallel 1269 request option (Section 5.2) is specified for the CCNinfo Request, a 1270 number of Reply messages may come back and cause a response storm. 1271 (See Section 10.7 for rate limiting to avoid the storm). In order to 1272 avoid DoS attacks, routers may configure the shorter timeout value 1273 than the user-configured CCNinfo timeout value. However, if it is 1274 too short, the Request may be timed out and the CCNinfo user does not 1275 receive the all Replies and only retrieves the partial path 1276 information (i.e., information about part of the tree). 1278 There may be the way to allow for incremental exploration (i.e., to 1279 explore the part of the tree the previous operation did not explore), 1280 whereas discussing such mechanism is out of scope of this document. 1282 10.6. Limiting Request Rates 1284 A router may limit CCNinfo Requests by ignoring some of the 1285 consecutive messages. The router MAY randomly ignore the received 1286 messages to minimize the processing overhead, i.e., to keep fairness 1287 in processing requests, or prevent traffic amplification. No error 1288 is returned. The rate limit is left to the router's implementation. 1290 10.7. Limiting Reply Rates 1292 CCNinfo supporting multipath forwarding may result in one Request 1293 returning multiple Reply messages. In order to prevent abuse, the 1294 routers in the traced path MAY need to rate-limit the Replies. No 1295 error is returned. The rate limit function is left to the router's 1296 implementation. 1298 10.8. Adjacency Verification 1300 CCNinfo Request and Reply messages MUST be forwarded by adjacent 1301 neighbor nodes or routers. Forwarding CCNinfo messages given from 1302 non-adjacent neighbor nodes/routers MUST be prohibited. Such invalid 1303 messages SHOULD be silently discarded. Note that defining the secure 1304 way to verify the adjacency cannot rely on the way specified in CCNx 1305 message format or semantics. An adjacency verification mechanism and 1306 the corresponding TLV for adjacency verification using hop-by-hop TLV 1307 header will be defined in a separate document. 1309 11. Acknowledgements 1311 The authors would like to thank Spyridon Mastorakis, Ilya Moiseenko, 1312 and David Oran for their valuable comments and suggestions on this 1313 document. 1315 12. References 1317 12.1. Normative References 1319 [1] Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 1320 Format", draft-irtf-icnrg-ccnxmessages-07 (work in 1321 progress), March 2018. 1323 [2] Bradner, S., "Key words for use in RFCs to indicate 1324 requirement levels", RFC 2119, March 1997. 1326 [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1327 (IPv6) Specification", RFC 8200, July 2017. 1329 12.2. Informative References 1331 [4] Asaeda, H., Matsuzono, K., and T. Turletti, "Contrace: A 1332 Tool for Measuring and Tracing Content-Centric Networks", 1333 IEEE Communications Magazine, Vol.53, No.3, pp.182-188, 1334 March 2015. 1336 [5] Malkin, G., "Traceroute Using an IP Option", RFC 1393, 1337 January 1993. 1339 [6] Asaeda, H., Mayer, K., and W. Lee, "Mtrace Version 2: 1340 Traceroute Facility for IP Multicast", draft-ietf-mboned- 1341 mtrace-v2-24 (work in progress), June 2018. 1343 Appendix A. ccninfo Command and Options 1345 The ccninfo command enables the CCNinfo user to investigate the 1346 routing path based on the name prefix of the content (e.g., 1347 ccn:/news/today), device name, and function (or application) name. 1348 The name prefix, device name, and function name (or application name) 1349 are mandatory but exclusive options; that is, only one of them should 1350 be used with the ccninfo command at once. 1352 The usage of ccninfo command is as follows: 1354 Usage: ccninfo [-P] [-g] [-f] [-n] [-o] [-r hop_count] [-s hop_count] 1355 name_prefix; or, 1357 Usage: ccninfo [-r hop_count] [-s hop_count] device_name | 1358 function_name (or application_name) 1360 name_prefix 1361 Name prefix of the content (e.g., ccn:/news/today) the CCNinfo 1362 user wants to trace. If the CCNinfo user specifies only a scheme 1363 name, e.g., "ccn:/", s/he must specify "-g" option (i.e., ccninfo 1364 -g ccn:/). In that case, the CCNinfo user discovers the router 1365 having the FIB of the specified scheme name and the RTT between 1366 CCNinfo user and the router. The "-P" option allows a partial 1367 match for the name prefix; otherwise, an exact match is required. 1369 device_name 1370 Device name (e.g., ccn:/%device/server-A, ccn:/%device/sensor-123) 1371 the CCNinfo user wants to trace. Here, we assume the ccninfo 1372 command with the "%device" prefix indicates the trace request for 1373 specified device/server/node, but defining the syntax of device 1374 name specification is [TBD]. 1376 function_name (or application_name) 1377 Function name (e.g., ccn:/%function/firewall, 1378 ccn:/%function/transcoding/mpeg2-h.264) or application name (e.g., 1379 ccn:/%application/mplayer) the CCNinfo user wants to trace. Here, 1380 we assume the ccninfo command with the "%function" or 1381 "%application" prefix indicates the trace request for specified 1382 function or application, but defining the syntax of function or 1383 application name specification is [TBD]. 1385 g option 1386 This option enables to discover a gateway that supports specified 1387 scheme name and has multiple FIBs. When a CCNinfo user specifies 1388 only a scheme name, e.g., "ccn:/", this option must be specified 1389 and other content name prefix is ignored. 1391 f option 1392 This option enables to ignore the forwarding strategy and send 1393 CCNinfo Requests to multiple upstream routers simultaneously. The 1394 CCNinfo user could then trace the all potential forwarding paths. 1396 n option 1397 This option can be specified if a CCNinfo user only needs the 1398 routing path information to the specified content/cache and RTT 1399 between CCNinfo user and content forwarder (i.e., cache 1400 information is not given). 1402 o option 1403 This option enables to trace the path to the content publisher. 1404 If this option is specified, each router along the path to the 1405 publisher only forwards the Request message; it inserts each 1406 Report block but does not send Reply even if it caches the 1407 specified content. The publisher (who has the complete set of 1408 content and is not a caching router) replies the Reply message. 1409 Specifying only a scheme name is not allowed with this option. 1411 r option 1412 Number of traced routers. If the CCNinfo user specifies this 1413 option, only the specified number of hops from the CCNinfo user 1414 trace the Request; each router inserts its own Report block and 1415 forwards the Request message to the upstream router(s), and the 1416 last router stops the trace and sends the Reply message back to 1417 the CCNinfo user. This value is set in the "HopLimit" field 1418 located in the fixed header of the Request. For example, when the 1419 CCNinfo user invokes the CCNinfo command with this option such as 1420 "-r 3", only three routers along the path examine their path and 1421 cache information. If there is a caching router within the hop 1422 count along the path, the caching router sends back the Reply 1423 message and terminates the trace request. If the last router does 1424 not have the corresponding cache, it replies the Reply message 1425 with NO_INFO return code (described in Section 3.1) with no Reply 1426 block TLV inserted. The Request messages are terminated at 1427 publishers; therefore, although the maximum value for this option 1428 a CCNinfo user can specify is 255, the Request messages should be 1429 in general reached at the publisher within significantly lower 1430 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 publishers; therefore, although the maximum 1445 value for this option a CCNinfo user can specify is 255, if the 1446 Request messages reaches the publisher, the publisher silently 1447 discards the Request message and the request will be timed out. 1449 Appendix B. Change History 1451 This document was created based on the previous "Contrace" document 1452 whose initial version had been published on October 31, 2016. 1454 Authors' Addresses 1456 Hitoshi Asaeda 1457 National Institute of Information and Communications Technology 1458 4-2-1 Nukui-Kitamachi 1459 Koganei, Tokyo 184-8795 1460 Japan 1462 Email: asaeda@nict.go.jp 1464 Xun Shao 1465 Kitami Institute of Technology 1466 165 Koen-cho 1467 Kitami, Hokkaido 090-8507 1468 Japan 1470 Email: x-shao@mail.kitami-it.ac.jp