idnits 2.17.1 draft-asaeda-icnrg-contrace-04.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 (October 28, 2017) is 2371 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 1381 -- Looks like a reference, but probably isn't: '-g' on line 1381 -- Looks like a reference, but probably isn't: '-f' on line 1381 -- Looks like a reference, but probably isn't: '-n' on line 1381 -- Looks like a reference, but probably isn't: '-o' on line 1381 -- Looks like a reference, but probably isn't: 'TBD' on line 1411 == Outdated reference: A later version (-09) exists of draft-irtf-icnrg-ccnxmessages-04 ** Obsolete normative reference: RFC 2460 (ref. '3') (Obsoleted by RFC 8200) -- 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-17 Summary: 2 errors (**), 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 X. Shao 4 Intended status: Experimental NICT 5 Expires: May 1, 2018 T. Turletti 6 Inria 7 October 28, 2017 9 Contrace: Traceroute Facility for Content-Centric Network 10 draft-asaeda-icnrg-contrace-04 12 Abstract 14 This document describes the traceroute facility for Content-Centric 15 Network (CCN), named "Contrace". Contrace investigates: 1) the 16 routing path information per name prefix, device name, and function/ 17 application, 2) the Round-Trip Time (RTT) between content forwarder 18 and consumer, and 3) the states of in-network cache per name prefix. 19 In addition, it discovers a gateway that supports different protocols 20 such as CCN and NDN. 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 May 1, 2018. 39 Copyright Notice 41 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . 6 59 3. Contrace Message Formats . . . . . . . . . . . . . . . . . . 7 60 3.1. Request Message . . . . . . . . . . . . . . . . . . . . . 8 61 3.1.1. Request Block . . . . . . . . . . . . . . . . . . . . 10 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. Contrace User Behavior . . . . . . . . . . . . . . . . . . . 19 67 4.1. Sending Contrace Request . . . . . . . . . . . . . . . . 19 68 4.1.1. Gateway Discovery . . . . . . . . . . . . . . . . . . 19 69 4.1.2. Routing Path Information . . . . . . . . . . . . . . 20 70 4.1.3. In-Network Cache Information . . . . . . . . . . . . 20 71 4.2. Receiving Contrace Reply . . . . . . . . . . . . . . . . 20 72 5. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 21 73 5.1. Receiving Contrace Request . . . . . . . . . . . . . . . 21 74 5.1.1. Request Packet Verification . . . . . . . . . . . . . 21 75 5.1.2. Request Normal Processing . . . . . . . . . . . . . . 21 76 5.2. Forwarding Contrace Request . . . . . . . . . . . . . . . 22 77 5.3. Sending Contrace Reply . . . . . . . . . . . . . . . . . 23 78 5.4. Forwarding Contrace Reply . . . . . . . . . . . . . . . . 24 79 6. Publisher Behavior . . . . . . . . . . . . . . . . . . . . . 24 80 7. Contrace Termination . . . . . . . . . . . . . . . . . . . . 25 81 7.1. Arriving at Publisher or Gateway . . . . . . . . . . . . 25 82 7.2. Arriving at Router Having Cache . . . . . . . . . . . . . 25 83 7.3. No Route . . . . . . . . . . . . . . . . . . . . . . . . 25 84 7.4. No Information . . . . . . . . . . . . . . . . . . . . . 25 85 7.5. No Space . . . . . . . . . . . . . . . . . . . . . . . . 25 86 7.6. Fatal Error . . . . . . . . . . . . . . . . . . . . . . . 25 87 7.7. Contrace Reply Timeout . . . . . . . . . . . . . . . . . 26 88 7.8. Non-Supported Node . . . . . . . . . . . . . . . . . . . 26 89 7.9. Administratively Prohibited . . . . . . . . . . . . . . . 26 90 8. Configurations . . . . . . . . . . . . . . . . . . . . . . . 26 91 8.1. Contrace Reply Timeout . . . . . . . . . . . . . . . . . 26 92 8.2. HopLimit in Fixed Header . . . . . . . . . . . . . . . . 26 93 8.3. Access Control . . . . . . . . . . . . . . . . . . . . . 26 94 9. Diagnosis and Analysis . . . . . . . . . . . . . . . . . . . 27 95 9.1. Number of Hops . . . . . . . . . . . . . . . . . . . . . 27 96 9.2. Caching Router and Gateway Identification . . . . . . . . 27 97 9.3. TTL or Hop Limit . . . . . . . . . . . . . . . . . . . . 27 98 9.4. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 27 99 9.5. Path Stretch . . . . . . . . . . . . . . . . . . . . . . 27 100 9.6. Cache Hit Probability . . . . . . . . . . . . . . . . . . 27 101 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 102 10.1. Policy-Based Information Provisioning for Request . . . 28 103 10.2. Filtering of Contrace Users Located in Invalid Networks 28 104 10.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 29 105 10.4. Characteristics of Content . . . . . . . . . . . . . . . 29 106 10.5. Longer or Shorter Contrace Reply Timeout . . . . . . . . 29 107 10.6. Limiting Request Rates . . . . . . . . . . . . . . . . . 29 108 10.7. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 29 109 10.8. Adjacency Verification . . . . . . . . . . . . . . . . . 30 110 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 111 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 112 12.1. Normative References . . . . . . . . . . . . . . . . . . 30 113 12.2. Informative References . . . . . . . . . . . . . . . . . 30 114 Appendix A. Contrace Command and Options . . . . . . . . . . . . 31 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 117 1. Introduction 119 In Content-Centric Network (CCN) or Named-Data Network (NDN), 120 publishers provide content through the network, and receivers 121 retrieve content by name. In this network architecture, routers 122 forward content requests by means of their Forwarding Information 123 Bases (FIBs), which are populated by name-based routing protocols. 124 CCN/NDN also enables receivers to retrieve content from an in-network 125 cache. 127 In CCN/NDN, while consumers do not generally need to know which 128 content forwarder is transmitting the content to them, operators and 129 developers may want to identify the content forwarder and observe the 130 routing path information per name prefix for troubleshooting or 131 investigating the network conditions. 133 Traceroute [5] is a useful tool for analyzing the routing conditions 134 in IP networks as it provides intermediate router addresses along the 135 path between source and destination and the Round-Trip Time (RTT) for 136 the path. However, this IP-based network tool cannot trace the name 137 prefix paths used in CCN/NDN. Moreover, given a source-rooted 138 routing path per name prefix, specifying a forwarding source (i.e., 139 router or publisher) for any content is difficult, because we do not 140 always know which branch of the source tree the consumer is on. 141 Additionally, it is not feasible to flood the entire source-rooted 142 tree to find the path from a source to a consumer. Furthermore, such 143 IP-based network tool does not allow the states of the in-network 144 cache to be discovered. 146 This document describes the specification of "Contrace", an active 147 network measurement tool for investigating the path and caching 148 condition in CCN. Contrace potentially discovers devices and 149 functions/applications in CCN. Contrace is designed based on the 150 work originally published in [4]. 152 Contrace consists of the Contrace user command and the Contrace 153 forwarding function implementation on a content forwarder (e.g., 154 router). The Contrace user (e.g., consumer) invokes the contrace 155 command (described in Appendix A) with the name prefix of the 156 content, the device name, or the function (or application) name. The 157 Contrace command initiates the Contrace "Request" message (described 158 in Section 3.1). The Request message, for example, obtains routing 159 path and cache information. When an appropriate adjacent neighbor 160 router receives the Request message, it retrieves cache information. 161 If the router is not the content forwarder for the request, it 162 inserts its "Report" block (described in Section 3.1.2) into the 163 Request message and forwards the Request message to its upstream 164 neighbor router(s) decided by its FIB. These two message types, 165 Contrace Request and Reply messages, are encoded in the CCNx TLV 166 format [1]. 168 In this way, the Contrace Request message is forwarded by routers 169 toward the content publisher, and the Contrace Report record is 170 inserted by each intermediate router. When the Request message 171 reaches the content forwarder (i.e., a router or the publisher who 172 has the specified cache or content), the content forwarder forms the 173 Contrace "Reply" message (described in Section 3.2) and sends it to 174 the downstream neighbor router. The Reply message is forwarded back 175 toward the Contrace user in a hop-by-hop manner. This request-reply 176 message flow, walking up the tree from a consumer toward a publisher, 177 is inspired by the design of the IP multicast traceroute facility 178 [6]. 180 Contrace supports multipath forwarding. The Request messages can be 181 forwarded to multiple neighbor routers. When the Request messages 182 forwarded to multiple routers, the different Reply messages will be 183 forwarded from different routers or publisher. To support this case, 184 PIT entries initiated by Contrace remain until the defined timeout 185 value is expired. 187 1. Request 2. Request 3. Request 4. Request 188 (+U) (U+A) (U+A+B) (U+A+B+C) 189 +----+ +----+ +----+ +----+ 190 | | | | | | | | 191 | v | v | v | v 192 +--------+ +--------+ +--------+ +--------+ +---------+ 193 |Contrace|----| Router |----| Router |----| Router |----|Publisher| 194 | user | | A | | B | | C | | | 195 +--------+ +--------+ +--------+ +--------+ +---------+ 196 \ 197 \ +-------+ 198 3. Request \ | Cache | 199 (U+A+B) \ +---------+ | 200 v| Caching |----+ 201 | router | 202 +---------+ 204 Figure 1: Request messages forwarded by consumer and routers. 205 Contrace user and routers (i.e., Router A,B,C) insert their own 206 Report blocks into the Request message and forward the message toward 207 the content forwarder (i.e., caching router and publisher) 209 3. Reply(C) 2. Reply(C) 210 4. Reply(P) 3. Reply(P) 2. Reply(P) 1. Reply(P) 211 +----+ +----+ +----+ +----+ 212 | | | | | | | | 213 v | v | v | v | 214 +--------+ +--------+ +--------+ +--------+ +---------+ 215 |Contrace|----| Router |----| Router |----| Router |----|Publisher| 216 | user | | A | | B | | C | | | 217 +--------+ +--------+ +--------+ +--------+ +---------+ 218 ^ 219 \ +-------+ 220 1. Reply(C) \ | Cache | 221 \ +---------+ | 222 \| Caching |----+ 223 | router | 224 +---------+ 226 Figure 2: Reply messages forwarded by publisher and routers. Each 227 router forwards the Reply message, and finally the Contrace user 228 receives two Reply messages: one from the publisher and the other 229 from the caching router. 231 Contrace facilitates the tracing of a routing path and provides: 1) 232 the RTT between content forwarder (i.e., caching router or publisher) 233 and consumer, 2) the states of in-network cache per name prefix, and 234 3) the routing path information per name prefix. 236 In addition, Contrace identifies the states of the cache, such as the 237 following metrics for Content Store (CS) in the content forwarder: 1) 238 size of the cached content, 2) number of the cached chunks of the 239 content, 3) number of the accesses (i.e., received Interests) per 240 cache or chunk, and 4) lifetime and expiration time per cache or 241 chunk. The number of received Interests per cache or chunk on the 242 routers indicates the popularity of the content. 244 Furthermore, Contrace implements policy-based information 245 provisioning that enables administrators to "hide" secure or private 246 information, but does not disrupt the forwarding of messages. This 247 policy-based information provisioning reduces the deployment barrier 248 faced by operators in installing and running Contrace on their 249 routers. 251 2. Terminology 253 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 254 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 255 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2], 256 and indicate requirement levels for compliant Contrace 257 implementations. 259 2.1. Definitions 261 Since Contrace requests flow in the opposite direction to the data 262 flow, we refer to "upstream" and "downstream" with respect to data, 263 unless explicitly specified. 265 Router 266 It is a router facilitating name-based content/device/function 267 name or characteristic retrieval in the path between consumer and 268 publisher. 270 Scheme name 271 It indicates a URI and protocol such as "ccnx:/" and "ndn:/". 272 This document considers the protocol for name-based 273 content/device/function name or characteristic retrieval. 275 Gateway 276 It is a router supporting multiple scheme names in the path 277 between consumer and publisher. The router has multiple FIBs for 278 different protocols and establishes the connections with different 279 neighbor routers for each protocol. 281 Node 282 It is a router, gateway, publisher, or consumer. 284 Content forwarder 285 It is either a caching router or a publisher that holds the cache 286 (or content) and forwards it to consumers. 288 Contrace user 289 It is a node that invokes the contrace command and initiates the 290 Contrace Request. 292 Incoming face 293 The face on which data is expected to arrive from the specified 294 name prefix. 296 Outgoing face 297 The face to which data from the publisher or router is expected to 298 transmit for the specified name prefix. It is also the face on 299 which the Contrace Request messages are received. 301 3. Contrace Message Formats 303 Contrace uses two message types: Request and Reply. Both messages 304 are encoded in the CCNx TLV format ([1], Figure 3). The Request 305 message consists of a fixed header, Request block TLV Figure 7, and 306 Report block TLV(s) Figure 11. The Reply message consists of a fixed 307 header, Request block TLV, Report block TLV(s), and Reply block/sub- 308 block TLV(s) Figure 14. 310 1 2 3 311 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 312 +---------------+---------------+---------------+---------------+ 313 | Version | PacketType | PacketLength | 314 +---------------+---------------+---------------+---------------+ 315 | PacketType specific fields | HeaderLength | 316 +---------------+---------------+---------------+---------------+ 317 / Optional Hop-by-hop header TLVs / 318 +---------------+---------------+---------------+---------------+ 319 / PacketPayload TLVs / 320 +---------------+---------------+---------------+---------------+ 321 / Optional CCNx ValidationAlgorithm TLV / 322 +---------------+---------------+---------------+---------------+ 323 / Optional CCNx ValidationPayload TLV (ValidationAlg required) / 324 +---------------+---------------+---------------+---------------+ 326 Figure 3: Packet format [1] 328 The Request and Reply Type values in the fixed header are PT_REQUEST 329 and PT_REPLY, respectively (Figure 4). These messages are forwarded 330 in a hop-by-hop manner. When the Request message reaches the content 331 forwarder, the content forwarder turns the Request message into a 332 Reply message by changing the Type field value in the fixed header 333 from PT_REQUEST to PT_REPLY and forwards back to the node that has 334 initiated the Request message. 336 Code Type name 337 ======== ===================== 338 1 PT_INTEREST [1] 339 2 PT_CONTENT [1] 340 3 PT_RETURN [1] 341 4 PT_REQUEST 342 5 PT_REPLY 344 Figure 4: Packet Type Namespace 346 Each Contrace message MUST begin with a fixed header with either a 347 Request or Reply type value to specify whether it is a Request 348 message or Reply message. Following a fixed header, there can be a 349 sequence of optional hop-by-hop header TLV(s) for a Request message. 350 In the case of a Request message, it is followed by a sequence of 351 Report blocks, each from a router on the path toward the publisher or 352 caching router. 354 At the beginning of PacketPayload TLVs, one top-level TLV type, 355 T_TRACE (Figure 5), exists at the outermost level of a CCNx protocol 356 message. This TLV indicates that the Name segment TLV(s) and Reply 357 block TLV(s) would follow in the Request or Reply message. 359 Code Type name 360 ======== ========================= 361 1 T_INTEREST [1] 362 2 T_OBJECT [1] 363 3 T_VALIDATION_ALG [1] 364 4 T_VALIDATION_PAYLOAD [1] 365 5 T_PING 366 6 T_TRACE 368 Figure 5: Top-Level Type Namespace 370 3.1. Request Message 372 When a Contrace user initiates a trace request (e.g., by contrace 373 command described in Appendix A), a Contrace Request message is 374 created and forwarded to its upstream router through the Incoming 375 face(s) determined by its FIB. 377 The Contrace Request message format is as shown in Figure 6. It 378 consists of a fixed header, Request block TLV (Figure 7), Report 379 block TLV(s) (Figure 11), and Name TLV. The Type value of Top-Level 380 type namespace is T_TRACE (Figure 5). The Type value for the Report 381 message is PT_REQUEST. 383 1 2 3 384 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 385 +---------------+---------------+---------------+---------------+ 386 | Version | PacketType | PacketLength | 387 +---------------+---------------+---------------+---------------+ 388 | HopLimit | ReturnCode |Reserved (MBZ) | HeaderLength | 389 +===============+===============+===============+===============+ 390 | | 391 + Request block TLV + 392 | | 393 +---------------+---------------+---------------+---------------+ 394 / Report block TLV 1 / 395 +---------------+---------------+---------------+---------------+ 396 / Report block TLV 2 / 397 +---------------+---------------+---------------+---------------+ 398 / . / 399 / . / 400 +---------------+---------------+---------------+---------------+ 401 / Report block TLV n / 402 +===============+===============+===============+===============+ 403 | T_TRACE | MessageLength | 404 +---------------+---------------+---------------+---------------+ 405 | T_NAME | Length | 406 +---------------+---------------+---------------+---------------+ 407 / Name segment TLVs (name prefix specified by contrace command) / 408 +---------------+---------------+---------------+---------------+ 410 Figure 6: Request message consists of a fixed header, Request block 411 TLV, Report block TLV(s), and Name TLV 413 HopLimit: 8 bits 415 HopLimit is a counter that is decremented with each hop. It 416 limits the distance a Request may travel on the network. 418 ReturnCode: 8 bits 420 ReturnCode is used for the Reply message. This value is replaced 421 by the content forwarder when the Request message is returned as 422 the Reply message (see Section 3.2). Until then, this field MUST 423 be transmitted as zeros and ignored on receipt. 425 Value Name Description 426 ----- --------------- ---------------------------------------------- 427 0x00 NO_ERROR No error 428 0x01 WRONG_IF Contrace Request arrived on an interface 429 to which this router would not forward for 430 the specified name/function toward the 431 publisher. 432 0x02 INVALID_REQUEST Invalid Contrace Request is received. 433 0x03 NO_ROUTE This router has no route for the name prefix 434 and no way to determine a potential route. 435 0x04 NO_INFO This router has no cache information for the 436 specified name prefix, device information, or 437 function. 438 0x05 NO_SPACE There was not enough room to insert another 439 Report block in the packet. 440 0x06 NO_GATAWAY Contrace Request arrived on a non-gateway 441 router. 442 0x07 INFO_HIDDEN Information is hidden from this trace because 443 of some policy. 444 0x0E ADMIN_PROHIB Contrace Request is administratively 445 prohibited. 446 0x0F UNKNOWN_REQUEST This router does not support/recognize the 447 Request message. 448 0x80 FATAL_ERROR A fatal error is one where the router may 449 know the upstream router but cannot forward 450 the message to it. 452 Reserved (MBZ): 8 bits 454 The reserved fields in the Value field MUST be transmitted as 455 zeros and ignored on receipt. 457 3.1.1. Request Block 459 When a Contrace user transmits the Request message, it MUST insert 460 the Request block TLV (Figure 7) and the Report block TLV (Figure 11) 461 of its own to the Request message before sending it through the 462 Incoming face(s). 464 1 2 3 465 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 466 +---------------+---------------+---------------+---------------+ 467 | T_TRACE_REQ | Length | 468 +---------------+---------------+-----+-------------------------+ 469 | SchemeName | SkipHopCount |TimeO| Reserved (MBZ) | 470 +---------------+---------------+-----+-------------------------+ 471 | Request ID | Flags | 472 +---------------+---------------+-------------------------------+ 474 Figure 7: Request block TLV (hop-by-hop header) 476 Code Type name 477 ============= ===================== 478 1 T_INTLIFE [1] 479 2 T_CACHETIME [1] 480 3 T_MSGHASH [1] 481 4 - 7 Reserved [1] 482 8 T_TRACE_REQ 483 9 T_TRACE_REPORT 484 %x0FFE T_PAD [1] 485 %x0FFF T_ORG [1] 486 %x1000-%x1FFF Reserved [1] 488 Figure 8: Hop-by-Hop Type Namespace 490 Type: 16 bits 492 Format of the Value field. For the single Request block TLV, the 493 type value MUST be T_TRACE_REQ. For all the available types for 494 hop-by-hop type namespace, please see Figure 8. 496 Length: 16 bits 498 Length of Value field in octets. For the Request block, it MUST 499 be 4 in the current specification. 501 SchemeName: 8 bits 503 Currently, the following scheme names are defined. 505 Code Scheme name 506 ============= =============== 507 0 ccnx:/ 508 1 ndn:/ 509 2 cefore:/ 510 %x03-%FF Not assigned 512 Figure 9: Scheme Names 514 SkipHopCount: 8 bits 516 Number of skipped routers. This value MUST be lower than the 517 value of HopLimit at the fixed header. 519 TimeO: 3 bits 521 Timeout value (seconds). This Timeout value means a [Contrace 522 Reply Timeout] value (seconds) requested by the Contrace user 523 later described in Section 8.1. A Contrace user requests routers 524 along the path to keep the PIT entry for the Request until this 525 timeout value expires. Note that, because of some security 526 concern (Section 10.5), a router along the path may configure the 527 shorter timeout value than this requested timeout value. In that 528 case, the Request may be timed out and the Contrace user may not 529 receive the Reply as expected. 531 Request ID: 16 bits 533 This field is used as a unique identifier for this Contrace 534 Request so that duplicate or delayed Reply messages can be 535 detected. 537 Flags: 16 bits 539 The trace conditions specified as the contrace command options 540 (described in Appendix A) are transferred in the Flags field. The 541 trace conditions depend on the specified name (i.e., name_prefix, 542 device_name, or function_name) as shown in Figure 10. Note that 543 code %x01 and %x02 are exclusive options; that is, only one of 544 them should be turned on at once. 546 Code Type name 547 ============ ===================================================== 548 %x01 Cache retrieval allowing partial match (name_prefix) 549 %x02 No cache information required (name_prefix) 550 %x04 Publisher reachability (name_prefix and device_name) 551 %x08 Force trace. Request to multiple upstream routers 552 simultaneously (name_prefix, device_name, and 553 function_name) 554 %x16 Discovery of gateway supporting specified scheme 555 name (name_prefix, device_name, and function_name) 556 %x32 Function's or application's version number retrieval 557 (function_name) 558 %x64-%x32768 Not assigned 560 Figure 10: Codes and types specified in Flags field 562 3.1.2. Report Block 564 A Contrace user and each upstream router along the path would insert 565 its own Report block TLV without changing the Type field of the fixed 566 header of the Request message until one of these routers is ready to 567 send a Reply. In the Report block TLV (Figure 11), the Request 568 Arrival Time and the Node Identifier MUST be inserted. 570 1 2 3 571 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 572 +---------------+---------------+---------------+---------------+ 573 | T_TRACE_REPORT | Length | 574 +---------------+---------------+---------------+---------------+ 575 | Request Arrival Time | 576 +---------------+---------------+---------------+---------------+ 577 / Node Identifier / 578 +---------------+---------------+---------------+---------------+ 580 Figure 11: Report block TLV (hop-by-hop header) 582 Type: 16 bits 584 Format of the Value field. For the Request block TLV(s), the type 585 value(s) MUST be T_TRACE_REPORT. 587 Length: 16 bits 589 Length of Value field in octets. 591 Request Arrival Time: 32 bits 592 The Request Arrival Time is a 32-bit NTP timestamp specifying the 593 arrival time of the Contrace Request packet at this router. The 594 32-bit form of an NTP timestamp consists of the middle 32 bits of 595 the full 64-bit form; that is, the low 16 bits of the integer part 596 and the high 16 bits of the fractional part. 598 The following formula converts from a UNIX timeval to a 32-bit NTP 599 timestamp: 601 request_arrival_time 602 = ((tv.tv_sec + 32384) << 16) + ((tv.tv_nsec << 7) / 1953125) 604 The constant 32384 is the number of seconds from Jan 1, 1900 to 605 Jan 1, 1970 truncated to 16 bits. ((tv.tv_nsec << 7) / 1953125) 606 is a reduction of ((tv.tv_nsec / 1000000000) << 16). 608 Note that Contrace does not require all the routers on the path to 609 have synchronized clocks in order to measure one-way latency. 611 Node Identifier: variable length 613 This field specifies the Contrace user or the router identifier 614 (e.g., IPv4 address) of the Incoming face on which packets from 615 the publisher are expected to arrive, or all-zeros if unknown or 616 unnumbered. Since we may not always rely on the IP addressing 617 architecture, it would be necessary to define the identifier 618 uniqueness (e.g., by specifying the protocol family) for this 619 field. However, defining such uniqueness is out of scope of this 620 document. Potentially, this field may be defined as a new TLV, 621 which might be defined in the document for the CCNx TLV format[1]. 623 3.2. Reply Message 625 When a content forwarder receives a Contrace Request message from the 626 appropriate adjacent neighbor router, it would insert a Reply block 627 TLV and Reply sub-block TLV(s) of its own to the Request message and 628 turn the Request into the Reply by changing the Type field of the 629 fixed header of the Request message from PT_REQUEST to PT_REPLY. The 630 Reply message (see Figure 12) would then be forwarded back toward the 631 Contrace user in a hop-by-hop manner. 633 1 2 3 634 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 635 +---------------+---------------+---------------+---------------+ 636 | Version | PacketType | PacketLength | 637 +---------------+---------------+---------------+---------------+ 638 | HopLimit | ReturnCode |Reserved (MBZ) | HeaderLength | 639 +===============+===============+===============+===============+ 640 | | 641 + Request block TLV + 642 | | 643 +---------------+---------------+---------------+---------------+ 644 / . / 645 / . / 646 / n Report block TLVs / 647 / . / 648 / . / 649 +===============+===============+===============+===============+ 650 | T_TRACE | MessageLength | 651 +---------------+---------------+---------------+---------------+ 652 | T_NAME | Length | 653 +---------------+---------------+---------------+---------------+ 654 / Name segment TLVs (name prefix specified by contrace command) / 655 +---------------+---------------+---------------+---------------+ 656 / Reply block TLV / 657 +---------------+---------------+---------------+---------------+ 658 / Reply sub-block TLV 1 / 659 +---------------+---------------+---------------+---------------+ 660 / Reply sub-block TLV 2 / 661 +---------------+---------------+---------------+---------------+ 662 / . / 663 / . / 664 +---------------+---------------+---------------+---------------+ 665 / Reply sub-block TLV k / 666 +---------------+---------------+---------------+---------------+ 668 Figure 12: Reply message consists of a fixed header, Request block 669 TLV, Report block TLV(s), Name TLV, and Reply block/sub-block TLV(s) 670 Code Type name 671 ============= ===================== 672 0 T_NAME [1] 673 1 T_PAYLOAD [1] 674 2 T_KEYIDRESTR [1] 675 3 T_OBJHASHRESTR [1] 676 5 T_PAYLDTYPE [1] 677 6 T_EXPIRY [1] 678 8 T_TRACE_REPLY 679 9 - 12 Reserved [1] 680 %x0FFE T_PAD [1] 681 %x0FFF T_ORG [1] 682 %x1000-%x1FFF Reserved [1] 684 Figure 13: CCNx Message Type Namespace 686 3.2.1. Reply Block 688 The Reply block TLV is an envelope for Reply sub-block TLV(s) 689 (explained in Section 3.2.1.1). 691 1 2 3 692 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 693 +---------------+---------------+---------------+---------------+ 694 | T_TRACE_REPLY | Length | 695 +---------------+---------------+---------------+---------------+ 697 Figure 14: Reply block TLV (packet payload) 699 Type: 16 bits 701 Format of the Value field. For the Report block TLV, the type 702 value MUST be T_TRACE_REPLY. 704 Length: 16 bits 706 Length of Value field in octets. This length is a total length of 707 Reply sub-block(s). 709 3.2.1.1. Reply Sub-Block 711 In addition to the Reply block, a router on the traced path will add 712 one or multiple Reply sub-blocks followed by the Reply block before 713 sending the Reply to its neighbor router. 715 The Reply sub-block is flexible for various purposes. For instance, 716 operators and developers may want to obtain various characteristics 717 of content such as content's ownership and copyright, or other cache 718 states and conditions. Various information about device or function 719 (or application) may be also retrieved by the variety of Reply sub- 720 blocks. In this document, Reply sub-block TLVs for T_TRACE_CONTENT 721 and T_TRACE_CONTENT_OWNER (Figure 15) and for T_TRACE_GATEWAY 722 (Figure 16) are defined; other Reply sub-block TLVs will be defined 723 in separate document(s). 725 1 2 3 726 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 727 +---------------+---------------+---------------+---------------+ 728 | Type | Length | 729 +---------------+---------------+---------------+---------------+ 730 | Content Size | 731 +---------------+---------------+---------------+---------------+ 732 | Object Count | 733 +---------------+---------------+---------------+---------------+ 734 | # Received Interest | 735 +---------------+---------------+---------------+---------------+ 736 | First Seqnum | 737 +---------------+---------------+---------------+---------------+ 738 | Last Seqnum | 739 +---------------+---------------+---------------+---------------+ 740 | Cache Lifetime | 741 +---------------+---------------+---------------+---------------+ 742 | Remain Cache Lifetime | 743 +---------------+---------------+---------------+---------------+ 744 | T_NAME | Length | 745 +---------------+---------------+---------------+---------------+ 746 / Name segment TLVs (name prefix partially/exactly matched) / 747 +---------------+---------------+---------------+---------------+ 749 Figure 15: Reply sub-block TLV for T_TRACE_CONTENT and 750 T_TRACE_CONTENT_OWNER (packet payload) 752 1 2 3 753 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 754 +---------------+---------------+---------------+---------------+ 755 | Type | Length | 756 +---------------+---------------+---------------+---------------+ 757 | Scheme Name | Reserved (MBZ) | 758 +---------------+---------------+---------------+---------------+ 760 Figure 16: Reply sub-block TLV for T_TRACE_GATEWAY (packet payload) 761 Code Type name 762 ============= =========================== 763 0 T_TRACE_CONTENT 764 1 T_TRACE_CONTENT_OWNER 765 2 T_TRACE_GATEWAY 766 3 T_TRACE_DEVICE 767 4 T_TRACE_FUNCTION 768 %x0FFF T_ORG 769 %x1000-%x1FFF Reserved (Experimental Use) 771 Figure 17: Contrace Reply Type Namespace 773 Type: 16 bits 775 Format of the Value field. For the Reply sub-block TLV, the type 776 value MUST be one of the type value defined in the Contrace Reply 777 Type Namespace (Figure 17). T_TRACE_CONTENT is specified when the 778 cache information is replied from a caching router. 779 T_TRACE_CONTENT_OWNER is specified when the content information is 780 replied from a publisher. T_TRACE_GATEWAY is used to discover a 781 gateway that has a FIB for the specified scheme name. 783 Length: 16 bits 785 Length of Value field in octets. 787 Scheme Name: 8 bits 789 The code of the scheme name defined in Figure 9. 791 Content Size: 32 bits 793 The total size (MB) of the (cached) content objects. Note that 794 the maximum size expressed by 32 bit field is 65 GB. 796 Object Count: 32 bits 798 The number of the (cached) content objects. 800 # Received Interest: 32 bits 802 The number of the received Interest messages to retrieve the 803 content. 805 First Seqnum: 32 bits 807 The first sequential number of the (cached) content objects. 809 Last Seqnum: 32 bits 811 The last sequential number of the (cached) content objects. Above 812 First Seqnum and this Last Seqnum do not guarantee the 813 consecutiveness of the cached content objects. 815 Cache Lifetime: 32 bits 817 The elapsed time after the oldest content object in the cache is 818 stored. The Cache Lifetime is a 32-bit NTP timestamp, and the 819 formula converts from a UNIX timeval to a 32-bit NTP timestamp is 820 same as that of Section 3.1.2. 822 Remain Cache Lifetime: 32 bits 824 The lifetime of a content object, which is removed first among the 825 cached content objects. The Remain Cache Lifetime is a 32-bit NTP 826 timestamp. 828 4. Contrace User Behavior 830 4.1. Sending Contrace Request 832 A Contrace user initiates a Contrace Request by sending the Request 833 message to the adjacent neighbor router(s) of interest. As a typical 834 example, a Contrace user invokes the contrace command (detailed in 835 Appendix A) that forms a Request message and sends it to the user's 836 adjacent neighbor router(s). 838 When the Contrace user's program initiates a Request message, it MUST 839 insert the necessary values, the "Request ID" (in the Request block) 840 and the "Node Identifier" (in the Report block), in the Request and 841 Report blocks. Contrace user's program MUST also record the Request 842 ID at the corresponding PIT entry. The Request ID is a unique 843 identifier for the Contrace Request. 845 After the Contrace user's program sends the Request message, until 846 the Reply times out, the Contrace user's program MUST keep the 847 following information; Request ID and Flags specified in the Request 848 block, Node Identifier and Request Arrival Time specified in the 849 Report block, and HopLimit specified in the fixed header. 851 4.1.1. Gateway Discovery 853 A Contrace Request can be used for gateway discovery; if a Contrace 854 user invokes a Contrace Request with a scheme name (e.g., ccnx:/ or 855 ndn:/) and the "gateway discovery" flag value (i.e., "%x16" bit as 856 seen in Figure 10), s/he could potentially discover a gateway that 857 supports different protocols such as CCN and NDN. The Contrace 858 Request for gateway discovery only indicates the routing path 859 information (see Section 4.1.2) and the scheme name whether the 860 router is a gateway or not; it does not provide other information, 861 e.g., cache information. 863 4.1.2. Routing Path Information 865 A Contrace user can send a Contrace Request for investigating routing 866 path information for the specified named content. By the Request, 867 the legitimate user can obtain; 1) identifiers (e.g., IP addresses) 868 of intermediate routers, 2) identifier of content forwarder, 3) 869 number of hops between content forwarder and consumer, and 4) RTT 870 between content forwarder and consumer, per name prefix. This 871 Contrace Request is terminated when it reaches the content forwarder. 872 The contrace command enables user to obtain both the routing path 873 information and in-network cache information (see below) in a same 874 time. 876 4.1.3. In-Network Cache Information 878 A Contrace user can send a Contrace Request for investigating in- 879 network cache information. By this Request, the legitimate user can 880 obtain; 1) size of the cached content, 2) number of the cached chunks 881 of the content, 3) number of the accesses (i.e., received Interests) 882 per cache or chunk, and 4) lifetime and expiration time per cache or 883 chunk, for Content Store (CS) in the content forwarder. This 884 Contrace Request is terminated when it reaches the content forwarder. 886 4.2. Receiving Contrace Reply 888 A Contrace user's program will receive one or multiple Contrace Reply 889 messages from the adjacent neighbor router that has previously 890 received and forwarded the Request message(s). When the program 891 receives the Reply, it MUST compare the kept Request ID and the 892 Request ID noted in the Reply. If they do not match, the Reply 893 message SHOULD be silently discarded. 895 If the number of the Report blocks in the received Reply is more than 896 the initial HopLimit value (which was inserted in the original 897 Request) + 1, the Reply SHOULD be silently ignored. 899 After the Contrace user has determined that s/he has traced the whole 900 path or as much as s/he can expect to, s/he might collect statistics 901 by waiting a timeout. Useful statistics provided by Contrace can be 902 seen in Section 9. 904 5. Router Behavior 906 5.1. Receiving Contrace Request 908 5.1.1. Request Packet Verification 910 Upon receiving a Contrace Request message, a router MUST examine 911 whether the message comes from a valid adjacent neighbor node. If it 912 is invalid, the Request MUST be silently ignored. The router next 913 examines the value of the "HopLimit" in the fixed header and the 914 value of the "SkipHopCount" in the Request block (Figure 7). If 915 SkipHopCount value is equal or more than the HopLimit value, the 916 Request MUST be silently ignored. 918 5.1.2. Request Normal Processing 920 When a router receives a Contrace Request message, it performs the 921 following steps. 923 1. HopLimit and SkipHopCount are counters that are decremented with 924 each hop. The router terminates the Contrace Request when the 925 HopLimit value becomes zero. Until the SkipHopCount value 926 becomes zero, the router forwards the Contrace Request messages 927 to the upstream router(s) (if it knows) without adding its own 928 Report block and without replying the Request. If the router 929 does not know the upstream router(s), without depending on the 930 SkipHopCount value, it replies the Contrace Reply message with 931 NO_ROUTE return code. 933 2. The router examines the Flags field of the Request block of 934 received Contrace Request. If the flag value indicates "%x00" or 935 "%x01" bit (as seen in Figure 10) for "cache information 936 discovery", the router examines its FIB and CS. If the router 937 caches the specified content, it inserts own Report block to the 938 message and sends the Reply message with own Reply block and sub- 939 block. If the router does not cache the specified content but 940 knows the neighbor router(s) for the specified name prefix, it 941 inserts own Report block and forwards the Request to the upstream 942 neighbor(s). If the router does not cache the specified content 943 and does not know the upstream neighbor router(s) for the 944 specified name prefix, it replies the Contrace Reply message with 945 NO_ROUTE return code. 947 3. If the flag value indicates "%x02" bit for "routing path 948 information discovery", the router examines its FIB and CS. If 949 the router caches the specified content, it inserts own Report 950 block to the message and sends the Reply message with own Reply 951 block. The router does not insert any Reply sub-block here. If 952 the router does not cache the specified content but knows the 953 neighbor router(s) for the specified name prefix, it inserts own 954 Report block and forwards the Request to the upstream 955 neighbor(s). If the router does not cache the specified content 956 and does not know the upstream neighbor router(s) for the 957 specified name prefix, it replies the Contrace Reply message with 958 NO_ROUTE return code. 960 4. If the flag value indicates "%x04" bit for "publisher discovery", 961 the node receiving the Request message examines whether it owns 962 the requested content as the publisher. If it is the publisher, 963 it sends the Reply message with own Report block and sub-block. 964 If the node is not the publisher but know the upstream neighbor 965 router(s) for the specified name prefix, it adds the own Report 966 block and forwards the Request to the neighbor(s). If the node 967 is not the publisher and does not know the upstream neighbor 968 router(s) for the specified name prefix, it replies the Contrace 969 Reply message with NO_ROUTE return code. 971 5. When a router receives a Contrace Request in which the "gateway 972 discovery" flag (i.e., "%x16") is set in the Flags field and a 973 scheme name is specified, the router examines whether it has the 974 FIB for the specified scheme name and the connections with the 975 neighbor router(s) for the scheme protocol. If the router is the 976 gateway, it sends the Reply message back toward the Contrace 977 user. If the router does not have the FIB for the specified 978 scheme name or does not connect to any neighbor router for the 979 specified scheme name, the router returns the Reply with 980 NO_GATEWAY return code. 982 5.2. Forwarding Contrace Request 984 When a router decides to forward a Request message with its Report 985 block to its upstream router(s), it specifies the Request Arrival 986 Time and Node Identifier in the Report block of the Request message. 987 The router then forwards the Request message upstream toward the 988 publisher or caching router based on the FIB entry. 990 When the router forwards the Request message, it MUST record the 991 Request ID at the corresponding PIT entry. The router can later 992 decide the PIT entry to correctly forward back the Reply message even 993 if it receives multiple Reply messages within the same timeout 994 period. (See below.) 996 Contrace supports multipath forwarding. The Request messages can be 997 forwarded to multiple neighbor routers. Some router may have 998 strategy for multipath forwarding; when it sends Interest messages to 999 multiple neighbor routers, it may delay or prioritize to send the 1000 message to the upstream routers. The Contrace Request, as the 1001 default, complies with such strategy; a Contrace user could trace the 1002 actual forwarding path based on the strategy. On the other hand, 1003 there may be the case that a Contrace user wants to discover all 1004 potential forwarding paths based on routers' FIBs. If a Contrace 1005 user invokes a Contrace Request with the force flag value (i.e., 1006 "%x08" bit as seen in Figure 10), the forwarding strategy will be 1007 ignored and the router sends Requests to multiple upstream routers 1008 simultaneously, and the Contrace user could trace the all potential 1009 forwarding paths. 1011 When the Request messages forwarded to multiple routers, the 1012 different Reply messages will be forwarded from different routers or 1013 publisher. To support this case, PIT entries initiated by Contrace 1014 remain until the configured Contrace Reply Timeout (Section 8.1) 1015 passes. In other words, unlike the ordinary Interest-Data 1016 communications in CCN, the router SHOULD NOT remove the PIT entry 1017 created by the Contrace Request before the timeout value expires, 1018 even if the router receives the Contrace Reply. 1020 Contrace Requests SHOULD NOT result in PIT aggregation in routers 1021 during the Request message transmission. 1023 5.3. Sending Contrace Reply 1025 When a router decides to send a Reply message to its downstream 1026 neighbor router or the Contrace user with NO_ERROR return code, it 1027 inserts a Report block having the Request Arrival Time and Node 1028 Identifier to the hop-by-hop TLV header of the Request message. And 1029 then the router inserts the corresponding Reply block and Reply sub- 1030 block to the payload. The router does not insert any Reply block/ 1031 sub-block if there is an error. The router finally changes the Type 1032 field in the fixed header from PT_REQUEST to PT_REPLY and forwards 1033 the message back as the Reply toward the Contrace user in a hop-by- 1034 hop manner. 1036 When a router decides to send the Reply message for the Request for 1037 the cache or routing path information discovery, it forms the Reply 1038 message including a Reply block and a Reply sub-block with the 1039 T_TRACE_CONTENT type value (Figure 15) and various cache information. 1040 After the router puts the NO_ERROR return code in the fixed header, 1041 it sends the Reply back toward the Contrace user. 1043 When a router decides to send the Reply message for the Request for 1044 the publisher discovery, it forms the Reply message including a Reply 1045 block and a Reply sub-block with the T_TRACE_CONTENT_OWNER type value 1046 (Figure 15) and various cache information. After the router puts the 1047 NO_ERROR return code in the fixed header, it sends the Reply back 1048 toward the Contrace user. 1050 When a router decides to send the Reply message for the Request for 1051 the gateway discovery, it forms the Reply message including a Reply 1052 block and a Reply sub-block with the T_TRACE_GATEWAY type value 1053 (Figure 16) and the scheme name (Figure 9). After the router puts 1054 the NO_ERROR return code in the fixed header, it sends the Reply back 1055 toward the Contrace user. 1057 If a router cannot continue the Request, it MUST put an appropriate 1058 ReturnCode in the Request message, change the Type field value in the 1059 fixed header from PT_REQUEST to PT_REPLY, and forward the Reply 1060 message back toward the Contrace user, to terminate the request. See 1061 Section 7. 1063 5.4. Forwarding Contrace Reply 1065 When a router receives a Contrace Reply whose Request ID matches the 1066 one in the original Contrace Request block TLV from a valid adjacent 1067 neighbor node, it MUST relay the Contrace Reply back to the Contrace 1068 user. If the router does not receive the corresponding Reply within 1069 the [Contrace Reply Timeout] period, then it removes the 1070 corresponding PIT entry and terminates the trace. 1072 Contrace Replies MUST NOT be cached in routers upon the Reply message 1073 transmission. 1075 6. Publisher Behavior 1077 Upon receiving a Contrace Request message, a publisher MUST examine 1078 whether the message comes from a valid adjacent neighbor node. If it 1079 is invalid, the Request SHOULD be silently ignored. 1081 If a publisher cannot accept the Request, it will note an appropriate 1082 ReturnCode in the Request message, change the Type field value in the 1083 fixed header from PT_REQUEST to PT_REPLY, and forward the message as 1084 the Reply back to the Contrace user. See Section 7 for details. 1086 If a publisher accepts the Request forwarded by a valid adjacent 1087 neighbor node, it retrieves the local content information. The Reply 1088 message having a Reply block and Reply sub-block is transmitted back 1089 to the neighbor node that had forwarded the Request message. 1091 7. Contrace Termination 1093 When performing an expanding hop-by-hop trace, it is necessary to 1094 determine when to stop expanding. There are several cases an 1095 intermediate router might return a Reply before a Request reaches the 1096 caching router or the publisher. 1098 7.1. Arriving at Publisher or Gateway 1100 A Contrace Request can be determined to have arrived at the publisher 1101 or gateway. 1103 7.2. Arriving at Router Having Cache 1105 A Contrace Request can be determined to have arrived at the router 1106 having the specified content cache within the specified HopLimit. 1108 7.3. No Route 1110 If the router cannot determine the routing paths or neighbor routers 1111 for the specified name prefix, device name, or function within the 1112 specified HopLimit, the router MUST note a ReturnCode of NO_ROUTE in 1113 the fixed header of the message, and forwards the message as the 1114 Reply back to the Contrace user. 1116 7.4. No Information 1118 If the router does not have any information about the specified name 1119 prefix, device name, or function within the specified HopLimit, the 1120 router MUST note a ReturnCode of NO_INFO in the fixed header of the 1121 message, and forwards the message as the Reply back to the Contrace 1122 user. 1124 7.5. No Space 1126 If appending the Report block would make the Contrace Request packet 1127 longer than the MTU of the Incoming face, or longer than 1280 bytes 1128 (especially in the situation supporting IPv6 as the payload [3]), the 1129 router MUST note a ReturnCode of NO_SPACE in the fixed header of the 1130 message, and forwards the message as the Reply back to the Contrace 1131 user. 1133 7.6. Fatal Error 1135 A Contrace Request has encountered a fatal error if the last 1136 ReturnCode in the trace has the 0x80 bit set (see Section 3.1). 1138 7.7. Contrace Reply Timeout 1140 If a Contrace user or a router encounters the Request or Reply 1141 message whose expires its own [Contrace Reply Timeout] value 1142 (Section 8.1), which is used to time out a Contrace Reply such as the 1143 case of Section 7.8. 1145 7.8. Non-Supported Node 1147 Cases will arise in which a router or a publisher along the path does 1148 not support Contrace. In such cases, a Contrace user and routers 1149 that forward the Contrace Request will time out the Contrace request. 1151 7.9. Administratively Prohibited 1153 If Contrace is administratively prohibited, a router or a publisher 1154 rejects the Request message, and the router or the publisher, or its 1155 downstream router will reply the Contrace Reply with the ReturnCode 1156 of ADMIN_PROHIB. 1158 8. Configurations 1160 8.1. Contrace Reply Timeout 1162 The [Contrace Reply Timeout] value is used to time out a Contrace 1163 Reply. Both Contrace users and routers can configure their own 1164 Contrace Reply Timeout values. Contrace users, for example, can 1165 configure the timeout value by the contrace command. The default 1166 [Contrace Reply Timeout] value is 4 (seconds). Routers may want to 1167 configure the short timeout values because of some security concern, 1168 e.g., Section 10.5. However, the [Contrace Reply Timeout] value 1169 SHOULD NOT be larger than 6 (seconds) and SHOULD NOT be lower than 3 1170 (seconds). 1172 8.2. HopLimit in Fixed Header 1174 If a Contrace user does not specify the HopLimit value in a fixed 1175 header for a Request message as the HopLimit, the HopLimit is set to 1176 32. Note that a Contrace user specifies 0 as the HopLimit, it is an 1177 invalid Request and discarded. 1179 8.3. Access Control 1181 A router MAY configure the valid or invalid networks to enable an 1182 access control. The access control can be defined per name prefix, 1183 such as "who can retrieve which name prefix". See Section 10.2. 1185 9. Diagnosis and Analysis 1187 9.1. Number of Hops 1189 A Contrace Request message is forwarded in a hop-by-hop manner and 1190 each forwarding router appended its own Report block. We can then 1191 verify the number of hops to reach the content forwarder or the 1192 publisher. 1194 9.2. Caching Router and Gateway Identification 1196 It is possible to identify the caching routers or a gateway in the 1197 path from the Contrace user to the content forwarder, while some 1198 routers may hide their identifier (with all-zeros) in the Report 1199 blocks (Section 10.1). 1201 9.3. TTL or Hop Limit 1203 By taking the HopLimit from the content forwarder and forwarding TTL 1204 threshold over all hops, it is possible to discover the TTL or hop 1205 limit required for the content forwarder to reach the Contrace user. 1207 9.4. Time Delay 1209 If the routers have synchronized clocks, it is possible to estimate 1210 propagation and queuing delay from the differences between the 1211 timestamps at successive hops. However, this delay includes control 1212 processing overhead, so is not necessarily indicative of the delay 1213 that data traffic would experience. 1215 9.5. Path Stretch 1217 By getting the path stretch "d / P", where "d" is the hop count of 1218 the data and "P" is the hop count from the consumer to the publisher, 1219 we can measure the improvement in path stretch in various cases, such 1220 as different caching and routing algorithms. We can then facilitate 1221 investigation of the performance of the protocol. 1223 9.6. Cache Hit Probability 1225 Contrace can show the number of received interests per cache or chunk 1226 on a router. By this, Contrace measures the content popularity 1227 (i.e., the number of accesses for each content/cache), and you can 1228 investigate the routing/caching strategy in networks. 1230 10. Security Considerations 1232 This section addresses some of the security considerations. 1234 10.1. Policy-Based Information Provisioning for Request 1236 Although Contrace gives excellent troubleshooting cues, some network 1237 administrators or operators may not want to disclose everything about 1238 their network to the public, or may wish to securely transmit private 1239 information to specific members of their networks. Contrace provides 1240 policy-based information provisioning allowing network administrators 1241 to specify their response policy for each router. 1243 The access policy regarding "who is allowed to retrieve" and/or "what 1244 kind of information" can be defined for each router. For the former 1245 access policy, routers having the specified content can examine the 1246 signature enclosed in the Request message and decide whether they 1247 should notify the content information in the Reply or not. If the 1248 routers decide to not notify the content information, they reply the 1249 Contrace Reply with the ReturnCode of ADMIN_PROHIB without appending 1250 any Reply (sub-)block TLV. For the latter policy, the permission, 1251 whether (1) All (all cache information is disclosed), (2) Partial 1252 (cache information with the particular name prefix can (or cannot) be 1253 disclosed), or (3) Deny (no cache information is disclosed), is 1254 defined at routers. 1256 On the other hand, we entail that each router does not disrupt 1257 forwarding Contrace Request and Reply messages. When a Request 1258 message is received, the router SHOULD insert Report block. Here, 1259 according to the policy configuration, the Node Identifier field in 1260 the Report block MAY be null (i.e., all-zeros), but the Request 1261 Arrival Time field SHOULD NOT be null. At last, the router SHOULD 1262 forward the Request message to the upstream router toward the content 1263 forwarder if no fatal error occurs. 1265 10.2. Filtering of Contrace Users Located in Invalid Networks 1267 A router MAY support an access control mechanism to filter out 1268 Requests from invalid Contrace users. For it, invalid networks (or 1269 domains) could, for example, be configured via a list of allowed/ 1270 disallowed networks (as seen in Section 8.3). If a Request is 1271 received from the disallowed network (according to the Node 1272 Identifier in the Request block), the Request SHOULD NOT be processed 1273 and the Reply with the ReturnCode of INFO_HIDDEN may be used to note 1274 that. The router MAY, however, perform rate limited logging of such 1275 events. 1277 10.3. Topology Discovery 1279 Contrace can be used to discover actively-used topologies. If a 1280 network topology is a secret, Contrace Requests may be restricted at 1281 the border of the domain, using the ADMIN_PROHIB return code. 1283 10.4. Characteristics of Content 1285 Contrace can be used to discover what publishers are sending to what 1286 kinds of contents. If this information is a secret, Contrace 1287 Requests may be restricted at the border of the domain, using the 1288 ADMIN_PROHIB return code. 1290 10.5. Longer or Shorter Contrace Reply Timeout 1292 Routers can configure the Contrace Reply Timeout (Section 8.1), which 1293 is the allowable timeout value to keep the PIT entry. If routers 1294 configure the longer timeout value, there may be an attractive attack 1295 vector against PIT memory. Moreover, especially when the force 1296 option (Section 5.2) is specified for the Contrace Request, a number 1297 of Reply messages may come back and cause a response storm. (See 1298 Section 10.7 for rate limiting to avoid the storm). In order to 1299 avoid DoS attacks, routers may configure the shorter timeout value 1300 than the user-configured Contrace timeout value. However, if it is 1301 too short, the Request may be timed out and the Contrace user does 1302 not receive the all Replies and only retrieves the partial path 1303 information (i.e., information about part of the tree). 1305 There may be the way to allow for incremental exploration (i.e., to 1306 explore the part of the tree the previous operation did not explore), 1307 whereas discussing such mechanism is out of scope of this document. 1309 10.6. Limiting Request Rates 1311 A router may limit Contrace Requests by ignoring some of the 1312 consecutive messages. The router MAY randomly ignore the received 1313 messages to minimize the processing overhead, i.e., to keep fairness 1314 in processing requests, or prevent traffic amplification. No error 1315 is returned. The rate limit is left to the router's implementation. 1317 10.7. Limiting Reply Rates 1319 Contrace supporting multipath forwarding may result in one Request 1320 returning multiple Reply messages. In order to prevent abuse, the 1321 routers in the traced path MAY need to rate-limit the Replies. No 1322 error is returned. The rate limit function is left to the router's 1323 implementation. 1325 10.8. Adjacency Verification 1327 Contrace Request and Reply messages MUST be forwarded by adjacent 1328 neighbor nodes or routers. Forwarding Contrace messages given from 1329 non-adjacent neighbor nodes/routers MUST be prohibited. Such invalid 1330 messages SHOULD be silently discarded. Note that defining the secure 1331 way to verify the adjacency cannot rely on the way specified in CCNx 1332 message format or semantics. An adjacency verification mechanism and 1333 the corresponding TLV for adjacency verification using hop-by-hop TLV 1334 header will be defined in a separate document. 1336 11. Acknowledgements 1338 The authors would like to thank Spyridon Mastorakis, Ilya Moiseenko, 1339 and David Oran for their valuable comments and suggestions on this 1340 document. 1342 12. References 1344 12.1. Normative References 1346 [1] Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 1347 Format", draft-irtf-icnrg-ccnxmessages-04 (work in 1348 progress), March 2017. 1350 [2] Bradner, S., "Key words for use in RFCs to indicate 1351 requirement levels", RFC 2119, March 1997. 1353 [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1354 (IPv6) Specification", RFC 2460, December 1998. 1356 12.2. Informative References 1358 [4] Asaeda, H., Matsuzono, K., and T. Turletti, "Contrace: A 1359 Tool for Measuring and Tracing Content-Centric Networks", 1360 IEEE Communications Magazine, Vol.53, No.3, pp.182-188, 1361 March 2015. 1363 [5] Malkin, G., "Traceroute Using an IP Option", RFC 1393, 1364 January 1993. 1366 [6] Asaeda, H., Mayer, K., and W. Lee, "Mtrace Version 2: 1367 Traceroute Facility for IP Multicast", draft-ietf-mboned- 1368 mtrace-v2-17 (work in progress), March 2017. 1370 Appendix A. Contrace Command and Options 1372 The contrace command enables the Contrace user to investigate the 1373 routing path based on the name prefix of the content (e.g., 1374 ccnx:/news/today), device name, and function (or application) name. 1375 The name prefix, device name, and function name (or application name) 1376 are mandatory but exclusive options; that is, only one of them should 1377 be used with the contrace command at once. 1379 The usage of contrace command is as follows: 1381 Usage: contrace [-P] [-g] [-f] [-n] [-o] [-r hop_count] [-s 1382 hop_count] [-w wait_time] name_prefix; or, 1384 Usage: contrace [-r hop_count] [-s hop_count] [-w wait_time] 1385 device_name | function_name (or application_name) 1387 name_prefix 1388 Name prefix of the content (e.g., ccnx:/news/today) the Contrace 1389 user wants to trace. If the Contrace user specifies only a scheme 1390 name, e.g., "ccnx:/", s/he must specify "-g" option (i.e., 1391 contrace -g ccnx:/). In that case, the Contrace user discovers 1392 the router having the FIB of the specified scheme name and the RTT 1393 between Contrace user and the router. The "-P" option allows a 1394 partial match for the name prefix; otherwise, an exact match is 1395 required. 1397 device_name 1398 Device name (e.g., ccnx:/%device/server-A, ccnx:/%device/sensor- 1399 123) the Contrace user wants to trace. Here, we assume the 1400 contrace command with the "%device" prefix indicates the trace 1401 request for specified device/server/node, but defining the syntax 1402 of device name specification is [TBD]. 1404 function_name (or application_name) 1405 Function name (e.g., ccnx:/%function/firewall, 1406 ccnx:/%function/transcoding/mpeg2-h.264) or application name 1407 (e.g., ccnx:/%application/mplayer) the Contrace user wants to 1408 trace. Here, we assume the contrace command with the "%function" 1409 or "%application" prefix indicates the trace request for specified 1410 function or application, but defining the syntax of function or 1411 application name specification is [TBD]. 1413 g option 1414 This option enables to discover a gateway that supports specified 1415 scheme name and has multiple FIBs. When a Contrace user specifies 1416 only a scheme name, e.g., "ccnx:/", this option must be specified 1417 and other content name prefix is ignored. 1419 f option 1420 This option enables to ignore the forwarding strategy and send 1421 Contrace Requests to multiple upstream routers simultaneously. 1422 The Contrace user could then trace the all potential forwarding 1423 paths. 1425 n option 1426 This option can be specified if a Contrace user only needs the 1427 routing path information to the specified content/cache and RTT 1428 between Contrace user and content forwarder (i.e., cache 1429 information is not given). 1431 o option 1432 This option enables to trace the path to the content publisher. 1433 If this option is specified, each router along the path to the 1434 publisher only forwards the Request message; it inserts each 1435 Report block but does not send Reply even if it caches the 1436 specified content. The publisher (who has the complete set of 1437 content and is not a caching router) replies the Reply message. 1438 Specifying only a scheme name is not allowed with this option. 1440 r option 1441 Number of traced routers. If the Contrace user specifies this 1442 option, only the specified number of hops from the Contrace user 1443 trace the Request; each router inserts its own Report block and 1444 forwards the Request message to the upstream router(s), and the 1445 last router stops the trace and sends the Reply message back to 1446 the Contrace user. This value is set in the "HopLimit" field 1447 located in the fixed header of the Request. For example, when the 1448 Contrace user invokes the Contrace command with this option such 1449 as "-r 3", only three routers along the path examine their path 1450 and cache information. If there is a caching router within the 1451 hop count along the path, the caching router sends back the Reply 1452 message and terminates the trace request. If the last router does 1453 not have the corresponding cache, it replies the Reply message 1454 with NO_INFO return code (described in Section 3.1) with no Reply 1455 block TLV inserted. The Request messages are terminated at 1456 publishers; therefore, although the maximum value for this option 1457 a Contrace user can specify is 255, the Request messages should be 1458 in general reached at the publisher within significantly lower 1459 than 255 hops. 1461 s option 1462 Number of skipped routers. If the Contrace user specifies this 1463 option, the number of hops from the Contrace user simply forward 1464 the Contrace Request messages without adding its own Report block 1465 and without replying the Request, and the next upstream router 1466 starts the trace. This value is set in the "SkipHopCount" field 1467 located in the Request block TLV. For example, when the Contrace 1468 user invokes the Contrace command with this option such as "-s 3", 1469 the three upstream routers along the path only forwards the 1470 Request message, but does not append their Report blocks in the 1471 hop-by-hop headers and does not send the Reply messages even 1472 though they have the corresponding cache. The Request messages 1473 are terminated at publishers; therefore, although the maximum 1474 value for this option a Contrace user can specify is 255, if the 1475 Request messages reaches the publisher, the publisher silently 1476 discards the Request message and the request will be timed out. 1478 w option 1479 This option defines the Contrace timeout value (in seconds) that 1480 the Contrace user will wait for the Reply. After the timeout, the 1481 Contrace user terminates the Request and silently discards the 1482 Reply message even if s/he receives the Reply. Note that routers 1483 along the path can configure the Contrace Reply Timeout 1484 Section 8.1, which is the allowable timeout value to keep the PIT 1485 entry. In order to avoid DoS attacks Section 10, routers MAY 1486 configure the shorter timeout value than the user-configured 1487 Contrace timeout value. If it is shorter, the Request may be 1488 timed out and the Contrace user may not receive the Reply as 1489 expected. 1491 Authors' Addresses 1493 Hitoshi Asaeda 1494 National Institute of Information and Communications Technology 1495 4-2-1 Nukui-Kitamachi 1496 Koganei, Tokyo 184-8795 1497 Japan 1499 Email: asaeda@nict.go.jp 1501 Xun Shao 1502 National Institute of Information and Communications Technology 1503 4-2-1 Nukui-Kitamachi 1504 Koganei, Tokyo 184-8795 1505 Japan 1507 Email: x-shao@nict.go.jp 1508 Thierry Turletti 1509 Inria 1510 2004 Route des Lucioles 1511 Sophia Antipolis 06902 1512 France 1514 Email: thierry.turletti@inria.fr