idnits 2.17.1 draft-irtf-icnrg-ccninfo-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 26, 2021) is 1005 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '-c' on line 1615 -- Looks like a reference, but probably isn't: '-f' on line 1615 -- Looks like a reference, but probably isn't: '-o' on line 1615 -- Looks like a reference, but probably isn't: '-V' on line 1615 == Outdated reference: A later version (-12) exists of draft-irtf-icnrg-icnping-02 == Outdated reference: A later version (-11) exists of draft-irtf-icnrg-icntraceroute-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group H. Asaeda 3 Internet-Draft A. Ooka 4 Intended status: Experimental NICT 5 Expires: January 27, 2022 X. Shao 6 Kitami Institute of Technology 7 July 26, 2021 9 CCNinfo: Discovering Content and Network Information in Content-Centric 10 Networks 11 draft-irtf-icnrg-ccninfo-08 13 Abstract 15 This document describes a mechanism named "CCNinfo" that discovers 16 information about the network topology and in-network cache in 17 Content-Centric Networks (CCN). CCNinfo investigates: 1) the CCN 18 routing path information per name prefix, 2) the Round-Trip Time 19 (RTT) between the content forwarder and consumer, and 3) the states 20 of in-network cache per name prefix. CCNinfo is useful to understand 21 and debug the behavior of testbed networks and other experimental 22 deployments of CCN systems. 24 This document is a product of the IRTF Information-Centric Networking 25 Research Group (ICNRG). This document represents the consensus view 26 of ICNRG and has been reviewed extensively by several members of the 27 ICN community and the RG. The authors and RG chairs approve of the 28 contents. The document is sponsored under the IRTF and is not issued 29 by the IETF and is not an IETF standard. This is an experimental 30 protocol and the specification may change in the future. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 27, 2022. 49 Copyright Notice 51 Copyright (c) 2021 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. CCNinfo as an Experimental Tool . . . . . . . . . . . . . 6 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 70 3. CCNinfo Message Formats . . . . . . . . . . . . . . . . . . . 8 71 3.1. Request Message . . . . . . . . . . . . . . . . . . . . . 9 72 3.1.1. Request Header Block and Request Block . . . . . . . 11 73 3.1.2. Report Block TLV . . . . . . . . . . . . . . . . . . 15 74 3.1.3. Content Name Specification . . . . . . . . . . . . . 16 75 3.2. Reply Message . . . . . . . . . . . . . . . . . . . . . . 16 76 3.2.1. Reply Block TLV . . . . . . . . . . . . . . . . . . . 17 77 3.2.1.1. Reply Sub-Block TLV . . . . . . . . . . . . . . . 18 78 4. CCNinfo User Behavior . . . . . . . . . . . . . . . . . . . . 21 79 4.1. Sending CCNinfo Request . . . . . . . . . . . . . . . . . 21 80 4.1.1. Routing Path Information . . . . . . . . . . . . . . 21 81 4.1.2. In-Network Cache Information . . . . . . . . . . . . 21 82 4.2. Receiving CCNinfo Reply . . . . . . . . . . . . . . . . . 22 83 5. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 22 84 5.1. User and Neighbor Verification . . . . . . . . . . . . . 22 85 5.2. Receiving CCNinfo Request . . . . . . . . . . . . . . . . 22 86 5.3. Forwarding CCNinfo Request . . . . . . . . . . . . . . . 24 87 5.3.1. Regular Request . . . . . . . . . . . . . . . . . . . 24 88 5.3.2. Full Discovery Request . . . . . . . . . . . . . . . 24 89 5.4. Sending CCNinfo Reply . . . . . . . . . . . . . . . . . . 25 90 5.5. Forwarding CCNinfo Reply . . . . . . . . . . . . . . . . 26 91 5.6. PIT Entry Management for Multipath Support . . . . . . . 26 92 6. CCNinfo Termination . . . . . . . . . . . . . . . . . . . . . 28 93 6.1. Arriving at First-hop Router . . . . . . . . . . . . . . 28 94 6.2. Arriving at Router Having Cache . . . . . . . . . . . . . 28 95 6.3. Arriving at Last Router . . . . . . . . . . . . . . . . . 28 96 6.4. Invalid Request . . . . . . . . . . . . . . . . . . . . . 28 97 6.5. No Route . . . . . . . . . . . . . . . . . . . . . . . . 28 98 6.6. No Information . . . . . . . . . . . . . . . . . . . . . 28 99 6.7. No Space . . . . . . . . . . . . . . . . . . . . . . . . 29 100 6.8. Fatal Error . . . . . . . . . . . . . . . . . . . . . . . 29 101 6.9. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 29 102 6.10. Non-Supported Node . . . . . . . . . . . . . . . . . . . 29 103 6.11. Administratively Prohibited . . . . . . . . . . . . . . . 29 104 7. Configurations . . . . . . . . . . . . . . . . . . . . . . . 29 105 7.1. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 30 106 7.2. HopLimit in Fixed Header . . . . . . . . . . . . . . . . 30 107 7.3. Access Control . . . . . . . . . . . . . . . . . . . . . 30 108 8. Diagnosis and Analysis . . . . . . . . . . . . . . . . . . . 30 109 8.1. Number of Hops and RTT . . . . . . . . . . . . . . . . . 30 110 8.2. Caching Router Identification . . . . . . . . . . . . . . 30 111 8.3. TTL or Hop Limit . . . . . . . . . . . . . . . . . . . . 30 112 8.4. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 30 113 8.5. Path Stretch . . . . . . . . . . . . . . . . . . . . . . 31 114 8.6. Cache Hit Probability . . . . . . . . . . . . . . . . . . 31 115 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 116 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 117 10.1. Policy-Based Information Provisioning for Request . . . 31 118 10.2. Filtering CCNinfo Users Located in Invalid Networks . . 32 119 10.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 32 120 10.4. Characteristics of Content . . . . . . . . . . . . . . . 32 121 10.5. Computational Attacks . . . . . . . . . . . . . . . . . 32 122 10.6. Longer or Shorter CCNinfo Reply Timeout . . . . . . . . 33 123 10.7. Limiting Request Rates . . . . . . . . . . . . . . . . . 33 124 10.8. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 33 125 10.9. Adjacency Verification . . . . . . . . . . . . . . . . . 33 126 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 127 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 128 12.1. Normative References . . . . . . . . . . . . . . . . . . 34 129 12.2. Informative References . . . . . . . . . . . . . . . . . 34 130 Appendix A. ccninfo Command and Options . . . . . . . . . . . . 35 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 133 1. Introduction 135 In Content-Centric Networks (CCN), publishers provide the content 136 through the network, and receivers retrieve it by name. In this 137 network architecture, routers forward content requests through their 138 Forwarding Information Bases (FIBs), which are populated by name- 139 based routing protocols. CCN also enables receivers to retrieve 140 content from an in-network cache. 142 In CCN, while consumers do not generally need to know the content 143 forwarder that is transmitting the content to them, the operators and 144 developers may want to identify the content forwarder and observe the 145 routing path information per name prefix for troubleshooting or 146 investigating the network conditions. 148 IP traceroute is a useful tool for discovering the routing conditions 149 in IP networks because it provides intermediate router addresses 150 along the path between the source and destination and the Round-Trip 151 Time (RTT) for the path. However, this IP-based network tool cannot 152 trace the name prefix paths used in CCN. Moreover, such IP-based 153 network tools do not obtain the states of the in-network cache to be 154 discovered. 156 Contrace [6] enables end users (i.e., consumers) to investigate path 157 and in-network cache conditions in CCN. Contrace is implemented as 158 an external daemon process running over TCP/IP that can interact with 159 a previous CCNx forwarding daemon (CCNx-0.8.2) to retrieve the 160 caching information on the forwarding daemon. This solution is 161 flexible, but it requires TCP/IP networks and defining the common 162 APIs for the global deployment. ICN ping [7] and traceroute [8] are 163 lightweight operational tools that enable a user to explore the 164 path(s) that reach a publisher or a cache storing the named content. 165 ICN ping and traceroute, however, do not exposes detailed information 166 about the forwarders deployed by a network operator. 168 This document describes the specifications of "CCNinfo", an active 169 networking tool for discovering the path and content caching 170 information in CCN. CCNinfo defines the protocol messages to 171 investigate path and in-network cache conditions in CCN. It is 172 embedded in the CCNx forwarding process and can facilitate with non- 173 IP networks as with the basic CCN concept. 175 The two message types, Request and Reply messages, are encoded in the 176 CCNx TLV format [1]. The request-reply message flow, walking up the 177 tree from a consumer toward a publisher, is similar to the behavior 178 of the IP multicast traceroute facility [9]. 180 CCNinfo facilitates the tracing of a routing path and provides: 1) 181 the RTT between the content forwarder (i.e., the caching or first-hop 182 router) and consumer, 2) the states of the in-network cache per name 183 prefix, and 3) the routing path information per name prefix. 185 In addition, CCNinfo identifies the states of the cache, such as the 186 following metrics for Content Store (CS) in the content forwarder: 1) 187 size of cached content objects, 2) number of cached content objects, 188 3) number of accesses (i.e., received Interests) per content, and 4) 189 elapsed cache time and remaining cache lifetime of content. 191 1. Request 2. Request 3. Request 192 (+U) (U+A) (U+A+B) 193 +----+ +----+ +----+ 194 | | | | | | 195 | v | v | v 196 +--------+ +--------+ +--------+ +--------+ +---------+ 197 | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| 198 | user | | A | | B | | C | | | 199 +--------+ +--------+ +--------+ +--------+ +---------+ 200 \ 201 \ +-------+ 202 3. Request \ | Cache | 203 (U+A+B) \ +---------+ | 204 v| Caching |----+ 205 | router | 206 +---------+ 208 Figure 1: Request messages forwarded by consumer and routers. 209 CCNinfo user and routers (i.e., Router A, B, C) insert their own 210 Report blocks into the Request message and forward the message toward 211 the content forwarder (i.e., caching router and publisher). 213 3. Reply(P) 2. Reply(P) 1. Reply(P) 214 +----+ +----+ +----+ 215 | | | | | | 216 v | v | v | 217 +--------+ +--------+ +--------+ +--------+ +---------+ 218 | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| 219 | user | | A | | B | | C | | | 220 +--------+ +--------+ +--------+ +--------+ +---------+ 221 ^ 222 \ +-------+ 223 1. Reply(C) \ | Cache | 224 \ +---------+ | 225 \| Caching |----+ 226 | router | 227 +---------+ 229 Figure 2: Default behavior. Reply messages forwarded by routers. 230 Each router forwards the Reply message along its PIT entry and 231 finally, the CCNinfo user receives a Reply message from Router C, 232 which is the first-hop router for the Publisher. Another Reply 233 message from the Caching router (i.e., Reply(C)) is discarded at 234 Router B when the other Reply message (i.e., Reply(P)) was already 235 forwarded by Router B. 237 CCNinfo supports multipath forwarding. The Request messages can be 238 forwarded to multiple neighbor routers. When the Request messages 239 are forwarded to multiple routers, the different Reply messages are 240 forwarded from different routers or publishers. 242 Furthermore, CCNinfo implements policy-based information provisioning 243 that enables administrators to "hide" secure or private information 244 but does not disrupt message forwarding. This policy-based 245 information provisioning reduces the deployment barrier faced by 246 operators in installing and running CCNinfo on their routers. 248 1.1. CCNinfo as an Experimental Tool 250 CCNinfo is intended as a comprehensive experimental tool for CCN 251 networks. It provides a wealth of information from CCN forwarders, 252 including on-path in-network cache conditions as well as forwarding 253 path instrumentation of multiple paths toward content forwarders. As 254 an experimental capability that exposes detailed information about 255 the forwarders deployed by a network operator, CCNinfo employs more 256 granular authorization policies than those required of ICN ping or 257 ICN traceroute. 259 Usually, the CCNinfo user (e.g., consumer) invokes the CCNinfo user 260 program (such as "ccninfo" command described in Appendix A) with the 261 name prefix of the content. The user program initiates the Request 262 message (described in Section 3.1) to obtain routing path and cache 263 information. When an appropriate adjacent neighbor router receives 264 the Request message, it retrieves own cache information. If the 265 router is not the content forwarder for the specified name prefix, it 266 inserts its Report block (described in Section 3.1.2) into the 267 Request message and forwards it to its upstream neighbor router(s) 268 decided by its FIB. 270 The Request message is forwarded by routers toward the content 271 publisher and the Report record is inserted by each intermediate 272 router. When the Request message reaches the content forwarder 273 (i.e., a router that can forward the specified content), the content 274 forwarder forms the Reply message (described in Section 3.2) and 275 sends it to the downstream neighbor router. The Reply message is 276 forwarded back toward the user in a hop-by-hop manner (along the PIT 277 entries). 279 In order to carry out meaningful experimentation with CCNx protocols, 280 comprehensive instrumentation and management information is needed to 281 take measurements and explore both the performance and robustness 282 characteristics of the protocols and of the applications using them. 283 CCNinfo's primary goal is to gather and report this information. As 284 experience is gained with both the CCNx protocols and CCNinfo itself, 285 we can refine the instrumentation capabilities and discover what 286 additional capabilities might be needed in CCNinfo and conversely 287 which features wind up not being of sufficient value to justify the 288 implementation complexity and execution overhead. 290 2. Terminology 292 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 293 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 294 "OPTIONAL" in this document are to be interpreted as described in BCP 295 14 (RFC2119 [3] and RFC8174 [4]) when, and only when, they appear in 296 all capitals, as shown here. 298 2.1. Definitions 300 This document follows the basic terminologies and definitions 301 described in [1]. Although CCNinfo requests flow in the opposite 302 direction to the data flow, we refer to "upstream" and "downstream" 303 with respect to data, unless explicitly specified. 305 Router 306 It is a router that facilitates CCN-based content retrieval in the 307 path between the consumer and publisher. 309 Scheme name 310 It indicates a URI and protocol. This document only considers 311 "ccnx:/" as the scheme name. 313 Prefix name 314 A prefix name, which is defined in [2], is a name that does not 315 uniquely identify a single content object, but rather a namespace 316 or prefix of an existing content object name. 318 Exact name 319 An exact name, which is defined in [2], is one that uniquely 320 identifies the name of a content object. 322 Node 323 It is a router, publisher, or consumer. 325 Content forwarder 326 It is either a caching router or a first-hop router that forwards 327 content objects to consumers. 329 CCNinfo user 330 It is a node that initiates the CCNinfo Request, which is usually 331 invoked by the user program (described in Appendix A) or other 332 similar commands. 334 Incoming face 335 The face on which data are expected to arrive from the specified 336 name prefix. 338 Outgoing face 339 The face to which data from the publisher or router are expected 340 to transmit for the specified name prefix. It is also the face on 341 which the Request messages are received. 343 Upstream router 344 The router that connects to an Incoming face of a router. 346 Downstream router 347 The router that connects to an Outgoing face of a router. 349 First-hop router (FHR) 350 The router that matches a FIB entry with an Outgoing face 351 referring to a local application or a publisher. 353 Last-hop router (LHR) 354 The router that is directly connected to a consumer. 356 3. CCNinfo Message Formats 358 CCNinfo uses two message types: Request and Reply. Both messages are 359 encoded in the CCNx TLV format ([1], Figure 3). The Request message 360 consists of a fixed header, Request block TLV (Figure 7), and Report 361 block TLV(s) (Figure 12). The Reply message consists of a fixed 362 header, Request block TLV, Report block TLV(s), and Reply block/sub- 363 block TLV(s) (Figure 14). 365 1 2 3 366 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 367 +---------------+---------------+---------------+---------------+ 368 | Version | PacketType | PacketLength | 369 +---------------+---------------+---------------+---------------+ 370 | PacketType specific fields | HeaderLength | 371 +---------------+---------------+---------------+---------------+ 372 / Optional Hop-by-hop header TLVs / 373 +---------------+---------------+---------------+---------------+ 374 / PacketPayload TLVs / 375 +---------------+---------------+---------------+---------------+ 376 / Optional CCNx ValidationAlgorithm TLV / 377 +---------------+---------------+---------------+---------------+ 378 / Optional CCNx ValidationPayload TLV (ValidationAlg required) / 379 +---------------+---------------+---------------+---------------+ 381 Figure 3: Packet format [1] 383 The Request and Reply Type values in the fixed header are 384 PT_CCNINFO_REQUEST and PT_CCNINFO_REPLY, respectively (Figure 4). 385 These messages are forwarded in a hop-by-hop manner. When the 386 Request message reaches the content forwarder, the content forwarder 387 turns it into a Reply message by changing the Type field value in the 388 fixed header from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY and forwards 389 it back toward the node that initiated the Request message. 391 Code Type name 392 ======== ===================== 393 %x00 PT_INTEREST [1] 394 %x01 PT_CONTENT [1] 395 %x02 PT_RETURN [1] 396 %x03 PT_CCNINFO_REQUEST 397 %x04 PT_CCNINFO_REPLY 399 Figure 4: Packet Type Namespace 401 The CCNinfo Request and Reply messages MUST begin with a fixed header 402 with either a Request or Reply type value to specify whether it is a 403 Request message or Reply message. Following a fixed header, there 404 can be a sequence of optional hop-by-hop header TLV(s) for a Request 405 message. In the case of a Request message, it is followed by a 406 sequence of Report blocks, each from a router on the path toward the 407 publisher or caching router. 409 At the beginning of PacketPayload TLVs, a top-level TLV type, 410 T_DISCOVERY (Figure 5), exists at the outermost level of a CCNx 411 protocol message. This TLV indicates that the Name segment TLV(s) 412 and Reply block TLV(s) would follow in the Request or Reply message. 414 Code Type name 415 ============= ========================= 416 %x0000 Reserved [1] 417 %x0001 T_INTEREST [1] 418 %x0002 T_OBJECT [1] 419 %x0003 T_VALIDATION_ALG [1] 420 %x0004 T_VALIDATION_PAYLOAD [1] 421 %x0005 T_DISCOVERY 423 Figure 5: Top-Level Type Namespace 425 3.1. Request Message 427 When a CCNinfo user initiates a discovery request (e.g., via the 428 ccninfo command described in Appendix A), a CCNinfo Request message 429 is created and forwarded to its upstream router through the Incoming 430 face(s) determined by its FIB. 432 The Request message format is shown in Figure 6. It consists of a 433 fixed header, Request header block TLV (Figure 7), Report block 434 TLV(s) (Figure 12), Name TLV, and Request block TLV. The Type value 435 of the Top-Level type namespace is T_DISCOVERY (Figure 5). The Type 436 value for the Report message is PT_CCNINFO_REQUEST. 438 1 2 3 439 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 440 +---------------+---------------+---------------+---------------+ 441 | Version | PacketType | PacketLength | 442 +---------------+---------------+---------------+---------------+ 443 | HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength | 444 +===============+===============+===============+===============+ 445 / Request header block TLV / 446 +---------------+---------------+---------------+---------------+ 447 / Report block TLV 1 / 448 +---------------+---------------+---------------+---------------+ 449 / Report block TLV 2 / 450 +---------------+---------------+---------------+---------------+ 451 / . / 452 / . / 453 +---------------+---------------+---------------+---------------+ 454 / Report block TLV n / 455 +===============+===============+===============+===============+ 456 | Type (=T_DISCOVERY) | MessageLength | 457 +---------------+---------------+---------------+---------------+ 458 | T_NAME | Length | 459 +---------------+---------------+---------------+---------------+ 460 / Name segment TLVs (name prefix specified by CCNinfo user) / 461 +---------------+---------------+---------------+---------------+ 462 / Request block TLV / 463 +---------------+---------------+---------------+---------------+ 464 / Optional CCNx ValidationAlgorithm TLV / 465 +---------------+---------------+---------------+---------------+ 466 / Optional CCNx ValidationPayload TLV (ValidationAlg required) / 467 +---------------+---------------+---------------+---------------+ 469 Figure 6: Request message consists of a fixed header, Request block 470 TLV, Report block TLV(s), and Name TLV 472 HopLimit: 8 bits 474 HopLimit is a counter that is decremented with each hop whenever a 475 Request packet is forwarded. It is specified by the CCNinfo user 476 program. It limits the distance that a Request may travel on the 477 network. Only the specified number of hops from the CCNinfo user 478 traces the Request. Each router inserts its own Report block and 479 forwards the Request message to the upstream router(s). The last 480 router stops the trace and sends the Reply message back to the 481 CCNinfo user. 483 ReturnCode: 8 bits 485 ReturnCode is used for the Reply message. This value is replaced 486 by the content forwarder when the Request message is returned as 487 the Reply message (see Section 3.2). Until then, this field MUST 488 be transmitted as zeros and ignored on receipt. 490 Value Name Description 491 ----- --------------- ---------------------------------------------- 492 %x00 NO_ERROR No error 493 %x01 WRONG_IF CCNinfo Request arrived on an interface 494 to which this router would not forward for 495 the specified name/function toward the 496 publisher. 497 %x02 INVALID_REQUEST Invalid CCNinfo Request is received. 498 %x03 NO_ROUTE This router has no route for the name prefix 499 and no way to determine a route. 500 %x04 NO_INFO This router has no cache information for the 501 specified name prefix. 502 %x05 NO_SPACE There was not enough room to insert another 503 Report block in the packet. 504 %x06 INFO_HIDDEN Information is hidden from this discovery 505 owing to some policy. 506 %x0E ADMIN_PROHIB CCNinfo Request is administratively 507 prohibited. 508 %x0F UNKNOWN_REQUEST This router does not support/recognize the 509 Request message. 510 %x80 FATAL_ERROR In a fatal error, the router may know the 511 upstream router but cannot forward the 512 message to it. 514 Reserved (MBZ): 8 bits 516 The reserved fields in the Value field MUST be transmitted as 517 zeros and ignored on receipt. 519 3.1.1. Request Header Block and Request Block 521 When a CCNinfo user transmits the Request message, s/he MUST insert 522 her/his Request header block TLV (Figure 7) into the hop-by-hop 523 header and Request block TLV (Figure 7) into the message before 524 sending it through the Incoming face(s). 526 1 2 3 527 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 528 +---------------+---------------+---------------+---------------+ 529 | Type (=T_DISC_REQHDR) | Length | 530 +---------------+---------------+-------+-------+-------+-+-+-+-+ 531 | Request ID |SkipHop| Flags |V|F|O|C| 532 +---------------+---------------+-------+-------+-------+-+-+-+-+ 534 Figure 7: Request header block TLV (hop-by-hop header) 536 Code Type name 537 ============= ========================= 538 %x0000 Reserved [1] 539 %x0001 T_INTLIFE [1] 540 %x0002 T_CACHETIME [1] 541 %x0003 T_MSGHASH [1] 542 %x0004-%x0007 Reserved [1] 543 %x0008 T_DISC_REQHDR 544 %x0009 T_DISC_REPORT 545 %x0FFE T_PAD [1] 546 %x0FFF T_ORG [1] 547 %x1000-%x1FFF Reserved [1] 549 Figure 8: Hop-by-Hop Type Namespace 551 Type: 16 bits 553 Format of the Value field. For the type value of the Request 554 block TLV MUST be T_DISC_REQHDR. 556 Length: 16 bits 558 Length of Value field in octets. 560 Request ID: 16 bits 562 This field is used as a unique identifier for the CCNinfo Request 563 so that the duplicate or delayed Reply messages can be detected. 565 SkipHop (Skip Hop Count): 4 bits 567 Number of skipped routers for a Request. It is specified by the 568 CCNinfo user program. Routers corresponding to the value 569 specified in this field are skipped and the CCNinfo Request 570 messages are forwarded to the next router without the addition of 571 Report blocks; the next upstream router then starts the trace. 572 The maximum value of this parameter is 15. This value MUST be 573 lower than that of HopLimit at the fixed header. 575 Flags: 12 bits 577 The Flags field is used to indicate the types of the content or 578 path discoveries. Currently, as shown in Figure 9, four bits, 579 "C", "O", "F", and "V" are assigned, and the other 8 bits are 580 reserved (MBZ) for the future use. Each flag can be mutually 581 specified with other flags. These flags are set by the CCNinfo 582 user program when they initiate Requests (see Appendix A), and the 583 routers that receive the Requests deal with the flags and change 584 the behaviors (see Section 5 for details). The Flag values 585 defined in this Flags field correspond to the Reply sub-blocks. 587 Flag Value Description 588 ----- ----- ----------------------------------------------------- 589 C 0 Path discovery (i.e., no cache information retrieved) 590 (default) 591 C 1 Cache information retrieval 592 O 0 Request to any content forwarder (default) 593 O 1 Publisher discovery (i.e., only FHR can reply) 594 F 0 Request based on FIB's strategy (default) 595 F 1 Full discovery request. Request to possible multiple 596 upstream routers specified in FIB simultaneously 597 V 0 No reply validation (default) 598 V 1 Reply sender validates Reply message 600 Figure 9: Codes and types specified in Flags field 602 1 2 3 603 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 604 +---------------+---------------+---------------+---------------+ 605 | Type (=T_DISC_REQ) | Length | 606 +---------------+---------------+---------------+---------------+ 607 | Request Arrival Time | 608 +---------------+---------------+---------------+---------------+ 609 / Node Identifier / 610 +---------------+---------------+---------------+---------------+ 612 Figure 10: Request block TLV (packet payload) 613 Code Type name 614 ============== =================== 615 %x0000 T_NAME [1] 616 %x0001 T_PAYLOAD [1] 617 %x0002 T_KEYIDRESTR [1] 618 %x0003 T_OBJHASHRESTR [1] 619 %x0005 T_PAYLDTYPE [1] 620 %x0006 T_EXPIRY [1] 621 %x0007 T_DISC_REQ 622 %x0008 T_DISC_REPLY 623 %x0009-%x0012 Reserved [1] 624 %x0FFE T_PAD [1] 625 %x0FFF T_ORG [1] 626 %x1000-%x1FFF Reserved [1] 628 Figure 11: CCNx Message Type Namespace 630 Type: 16 bits 632 Format of the Value field. For the Request block TLV, the type 633 value(s) MUST be T_DISC_REQ (see Figure 11) in the current 634 specification. 636 Length: 16 bits 638 Length of Value field in octets. 640 Request Arrival Time: 32 bits 642 The Request Arrival Time is a 32-bit NTP timestamp specifying the 643 arrival time of the CCNinfo Request packet at a specific router. 644 The 32-bit form of an NTP timestamp consists of the middle 32 bits 645 of the full 64-bit form; that is, the low 16 bits of the integer 646 part and the high 16 bits of the fractional part. 648 The following formula converts from a timespec (fractional part in 649 nanoseconds) to a 32-bit NTP timestamp: 651 request_arrival_time 652 = ((tv.tv_sec + 32384) << 16) + ((tv.tv_nsec << 7) / 1953125) 654 The constant 32384 is the number of seconds from Jan 1, 1900 to 655 Jan 1, 1970 truncated to 16 bits. ((tv.tv_nsec << 7) / 1953125) 656 is a reduction of ((tv.tv_nsec / 1000000000) << 16), where "<<" 657 denotes a logical left shift. 659 Note that it is RECOMMENDED for all the routers on the path to 660 have synchronized clocks to measure one-way latency per hop; 661 however, even if they do not have synchronized clocks, CCNinfo 662 measures the RTT between the content forwarder and consumer. 664 Node Identifier: variable length 666 This field specifies the node identifier (e.g., node name or hash- 667 based self-certifying name [10]) or all-zeros if unknown. This 668 document assumes that the Name TLV defined in the CCNx TLV format 669 [1] can be used for this field and the node identifier is 670 specified in it. 672 3.1.2. Report Block TLV 674 A CCNinfo user and each upstream router along the path would insert 675 their own Report block TLV without changing the Type field of the 676 fixed header of the Request message until one of these routers is 677 ready to send a Reply. In the Report block TLV (Figure 12), the 678 Request Arrival Time and Node Identifier MUST be inserted. 680 1 2 3 681 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 682 +---------------+---------------+---------------+---------------+ 683 | Type (=T_DISC_REPORT) | Length | 684 +---------------+---------------+---------------+---------------+ 685 | Request Arrival Time | 686 +---------------+---------------+---------------+---------------+ 687 / Node Identifier / 688 +---------------+---------------+---------------+---------------+ 690 Figure 12: Report block TLV (hop-by-hop header) 692 Type: 16 bits 694 Format of the Value field. For the Report block TLV, the type 695 value(s) MUST be T_DISC_REPORT in the current specification. For 696 all the available types for hop-by-hop type namespace, please see 697 Figure 8. 699 Length: 16 bits 701 Length of Value field in octets. 703 Request Arrival Time: 32 bits 705 Same definition as given in Section 3.1.1. 707 Node Identifier: variable length 708 Same definition as given in Section 3.1.1. 710 3.1.3. Content Name Specification 712 Specifications of the Name TLV (whose type value is T_NAME) and the 713 Name Segment TLVs are described in [1], which are followed by 714 CCNinfo. CCNinfo enables to specification of the content name either 715 with a prefix name without chunk number (such as "ccnx:/news/today") 716 or an exact name (such as "ccnx:/news/today/Chunk=10"). When a 717 CCNinfo user specifies a prefix name, s/he will obtain the summary 718 information of the matched content objects in the content forwarder. 719 In contrast, when a CCNinfo user specifies an exact name, s/he will 720 obtain only about the specified content object in the content 721 forwarder. A CCNinfo Request message MUST NOT be sent only with a 722 scheme name, ccnx:/. It will be rejected and discarded by routers. 724 3.2. Reply Message 726 When a content forwarder receives a CCNinfo Request message from an 727 appropriate adjacent neighbor router, it inserts its own Reply block 728 TLV and Reply sub-block TLV(s) to the Request message and turns the 729 Request into the Reply by changing the Type field of the fixed header 730 of the Request message from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY. 731 The Reply message (see Figure 13) is then forwarded back toward the 732 CCNinfo user in a hop-by-hop manner. 734 1 2 3 735 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 736 +---------------+---------------+---------------+---------------+ 737 | Version | PacketType | PacketLength | 738 +---------------+---------------+-------------+-+---------------+ 739 | HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength | 740 +===============+===============+=============+=+===============+ 741 / Request header block TLV / 742 +---------------+---------------+---------------+---------------+ 743 / . / 744 / . / 745 / n Report block TLVs / 746 / . / 747 / . / 748 +===============+===============+===============+===============+ 749 | Type (=T_DISCOVERY) | MessageLength | 750 +---------------+---------------+---------------+---------------+ 751 | T_NAME | Length | 752 +---------------+---------------+---------------+---------------+ 753 / Name segment TLVs (name prefix specified by CCNinfo user) / 754 +---------------+---------------+---------------+---------------+ 755 / Request block TLV / 756 +---------------+---------------+---------------+---------------+ 757 / Reply block TLV / 758 +---------------+---------------+---------------+---------------+ 759 / Reply sub-block TLV 1 / 760 +---------------+---------------+---------------+---------------+ 761 / . / 762 / . / 763 +---------------+---------------+---------------+---------------+ 764 / Reply sub-block TLV k / 765 +---------------+---------------+---------------+---------------+ 766 / Optional CCNx ValidationAlgorithm TLV / 767 +---------------+---------------+---------------+---------------+ 768 / Optional CCNx ValidationPayload TLV (ValidationAlg required) / 769 +---------------+---------------+---------------+---------------+ 771 Figure 13: Reply message consists of a fixed header, Request block 772 TLV, Report block TLV(s), Name TLV, and Reply block/sub-block TLV(s) 774 3.2.1. Reply Block TLV 776 The Reply block TLV is an envelope for the Reply sub-block TLV(s) 777 (explained from the next section). 779 1 2 3 780 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 781 +---------------+---------------+---------------+---------------+ 782 | Type (=T_DISC_REPLY) | Length | 783 +---------------+---------------+---------------+---------------+ 784 | Request Arrival Time | 785 +---------------+---------------+---------------+---------------+ 786 / Node Identifier / 787 +---------------+---------------+---------------+---------------+ 789 Figure 14: Reply block TLV (packet payload) 791 Type: 16 bits 793 Format of the Value field. For the Reply block TLV, the type 794 value MUST be T_DISC_REPLY shown in Figure 11 in the current 795 specification. 797 Length: 16 bits 799 Length of the Value field in octets. This length is the total 800 length of Reply sub-block(s). 802 Request Arrival Time: 32 bits 804 Same definition as given in Section 3.1.1. 806 Node Identifier: variable length 808 Same definition as given in Section 3.1.1. 810 3.2.1.1. Reply Sub-Block TLV 812 The router on the traced path will add one or multiple Reply sub- 813 blocks followed by the Reply block TLV before sending the Reply to 814 its neighbor router. This section describes the Reply sub-block TLV 815 for informing various cache states and conditions as shown in 816 Figure 15. (Other Reply sub-block TLVs will be discussed in separate 817 document(s).) 819 Note that some routers may not be capable of reporting the following 820 values, such as Object Size, Object Count, # Received Interest, First 821 Seqnum, Last Seqnum, Elapsed Cache Time, and Remain Cache Lifetime, 822 shown in Figure 15, or do not report these values due to their 823 policy. In that case, the routers set these fields to a value of one 824 (i.e., %xFFFFFFFF). The value of each field will be also all-one 825 when the value is equal to or bigger than the maximum size expressed 826 by the 32-bit field. The CCNinfo user program MUST inform that these 827 values are not valid if the fields received are set to the value of 828 one. 830 If the cache is refreshed after reboot, the value in each field MUST 831 be refreshed (i.e., MUST be set to 0). If the cache remains after 832 reboot, the value MUST NOT be refreshed (i.e., MUST be reflected as 833 it is). 835 1 2 3 836 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 837 +---------------+---------------+---------------+---------------+ 838 | Type | Length | 839 +---------------+---------------+---------------+---------------+ 840 | Object Size | 841 +---------------+---------------+---------------+---------------+ 842 | Object Count | 843 +---------------+---------------+---------------+---------------+ 844 | # Received Interest | 845 +---------------+---------------+---------------+---------------+ 846 | First Seqnum | 847 +---------------+---------------+---------------+---------------+ 848 | Last Seqnum | 849 +---------------+---------------+---------------+---------------+ 850 | Elapsed Cache Time | 851 +---------------+---------------+---------------+---------------+ 852 | Remain Cache Lifetime | 853 +---------------+---------------+---------------+---------------+ 854 | T_NAME | Length | 855 +---------------+---------------+---------------+---------------+ 856 / Name Segment TLVs / 857 +---------------+---------------+---------------+---------------+ 859 Figure 15: Reply sub-block TLV for T_DISC_CONTENT and 860 T_DISC_CONTENT_PUBLISHER (packet payload) 862 Code Type name 863 ============= =========================== 864 %x0000 T_DISC_CONTENT 865 %x0001 T_DISC_CONTENT_PUBLISHER 866 %x0FFF T_ORG 867 %x1000-%x1FFF Reserved (Experimental Use) 869 Figure 16: CCNinfo Reply Type Namespace 871 Type: 16 bits 873 Format of the Value field. For the Reply sub-block TLV, the type 874 value MUST be either T_DISC_CONTENT or T_DISC_CONTENT_PUBLISHER 875 defined in the CCNinfo Reply Type Namespace (Figure 16). 876 T_DISC_CONTENT is specified when the cache information is replied 877 from a caching router. T_DISC_CONTENT_PUBLISHER is specified when 878 the content information is replied from a FHR attached to a 879 publisher. 881 Length: 16 bits 883 Length of the Value field in octets. 885 Object Size: 32 bits 887 The total size (KB) of the unexpired content objects. Note that 888 the maximum size expressed by the 32-bit field is approximately 889 4.29 TB. 891 Object Count: 32 bits 893 The number of the unexpired content objects. Note that the 894 maximum count expressed by the 32-bit field is approximately 4.29 895 billion. 897 # Received Interest: 32 bits 899 The total number of the received Interest messages to retrieve the 900 cached content objects. 902 First Seqnum: 32 bits 904 The first sequential number of the unexpired content objects. 906 Last Seqnum: 32 bits 908 The last sequential number of the unexpired content objects. The 909 First Seqnum and Last Seqnum do not guarantee the consecutiveness 910 of the cached content objects; however, knowing these values may 911 help in the analysis of consecutive or discontinuous chunks such 912 as [11]. 914 Elapsed Cache Time: 32 bits 916 The elapsed time (seconds) after the oldest content object of the 917 content is cached. 919 Remain Cache Lifetime: 32 bits 921 The lifetime (seconds) of a content object, which is lastly 922 cached. 924 4. CCNinfo User Behavior 926 4.1. Sending CCNinfo Request 928 A CCNinfo user invokes a CCNinfo user program (e.g., ccninfo command) 929 that initiates a CCNinfo Request message and sends it to the user's 930 adjacent neighbor router(s) of interest. The user later obtains both 931 the routing path information and in-network cache information in the 932 single Reply. 934 When the CCNinfo user program initiates a Request message, it MUST 935 insert the necessary values, i.e., the "Request ID" and the "Node 936 Identifier", in the Request block. The Request ID MUST be unique for 937 the CCNinfo user until s/he receives the corresponding Reply 938 message(s) or the Request is timed out. 940 Owing to some policies, a router may want to validate the CCNinfo 941 Requests using the CCNx ValidationPayload TLV (whether it accepts the 942 Request or not) especially when the router receives the "full 943 discovery request" (see Section 5.3.2). Accordingly, the CCNinfo 944 user program MAY require validating the Request message and appending 945 the user's signature into the CCNx ValidationPayload TLV. The router 946 then forwards the Request message. If the router does not approve 947 the Request, it rejects the Request message as described in 948 Section 6.11. 950 After the CCNinfo user program sends the Request message, until the 951 Reply is timed out or the expected numbers of Replies or a Reply 952 message with a non-zero ReturnCode in the fixed header is received, 953 the CCNinfo user program MUST keep the following information: 954 HopLimit, specified in the fixed header, Request ID, Flags, Node 955 Identifier, and Request Arrival Time, specified in the Request block. 957 4.1.1. Routing Path Information 959 A CCNinfo user can send a CCNinfo Request for investigating the 960 routing path information for the specified named content. Using the 961 Request, a legitimate user can obtain 1) the node identifiers of the 962 intermediate routers, 2) node identifier of the content forwarder, 3) 963 number of hops between the content forwarder and consumer, and 4) RTT 964 between the content forwarder and consumer, per name prefix. This 965 CCNinfo Request is terminated when it reaches the content forwarder. 967 4.1.2. In-Network Cache Information 969 A CCNinfo user can send a CCNinfo Request for investigating in- 970 network cache information. Using the Request, a legitimate user can 971 obtain 1) the size of cached content objects, 2) number of cached 972 content objects, 3) number of accesses (i.e., received Interests) per 973 content, and 4) lifetime and expiration time of the cached content 974 objects, for Content Store (CS) in the content forwarder, unless the 975 content forwarder is capable of reporting them (see Section 3.2.1.1). 976 This CCNinfo Request is terminated when it reaches the content 977 forwarder. 979 4.2. Receiving CCNinfo Reply 981 A CCNinfo user program will receive one or multiple CCNinfo Reply 982 messages from the adjacent neighbor router(s). When the program 983 receives the Reply, it MUST compare the kept Request ID and Node 984 Identifier to identify the Request and Reply pair. If they do not 985 match, the Reply message MUST be silently discarded. 987 If the number of Report blocks in the received Reply is more than the 988 initial HopLimit value (which was inserted in the original Request), 989 the Reply MUST be silently ignored. 991 After the CCNinfo user has determined that s/he has traced the whole 992 path or the maximum path that s/he can be expected to, s/he might 993 collect statistics by waiting for a timeout. Useful statistics 994 provided by CCNinfo are stated in Section 8. 996 5. Router Behavior 998 5.1. User and Neighbor Verification 1000 Upon receiving a CCNinfo Request message, a router MAY examine 1001 whether a valid CCNinfo user has sent the message. If the router 1002 recognizes that the Request sender's signature specified in the 1003 Request is invalid, it SHOULD terminate the Request, as defined in 1004 Section 6.4. 1006 Upon receiving a CCNinfo Request/Reply message, a router MAY examine 1007 whether the message comes from a valid adjacent neighbor node. If 1008 the router recognizes that the Request/Reply sender is invalid, it 1009 SHOULD silently ignore the Request/Reply message, as specified in 1010 Section 10.9. 1012 5.2. Receiving CCNinfo Request 1014 After a router accepts the CCNinfo Request message, it performs the 1015 following steps. 1017 1. The value of "HopLimit" in the fixed header and that of "SkipHop 1018 (Skip Hop Count)" in the Request block are counters that are 1019 decremented with each hop. If the HopLimit value is zero, the 1020 router terminates the Request, as defined in Section 6.5. If the 1021 SkipHop value is equal to or more than the HopLimit value, the 1022 router terminates the Request, as defined in Section 6.4. 1023 Otherwise, until the SkipHop value becomes zero, the router 1024 forwards the Request message to the upstream router(s) without 1025 adding its own Report block and without replying to the Request. 1026 If the router does not know the upstream router(s) regarding the 1027 specified name prefix, it terminates the Request, as defined in 1028 Section 6.5. It should be noted that the Request messages are 1029 terminated at the FHR; therefore, although the maximum value for 1030 the HopLimit is 255 and that for SkipHop is 15, if the Request 1031 messages reach the FHR before the HopLimit or SkipHop value 1032 becomes 0, the FHR silently discards the Request message and the 1033 Request is timed out. 1035 2. The router examines the Flags field (specified in Figure 9) in 1036 the Request block of the received CCNinfo Request. If the "C" 1037 flag is not set, it is categorized as the "routing path 1038 information discovery". If the "C" flag is set, it is the "cache 1039 information discovery". If the "O" flag is set, it is the 1040 "publisher discovery". 1042 3. If the Request is either "cache information discovery" or 1043 "routing path information discovery", the router examines its FIB 1044 and CS. If the router caches the specified content, it sends the 1045 Reply message with its own Reply block and sub-block(s). If the 1046 router cannot insert its own Reply block or sub-block(s) because 1047 of no space, it it terminates the Request, as specified in 1048 Section 6.7. If the router does not cache the specified content 1049 but knows the upstream neighbor router(s) for the specified name 1050 prefix, it creates the PIT entry, and inserts its own Report 1051 block in the hop-by-hop header and forwards the Request to the 1052 upstream neighbor(s). If the router cannot insert its own Report 1053 block because of no space, or if the router does not cache the 1054 specified content and does not know the upstream neighbor 1055 router(s) for the specified name prefix, it terminates the 1056 Request, as defined in Section 6.5. 1058 4. If the Request is the "publisher discovery", the router examines 1059 whether it is the FHR for the requested content. If the router 1060 is the FHR, it sends the Reply message with its own Report block 1061 and sub-blocks (in the case of cache information discovery) or 1062 the Reply message with its own Report block without adding any 1063 Reply sub-blocks (in the case of routing path information 1064 discovery). If the router is not the FHR but knows the upstream 1065 neighbor router(s) for the specified name prefix, it creates the 1066 PIT entry, and inserts its own Report block and forwards the 1067 Request to the upstream neighbor(s). If the router cannot insert 1068 its own Report block in the hop-by-hop header because of no 1069 space, it it terminates the Request, as specified in Section 6.7. 1070 If the router is not the FHR and does not know the upstream 1071 neighbor router(s) for the specified name prefix, it terminates 1072 the Request, as defined in Section 6.5. Note that in Cefore 1073 [13], there is an API by which a publisher informs the 1074 application prefix to the FHR and the FHR registers it into the 1075 FIB. The prefix entry then can be statically configured on other 1076 routers or announced by a routing protocol. 1078 5.3. Forwarding CCNinfo Request 1080 5.3.1. Regular Request 1082 When a router decides to forward a Request message with its Report 1083 block to its upstream router(s), it specifies the Request Arrival 1084 Time and Node Identifier in the Report block of the Request message. 1085 The router then forwards the Request message upstream toward the 1086 publisher or caching router based on the FIB entry like the ordinary 1087 Interest-Data exchanges in CCN. 1089 When the router forwards the Request message, it MUST record the F 1090 flag and Request ID in the Request block of the Request message and 1091 exploiting path labels (specified in Section 1) at the corresponding 1092 PIT entry. The router can later check the PIT entry to correctly 1093 forward the Reply message(s) back. 1095 CCNinfo supports multipath forwarding. The Request messages can be 1096 forwarded to multiple neighbor routers. Some routers may have a 1097 strategy for multipath forwarding; when a router sends Interest 1098 messages to multiple neighbor routers, it may delay or prioritize to 1099 send the message to the upstream routers. The CCNinfo Request, as 1100 the default, complies with such strategies; a CCNinfo user could 1101 trace the actual forwarding path based on the forwarding strategy and 1102 will receive a single Reply message such as a content object. 1104 5.3.2. Full Discovery Request 1106 There may be a case wherein a CCNinfo user wants to discover all 1107 possible forwarding paths and content forwarders based on the 1108 routers' FIBs. The "full discovery request" enables this 1109 functionality. If a CCNinfo user sets the F flag in the Request 1110 block of the Request message (as seen in Figure 9) to request the 1111 full discovery, the upstream routers simultaneously forward the 1112 Requests to all multiple upstream routers based on the FIBs. Then, 1113 the CCNinfo user can trace all possible forwarding paths. 1115 3. Reply(C) 2. Reply(C) 1116 3. Reply(P) 2. Reply(P) 1. Reply(P) 1117 +----+ +----+ +----+ 1118 | | | | | | 1119 v | v | v | 1120 +--------+ +--------+ +--------+ +--------+ +---------+ 1121 | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| 1122 | user | | A | | B | | C | | | 1123 +--------+ +--------+ +--------+ +--------+ +---------+ 1124 ^ 1125 \ +-------+ 1126 1. Reply(C) \ | Cache | 1127 \ +---------+ | 1128 \| Caching |----+ 1129 | router | 1130 +---------+ 1132 Figure 17: Full discovery request. Reply messages forwarded by 1133 publisher and routers. Each router forwards the Reply message along 1134 its PIT entry and finally, the CCNinfo user receives two Reply 1135 messages: one from the FHR (Router C) and the other from the Caching 1136 router. 1138 To receive different Reply messages forwarded from different routers, 1139 the PIT entries initiated by CCNinfo remain until the configured 1140 CCNinfo Reply Timeout (Section 7.1) is expired. In other words, 1141 unlike the ordinary Interest-Data exchanges in CCN, if routers that 1142 accept the full discovery request receive the full discovery request, 1143 the routers SHOULD NOT remove the PIT entry created by the full 1144 discovery request until the CCNinfo Reply Timeout value expires. 1146 Note that the full discovery request is an OPTIONAL implementation of 1147 CCNinfo; it may not be implemented on routers. Even if it is 1148 implemented on a router, it may not accept the full discovery request 1149 from non-validated CCNinfo users or routers or because of its policy. 1150 If a router does not accept the full discovery request, it rejects 1151 the full discovery request as described in Section 6.11. Routers 1152 that enable the full discovery request MAY rate-limit Replies, as 1153 described in Section 10.8 as well. 1155 5.4. Sending CCNinfo Reply 1157 If there is a caching router or FHR for the specified content within 1158 the specified hop count along the path, the caching router or FHR 1159 sends back the Reply message toward the CCNinfo user and terminates 1160 the Request. 1162 When a router decides to send a Reply message to its downstream 1163 neighbor router or the CCNinfo user with NO_ERROR return code, it 1164 inserts a Report block with the Request Arrival Time and Node 1165 Identifier to the Request message. Then, the router inserts the 1166 corresponding Reply sub-block(s) (Figure 15) to the payload. The 1167 router finally changes the Type field in the fixed header from 1168 PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY and forwards the message back 1169 as the Reply toward the CCNinfo user in a hop-by-hop manner. 1171 If a router cannot continue the Request, the router MUST put an 1172 appropriate ReturnCode in the Request message, change the Type field 1173 value in the fixed header from PT_CCNINFO_REQUEST to 1174 PT_CCNINFO_REPLY, and forward the Reply message back toward the 1175 CCNinfo user to terminate the Request (see Section 6). 1177 5.5. Forwarding CCNinfo Reply 1179 When a router receives a CCNinfo Reply whose Request ID and Node 1180 Identifier match those in the PIT entry, sent from a valid adjacent 1181 neighbor router, it forwards the CCNinfo Reply back toward the 1182 CCNinfo user. If the router does not receive the corresponding Reply 1183 within the [CCNinfo Reply Timeout] period, then it removes the 1184 corresponding PIT entry and terminates the trace. 1186 The Flags field in the Request block TLV is used to indicate whether 1187 the router keeps the PIT entry during the CCNinfo Reply Timeout even 1188 after one or more corresponding Reply messages are forwarded. When 1189 the CCNinfo user does not set the F flag (i.e., "0"), the 1190 intermediate routers immediately remove the PIT entry whenever they 1191 forward the corresponding Reply message. When the CCNinfo user sets 1192 the F flag (i.e., "1"), which means the CCNinfo user chooses the 1193 "full discovery request" (see Section 5.3.2), the intermediate 1194 routers keep the PIT entry within the [CCNinfo Reply Timeout] period. 1195 After this timeout, the PIT entry is removed. 1197 CCNinfo Replies MUST NOT be cached in routers upon the transmission 1198 of Reply messages. 1200 5.6. PIT Entry Management for Multipath Support 1202 Within a network with multipath condition, there is a case 1203 (Figure 18) wherein a single CCNinfo Request is split into multiple 1204 Requests (e.g., at Router A), which are injected into a single router 1205 (Router D). In this case, multiple Replies with the same Request ID 1206 and Node Identifier including different Report blocks are received by 1207 the router (Router D). 1209 +--------+ 1210 | Router | 1211 | B | 1212 +--------+ 1213 / \ 1214 / \ 1215 +--------+ +--------+ +--------+ +---------+ 1216 | CCNinfo|----| Router | | Router | ... |Publisher| 1217 | user | | A | | D | | | 1218 +--------+ +--------+ +--------+ +---------+ 1219 \ / 1220 \ / 1221 +--------+ 1222 | Router | 1223 | C | 1224 +--------+ 1226 Figure 18 1228 To recognize different CCNinfo Reply messages, the routers MUST 1229 distinguish the PIT entries by the Request ID and exploiting path 1230 labels, which could be a hash value of the concatenation information 1231 of the cumulate Node Identifiers in the hop-by-hop header and the 1232 specified content name. For example, when Router D in Figure 18 1233 receives a CCNinfo Request from Router B, its PIT includes the 1234 Request ID and value such as H((Router_A|Router_B)|content_name), 1235 where "H" indicates some hash function and "|" indicates 1236 concatenation. When Router D receives a CCNinfo Request from Router 1237 C, its PIT includes the same Request ID and value of 1238 H((Router_A|Router_C)|content_name). Two different Replies are later 1239 received on Router D and each Reply is appropriately forwarded to 1240 Router B and Router C, respectively. Note that two Reply messages 1241 coming from Router B and Router C are reached at Router A, but the 1242 CCNinfo user can only receive the first Reply message either from 1243 Router B or Router C as Router A removes the corresponding PIT entry 1244 after it forwards the first Reply. 1246 To avoid routing loop, when a router seeks the cumulate Node 1247 Identifiers of the Report blocks in the hop-by-hop header, it MUST 1248 examine whether its own Node Identifier is not previously inserted. 1249 If a router detects its own Node Identifier in the hop-by-hop header, 1250 the router inserts its Report block and terminates the Request as 1251 will be described in Section 6.8. 1253 6. CCNinfo Termination 1255 When performing a hop-by-hop trace, it is necessary to determine when 1256 to stop the trace. There are several cases when an intermediate 1257 router might return a Reply before a Request reaches the caching 1258 router or the FHR. 1260 6.1. Arriving at First-hop Router 1262 A CCNinfo Request can be determined to have arrived at the FHR. To 1263 ensure that a router recognizes that it is the FHR for the specified 1264 content, it needs to have a FIB entry (or attach) to the 1265 corresponding publisher or the content. 1267 6.2. Arriving at Router Having Cache 1269 A CCNinfo Request can be determined to have arrived at the router 1270 having the specified content cache within the specified HopLimit. 1272 6.3. Arriving at Last Router 1274 A CCNinfo Request can be determined to have arrived at the last 1275 router of the specified HopLimit. If the last router does not have 1276 the corresponding cache, it MUST insert its Report block and send the 1277 Reply message with NO_INFO return code without appending any Reply 1278 (sub-)block TLVs. 1280 6.4. Invalid Request 1282 If the router does not validate the Request or the Reply, the router 1283 MUST note a ReturnCode of INVALID_REQUEST in the fixed header of the 1284 message, insert its Report block, and forward the message as the 1285 Reply back to the CCNinfo user. The router MAY, however, randomly 1286 ignore the received invalid messages. (See Section 10.7.) 1288 6.5. No Route 1290 If the router cannot determine the routing paths or neighbor routers 1291 for the specified name prefix within the specified HopLimit, it MUST 1292 note a ReturnCode of NO_ROUTE in the fixed header of the message, 1293 insert its Report block, and forward the message as the Reply back to 1294 the CCNinfo user. 1296 6.6. No Information 1298 If the router does not have any information about the specified name 1299 prefix within the specified HopLimit, it MUST note a ReturnCode of 1300 NO_INFO in the fixed header of the message, insert its Report block, 1301 and forward the message as the Reply back to the CCNinfo user. 1303 6.7. No Space 1305 If appending the Report block or the Reply (sub-)block would make the 1306 hop-by-hop header longer than 247 bytes or the Request packet longer 1307 than the MTU of the Incoming face, the router MUST note a ReturnCode 1308 of NO_SPACE in the fixed header of the message and forward the 1309 message as the Reply back to the CCNinfo user. 1311 6.8. Fatal Error 1313 If a CCNinfo Request has encountered a fatal error, the router MUST 1314 note a ReturnCode of FATAL_ERROR in the fixed header of the message 1315 and forward the message as the Reply back to the CCNinfo user. This 1316 may happen, for example, when the router detects some routing loop in 1317 the Request blocks (see Section 1). The fatal error can be encoded 1318 with another error: if a router detects routing loop but cannot 1319 insert its Report block, it MUST note NO_SPACE and FATAL_ERROR 1320 ReturnCodes (i.e., %x85) in the fixed header and forward the message 1321 back to the CCNinfo user. 1323 6.9. CCNinfo Reply Timeout 1325 If a router receives the Request or Reply message that expires its 1326 own [CCNinfo Reply Timeout] value (Section 7.1), the router will 1327 silently discard the Request or Reply message. 1329 6.10. Non-Supported Node 1331 Cases will arise in which a router or a FHR along the path does not 1332 support CCNinfo. In such cases, a CCNinfo user and routers that 1333 forward the CCNinfo Request will time out the CCNinfo request. 1335 6.11. Administratively Prohibited 1337 If CCNinfo is administratively prohibited, the router rejects the 1338 Request message and MUST send the CCNinfo Reply with the ReturnCode 1339 of ADMIN_PROHIB. The router MAY, however, randomly ignore the 1340 Request messages to be rejected (see Section 10.7). 1342 7. Configurations 1343 7.1. CCNinfo Reply Timeout 1345 The [CCNinfo Reply Timeout] value is used to time out a CCNinfo 1346 Reply. The value for a router can be statically configured by the 1347 router's administrators/operators. The default value is 3 (seconds). 1348 The [CCNinfo Reply Timeout] value SHOULD NOT be larger than 4 1349 (seconds) and SHOULD NOT be lower than 2 (seconds). 1351 7.2. HopLimit in Fixed Header 1353 If a CCNinfo user does not specify the HopLimit value in the fixed 1354 header for a Request message as the HopLimit, the HopLimit is set to 1355 32. Note that 0 HopLimit is an invalid Request; hence, the router in 1356 this case follows the way defined in Section 6.4. 1358 7.3. Access Control 1360 A router MAY configure the valid or invalid networks to enable an 1361 access control. The access control MAY be defined per name prefix, 1362 such as "who can retrieve which name prefix" (see Section 10.2). 1364 8. Diagnosis and Analysis 1366 8.1. Number of Hops and RTT 1368 A CCNinfo Request message is forwarded in a hop-by-hop manner and 1369 each forwarding router appends its own Report block. We can then 1370 verify the number of hops to reach the content forwarder or publisher 1371 and the RTT between the content forwarder or publisher. 1373 8.2. Caching Router Identification 1375 While some routers may hide their node identifiers with all-zeros in 1376 the Report blocks (as seen in Section 10.1), the routers in the path 1377 from the CCNinfo user to the content forwarder can be identified. 1379 8.3. TTL or Hop Limit 1381 By taking the HopLimit from the content forwarder and forwarding the 1382 TTL threshold over all hops, it is possible to discover the TTL or 1383 hop limit required for the content forwarder to reach the CCNinfo 1384 user. 1386 8.4. Time Delay 1388 If the routers have synchronized clocks, it is possible to estimate 1389 the propagation and queuing delays from the differences between the 1390 timestamps at the successive hops. However, this delay includes the 1391 control processing overhead; therefore, it is not necessarily 1392 indicative of the delay that would be experienced by the data 1393 traffic. 1395 8.5. Path Stretch 1397 By obtaining the path stretch "d / P", where "d" is the hop count of 1398 the data and "P" is the hop count from the consumer to the publisher, 1399 we can measure the improvements in path stretch in various cases, 1400 such as in different caching and routing algorithms. We can then 1401 facilitate the investigation of the performance of the protocol. 1403 8.6. Cache Hit Probability 1405 CCNinfo can show the number of received interests per cache or chunk 1406 on a router. Accordingly, CCNinfo measures the content popularity 1407 (i.e., the number of accesses for each content/cache), thereby 1408 enabling the investigation of the routing/caching strategy in 1409 networks. 1411 9. IANA Considerations 1413 New assignments can only be made via a Standards Action as specified 1414 in [5]. This document does not intend to be the standard document. 1415 However, the new assignments such as the ReturnCode and various type 1416 values will be considered when this specification becomes the RFC. 1418 10. Security Considerations 1420 This section addresses some of the security considerations. 1422 10.1. Policy-Based Information Provisioning for Request 1424 Although CCNinfo gives excellent troubleshooting cues, some network 1425 administrators or operators may not want to disclose everything about 1426 their network to the public or may wish to securely transmit private 1427 information to specific members of their networks. CCNinfo provides 1428 policy-based information provisioning, thereby allowing network 1429 administrators to specify their response policy for each router. 1431 The access policy regarding "who is allowed to retrieve" and/or "what 1432 kind of cache information" can be defined for each router. For the 1433 former type of access policy, routers with the specified content MAY 1434 examine the signature enclosed in the Request message and decide 1435 whether they should notify the content information in the Reply. If 1436 the routers decide to not notify the content information, they MUST 1437 send the CCNinfo Reply with the ReturnCode of ADMIN_PROHIB without 1438 appending any Reply (sub-)block TLVs. For the latter type of policy, 1439 the permission, whether (1) All (all cache information is disclosed), 1440 (2) Partial (cache information with a particular name prefix can (or 1441 cannot) be disclosed), or (3) Deny (no cache information is 1442 disclosed), is defined at the routers. 1444 In contrast, we entail that each router does not disrupt the 1445 forwarding of CCNinfo Request and Reply messages. When a Request 1446 message is received, the router SHOULD insert the Report block if the 1447 ReturnCode is NO_ERROR. Here, according to the policy configuration, 1448 the Node Identifier field in the Report block MAY be null (i.e., all- 1449 zeros), but the Request Arrival Time field SHOULD NOT be null. 1450 Finally, the router SHOULD forward the Request message to the 1451 upstream router toward the content forwarder if the ReturnCode is 1452 kept with NO_ERROR. 1454 10.2. Filtering CCNinfo Users Located in Invalid Networks 1456 A router MAY support an access control mechanism to filter out 1457 Requests from invalid CCNinfo users. To accomplish this, invalid 1458 networks (or domains) could, for example, be configured via a list of 1459 allowed/disallowed networks (as observed in Section 7.3). If a 1460 Request is received from a disallowed network (according to the Node 1461 Identifier in the Request block), the Request MUST NOT be processed 1462 and the Reply with the ReturnCode of INFO_HIDDEN SHOULD be used to 1463 note that. The router MAY, however, perform rate limited logging of 1464 such events. 1466 10.3. Topology Discovery 1468 CCNinfo can be used to discover actively used topologies. If a 1469 network topology is not disclosed, CCNinfo Requests SHOULD be 1470 restricted at the border of the domain using the ADMIN_PROHIB return 1471 code. 1473 10.4. Characteristics of Content 1475 CCNinfo can be used to discover the type of content being sent by 1476 publishers. If this information is a secret, CCNinfo Requests SHOULD 1477 be restricted at the border of the domain, using the ADMIN_PROHIB 1478 return code. 1480 10.5. Computational Attacks 1482 CCNinfo may impose heavy tasks at content forwarders because it makes 1483 content forwarders seek their internal cache states reported in the 1484 Reply messages whenever they form the Reply messages. The current 1485 CCNinfo specification allows to return null values for several 1486 fields, such as First/Last Seqnum or Elapsed Cache Time fields in the 1487 Reply sub-block. As mentioned in Section 3.2.1.1, these values MAY 1488 be null. This means that the content forwarder can not only hide 1489 these values owing to privacy/security policies, but also skip the 1490 implementations of the complex functions to report these values. 1492 10.6. Longer or Shorter CCNinfo Reply Timeout 1494 Routers can configure CCNinfo Reply Timeout (Section 7.1), which is 1495 the allowable timeout value to keep the PIT entry. If routers 1496 configure a longer timeout value, there may be an attractive attack 1497 vector against the PIT memory. Moreover, especially when the full 1498 discovery request option (Section 5.3) is specified for the CCNinfo 1499 Request, several Reply messages may be returned and cause a response 1500 storm. (See Section 10.8 for rate-limiting to avoid the storm). To 1501 avoid DoS attacks, routers MAY configure the timeout value, which is 1502 shorter than the user-configured CCNinfo timeout value. However, if 1503 it is too short, the Request may be timed out and the CCNinfo user 1504 does not receive all Replies; s/he only retrieves the partial path 1505 information (i.e., information about a part of the tree). 1507 There may be a way to enable incremental exploration (i.e., to 1508 explore the part of the tree that was not explored by the previous 1509 operation); however, discussing such mechanisms is out of scope of 1510 this document. 1512 10.7. Limiting Request Rates 1514 A router MAY rate-limit CCNinfo Requests by ignoring some of the 1515 consecutive messages. The router MAY randomly ignore the received 1516 messages to minimize the processing overhead, i.e., to keep fairness 1517 in processing requests, or prevent traffic amplification. In such a 1518 case, no error message is returned. The rate limit function is left 1519 to the router's implementation. 1521 10.8. Limiting Reply Rates 1523 CCNinfo supporting multipath forwarding may result in one Request 1524 returning multiple Reply messages. To prevent abuse, the routers in 1525 the traced path MAY need to rate-limit the Replies. In such a case, 1526 no error message is returned. The rate limit function is left to the 1527 router's implementation. 1529 10.9. Adjacency Verification 1531 It is assumed that the CCNinfo Request and Reply messages are 1532 forwarded by adjacent neighbor nodes or routers. The CCNx message 1533 format or semantics do not define a secure way to verify the node/ 1534 router adjacency, while HopAuth [10] provides a possible method for 1535 an adjacency verification and defines the corresponding message 1536 format for adjacency verification as well as the router behaviors. 1537 CCNinfo MAY use a similar method for node adjacency verification. 1539 11. Acknowledgements 1541 The authors would like to thank Spyridon Mastorakis, Paulo Mendes, 1542 Ilya Moiseenko, David Oran, and Thierry Turletti for their valuable 1543 comments and suggestions on this document. 1545 12. References 1547 12.1. Normative References 1549 [1] Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 1550 Format", RFC 8609, July 2019. 1552 [2] Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", 1553 RFC 8569, July 2019. 1555 [3] Bradner, S., "Key words for use in RFCs to Indicate 1556 Requirement Levels", BCP 14, RFC 2119, 1557 DOI 10.17487/RFC2119, March 1997, 1558 . 1560 [4] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1561 2119 Key Words", May 2017, 1562 . 1564 [5] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1565 Writing an IANA Considerations Section in RFCs", BCP 26, 1566 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1567 . 1569 12.2. Informative References 1571 [6] Asaeda, H., Matsuzono, K., and T. Turletti, "Contrace: A 1572 Tool for Measuring and Tracing Content-Centric Networks", 1573 IEEE Communications Magazine, Vol.53, No.3, pp.182-188, 1574 March 2015. 1576 [7] Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and 1577 D. Oran, "ICN Ping Protocol Specification", draft-irtf- 1578 icnrg-icnping-02 (work in progress), April 2021. 1580 [8] Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and 1581 D. Oran, "ICN Traceroute Protocol Specification", draft- 1582 irtf-icnrg-icntraceroute-02 (work in progress), April 1583 2021. 1585 [9] Asaeda, H., Mayer, K., and W. Lee, "Mtrace Version 2: 1586 Traceroute Facility for IP Multicast", RFC 8487, October 1587 2018. 1589 [10] Li, R. and H. Asaeda, "Hop-by-Hop Authentication in 1590 Content-Centric Networking/Named Data Networking", draft- 1591 li-icnrg-hopauth-02 (work in progress), February 2020. 1593 [11] Li, R., Matsuzono, K., Asaeda, H., and X. Fu, "Consecutive 1594 Caching and Adaptive Retrieval for In-Network Big Data 1595 Sharing", Proc. IEEE ICC, Kansas City, USA, May 2018. 1597 [12] Asaeda, H., Ooka, A., Matsuzono, K., and R. Li, "Cefore: 1598 Software Platform Enabling Content-Centric Networking and 1599 Beyond", IEICE Transaction on Communications, Vol.E102-B, 1600 No.9, pp.1792-1803, September 2019. 1602 [13] "Cefore Home Page", . 1604 Appendix A. ccninfo Command and Options 1606 CCNinfo is implemented in Cefore [12][13]. "ccninfo" is the command 1607 invoked by the CCNinfo user (e.g., consumer). The ccninfo command 1608 sends the Request message and receives the Reply message(s). There 1609 are several options that can be specified with ccninfo, while the 1610 content name prefix (e.g., ccnx:/news/today) is the mandatory 1611 parameter. 1613 The usage of ccninfo command is as follows: 1615 Usage: ccninfo [-c] [-f] [-o] [-V] [-r hop_count] [-s hop_count] [-v 1616 algo] name_prefix 1618 name_prefix 1619 Prefix name of content (e.g., ccnx:/news/today) or exact name of 1620 content (e.g., ccnx:/news/today/Chunk=10) the CCNinfo user wants 1621 to trace. 1623 c option 1624 This option can be specified if a CCNinfo user needs the cache 1625 information as well as the routing path information for the 1626 specified content/cache and RTT between the CCNinfo user and 1627 content forwarder. 1629 f option 1630 This option enables the "full discovery request"; routers send 1631 CCNinfo Requests to multiple upstream faces based on their FIBs 1632 simultaneously. The CCNinfo user can then trace all possible 1633 forwarding paths. 1635 o option 1636 This option enables to trace the path to the content publisher. 1637 Each router along the path to the publisher inserts each Report 1638 block and forwards the Request message. It does not send Reply 1639 even if it caches the specified content. FHR that attaches the 1640 publisher (who has the complete set of content and is not a 1641 caching router) sends the Reply message. 1643 V option 1644 This option requests the Reply sender to validate the Reply 1645 message with the Reply sender's signature. The Reply message will 1646 then include the CCNx ValidationPayload TLV. The validation 1647 algorithm is selected by the Reply sender. 1649 r option 1650 Number of traced routers. This value is set in the "HopLimit" 1651 field located in the fixed header of the Request. For example, 1652 when the CCNinfo user invokes the CCNinfo command with this 1653 option, such as "-r 3", only three routers along the path examine 1654 their path and cache information. 1656 s option 1657 Number of skipped routers. This value is set in the "SkipHop" 1658 field located in the Request block TLV. For example, when the 1659 CCNinfo user invokes the CCNinfo command with this option, such as 1660 "-s 3", three upstream routers along the path only forward the 1661 Request message but do not append their Report blocks in the hop- 1662 by-hop header and do not send Reply messages despite having the 1663 corresponding cache. 1665 v option 1666 This option enables the CCNinfo user to validate the Request 1667 message with his/her signature. The Request message will include 1668 the CCNx ValidationPayload TLV. The validation algorithm is 1669 specified by the CCNinfo user. 1671 Authors' Addresses 1672 Hitoshi Asaeda 1673 National Institute of Information and Communications Technology 1674 4-2-1 Nukui-Kitamachi 1675 Koganei, Tokyo 184-8795 1676 Japan 1678 Email: asaeda@nict.go.jp 1680 Atsushi Ooka 1681 National Institute of Information and Communications Technology 1682 4-2-1 Nukui-Kitamachi 1683 Koganei, Tokyo 184-8795 1684 Japan 1686 Email: a-ooka@nict.go.jp 1688 Xun Shao 1689 Kitami Institute of Technology 1690 165 Koen-cho 1691 Kitami, Hokkaido 090-8507 1692 Japan 1694 Email: x-shao@mail.kitami-it.ac.jp