From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc9344.txt | 1869 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1869 insertions(+) create mode 100644 doc/rfc/rfc9344.txt (limited to 'doc/rfc/rfc9344.txt') diff --git a/doc/rfc/rfc9344.txt b/doc/rfc/rfc9344.txt new file mode 100644 index 0000000..a9f3969 --- /dev/null +++ b/doc/rfc/rfc9344.txt @@ -0,0 +1,1869 @@ + + + + +Internet Research Task Force (IRTF) H. Asaeda +Request for Comments: 9344 A. Ooka +Category: Experimental NICT +ISSN: 2070-1721 X. Shao + Toyohashi University of Technology + February 2023 + + +CCNinfo: Discovering Content and Network Information in Content-Centric + Networks + +Abstract + + This document describes a mechanism named "CCNinfo" that discovers + information about the network topology and in-network cache in + Content-Centric Networks (CCNs). CCNinfo investigates 1) the CCN + routing path information per name prefix, 2) the Round-Trip Time + (RTT) between the content forwarder and the consumer, and 3) the + states of in-network cache per name prefix. CCNinfo is useful to + understand and debug the behavior of testbed networks and other + experimental deployments of CCN systems. + + This document is a product of the IRTF Information-Centric Networking + Research Group (ICNRG). This document represents the consensus view + of ICNRG and has been reviewed extensively by several members of the + ICN community and the RG. The authors and RG chairs approve of the + contents. The document is sponsored under the IRTF, is not issued by + the IETF, and is not an IETF standard. This is an experimental + protocol and the specification may change in the future. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Research Task + Force (IRTF). The IRTF publishes the results of Internet-related + research and development activities. These results might not be + suitable for deployment. This RFC represents the consensus of the + Information-Centric Networking Research Group of the Internet + Research Task Force (IRTF). Documents approved for publication by + the IRSG are not candidates for any level of Internet Standard; see + Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9344. + +Copyright Notice + + Copyright (c) 2023 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction + 1.1. CCNinfo as an Experimental Tool + 2. Terminology + 2.1. Definitions + 3. CCNinfo Message Formats + 3.1. Request Message + 3.1.1. Request Header Block and Request Block + 3.1.2. Report Block TLV + 3.1.3. Content Name Specification + 3.2. Reply Message + 3.2.1. Reply Block TLV + 3.2.1.1. Reply Sub-Block TLV + 4. CCNinfo User Behavior + 4.1. Sending CCNinfo Request + 4.1.1. Routing Path Information + 4.1.2. In-Network Cache Information + 4.2. Receiving CCNinfo Reply + 5. Router Behavior + 5.1. User and Neighbor Verification + 5.2. Receiving CCNinfo Request + 5.3. Forwarding CCNinfo Request + 5.3.1. Regular Request + 5.3.2. Full Discovery Request + 5.4. Sending CCNinfo Reply + 5.5. Forwarding CCNinfo Reply + 5.6. PIT Entry Management for Multipath Support + 6. CCNinfo Termination + 6.1. Arriving at First-Hop Router + 6.2. Arriving at Router Having Cache + 6.3. Arriving at Last Router + 6.4. Invalid Request + 6.5. No Route + 6.6. No Information + 6.7. No Space + 6.8. Fatal Error + 6.9. CCNinfo Reply Timeout + 6.10. Non-Supported Node + 6.11. Administratively Prohibited + 7. Configurations + 7.1. CCNinfo Reply Timeout + 7.2. HopLimit in Fixed Header + 7.3. Access Control + 8. Diagnosis and Analysis + 8.1. Number of Hops and RTT + 8.2. Caching Router Identification + 8.3. TTL or Hop Limit + 8.4. Time Delay + 8.5. Path Stretch + 8.6. Cache Hit Probability + 9. IANA Considerations + 9.1. Packet Type Registry + 9.2. Top-Level Type Registry + 9.3. Hop-by-Hop Type Registry + 9.4. Message Type Registry + 9.5. Reply Type Registry + 10. Security Considerations + 10.1. Policy-Based Information Provisioning for Request + 10.2. Filtering CCNinfo Users Located in Invalid Networks + 10.3. Topology Discovery + 10.4. Characteristics of Content + 10.5. Computational Attacks + 10.6. Longer or Shorter CCNinfo Reply Timeout + 10.7. Limiting Request Rates + 10.8. Limiting Reply Rates + 10.9. Adjacency Verification + 11. References + 11.1. Normative References + 11.2. Informative References + Appendix A. ccninfo Command and Options + Acknowledgements + Authors' Addresses + +1. Introduction + + In Content-Centric Networks (CCNs), publishers provide the content + through the network, and receivers retrieve it by name. In this + network architecture, routers forward content requests through their + Forwarding Information Bases (FIBs), which are populated by name- + based routing protocols. CCN also enables receivers to retrieve + content from an in-network cache. + + In CCN, while consumers do not generally need to know the content + forwarder that is transmitting the content to them, the operators and + developers may want to identify the content forwarder and observe the + routing path information per name prefix for troubleshooting or + investigating the network conditions. + + IP traceroute is a useful tool for discovering the routing conditions + in IP networks because it provides intermediate router addresses + along the path between the source and the destination, and the Round- + Trip Time (RTT) for the path. However, this IP-based network tool + cannot trace the name prefix paths used in CCN. Moreover, such IP- + based network tools do not obtain the states of the in-network cache + to be discovered. + + Contrace [Contrace] enables end users (i.e., consumers) to + investigate path and in-network cache conditions in CCN. Contrace is + implemented as an external daemon process running over TCP/IP that + can interact with a previous CCNx forwarding daemon (CCNx-0.8.2) to + retrieve the caching information on the forwarding daemon. This + solution is flexible, but it requires defining the common APIs used + for global deployment in TCP/IP networks. ICN (Information-Centric + Networking) ping [ICN-PING] and traceroute [ICN-TRACEROUTE] are + lightweight operational tools that enable a user to explore the + path(s) that reach a publisher or a cache storing the named content. + ICN ping and traceroute, however, do not expose detailed information + about the forwarders deployed by a network operator. + + This document describes the specifications of "CCNinfo", an active + networking tool for discovering the path and content-caching + information in CCN. CCNinfo defines the protocol messages to + investigate path and in-network cache conditions in CCN. It is + embedded in the CCNx forwarding process and can facilitate with non- + IP networks as with the basic CCN concept. + + The two message types, Request and Reply messages, are encoded in the + CCNx TLV format [RFC8609]. The Request-and-Reply message flow, + walking up the tree from a consumer toward a publisher, is similar to + the behavior of the IP multicast traceroute facility [RFC8487]. + + CCNinfo facilitates the tracing of a routing path and provides 1) the + RTT between the content forwarder (i.e., caching router or first-hop + router) and consumer, 2) the states of the in-network cache per name + prefix, and 3) the routing path information per name prefix. + + In addition, CCNinfo identifies the states of the cache, such as the + metrics for Content Store (CS) in the content forwarder as follows: + 1) size of cached Content Objects, 2) number of cached Content + Objects, 3) number of accesses (i.e., received Interests) per + content, and 4) elapsed cache time and remaining cache lifetime of + content. + + CCNinfo supports multipath forwarding. The Request messages can be + forwarded to multiple neighbor routers. When the Request messages + are forwarded to multiple routers, the different Reply messages are + forwarded from different routers or publishers. + + Furthermore, CCNinfo implements policy-based information provisioning + that enables administrators to "hide" secure or private information + but does not disrupt message forwarding. This policy-based + information provisioning reduces the deployment barrier faced by + operators in installing and running CCNinfo on their routers. + + The document represents the consensus of the Information-Centric + Networking Research Group (ICNRG). This document was read and + reviewed by the active research group members. It is not an IETF + product and is not a standard. + +1.1. CCNinfo as an Experimental Tool + + In order to carry out meaningful experimentation with CCNx protocols, + comprehensive instrumentation and management information is needed to + take measurements and explore both the performance and robustness + characteristics of the protocols and of the applications using them. + CCNinfo's primary goal is to gather and report this information. As + experience is gained with both the CCNx protocols and CCNinfo itself, + we can refine the instrumentation capabilities and discover what + additional capabilities might be needed in CCNinfo and conversely + which features wind up not being of sufficient value to justify the + implementation complexity and execution overhead. + + CCNinfo is intended as a comprehensive experimental tool for CCNx- + based networks. It provides a wealth of information from forwarders, + including on-path in-network cache conditions as well as forwarding + path instrumentation of multiple paths toward content forwarders. As + an experimental capability that exposes detailed information about + the forwarders deployed by a network operator, CCNinfo employs more + granular authorization policies than those required of ICN ping or + ICN traceroute. + + CCNinfo uses two message types: Request and Reply. A CCNinfo user, + e.g., consumer, initiates a CCNinfo Request message when they want to + obtain routing path and cache information. When an adjacent neighbor + router receives the Request message, it examines its own cache + information. If the router does not cache the specified content, it + inserts its Report block into the hop-by-hop header of the Request + message and forwards the message to its upstream neighbor router(s) + decided by its FIB. In Figure 1, CCNinfo user and routers (Routers + A, B, C) insert their own Report blocks into the Request message and + forward the message toward the content forwarder. + + 1. Request 2. Request 3. Request + (U) (U+A) (U+A+B) + +----+ +----+ +----+ + | | | | | | + | v | v | v + +--------+ +--------+ +--------+ +--------+ +---------+ + | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| + | user | | A | | B | | C | | | + +--------+ +--------+ +--------+ +--------+ +---------+ + \ + \ +-------+ + 3. Request \ | Cache | + (U+A+B) \ +---------+ | + v| Caching |----+ + | router | + +---------+ + + Figure 1: Request Message Invoked by the CCNinfo User and + Forwarded by Routers + + When the Request message reaches the content forwarder, the content + forwarder forms the Reply message; it inserts its own Reply block TLV + and Reply sub-block TLV(s) to the Request message. The Reply message + is then forwarded back toward the user in a hop-by-hop manner along + the Pending Interest Table (PIT) entries. In Figure 2, each router + (Routers C, B, and A) forwards the Reply message along its PIT entry, + and finally, the CCNinfo user receives a Reply message from Router C, + which is the first-hop router for the publisher. Another Reply + message from the caching router (i.e., Reply(C)) is discarded at + Router B if the other Reply message (i.e., Reply(P)) was already + forwarded by Router B. + + 3. Reply(P) 2. Reply(P) 1. Reply(P) + +----+ +----+ +----+ + | | | | | | + v | v | v | + +--------+ +--------+ +--------+ +--------+ +---------+ + | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| + | user | | A | | B | | C | | | + +--------+ +--------+ +--------+ +--------+ +---------+ + ^ + \ +-------+ + 1. Reply(C) \ | Cache | + \ +---------+ | + \| Caching |----+ + | router | + +---------+ + + Figure 2: Reply Messages Forwarded by Routers, and One Reply + Message is Received by the CCNinfo User + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2.1. Definitions + + This document follows the basic terminologies and definitions + described in [RFC8609]. Although CCNinfo requests flow in the + opposite direction to the data flow, we refer to "upstream" and + "downstream" with respect to data, unless explicitly specified. + + Scheme name: + A scheme name indicates a URI and protocol. This document only + considers "ccnx:/" as the scheme name. + + Prefix name: + A prefix name, which is defined in [RFC8569], is a name that does + not uniquely identify a single Content Object, but rather a + namespace or prefix of an existing Content Object name. + + Exact name: + An exact name, which is defined in [RFC8569], is one that uniquely + identifies the name of a Content Object. + + Node: + A node within a CCN network can fulfill the role of a data + publisher, a data consumer, and/or a forwarder for Interest and + Content Object, as described in [RFC8793]. + + Consumer: + A node that requests Content Objects by generating and sending out + Interests. It is the same definition of ICN Consumer, as given in + [RFC8793]. + + Publisher: + A node that creates Content Objects and makes them available for + retrieval. It is the same definition of ICN Producer, as given in + [RFC8793]. + + Router: + A node that implements stateful forwarding in the path between + consumer and publisher. + + Caching router: + A node that temporarily stores and potentially carries Interests + or Content Objects before forwarding it to the next node. + + Content forwarder: + A content forwarder is either a caching router or a first-hop + router that forwards Content Objects to consumers. + + CCNinfo user: + A node that initiates the CCNinfo Request, which is either a + consumer or a router that invokes the CCNinfo user program with + the name prefix of the content. The CCNinfo user program, such as + "ccninfo" command described in Appendix A or other similar + commands, initiates the Request message to obtain routing path and + cache information. + + Incoming face: + The face on which data are expected to arrive from the specified + name prefix. + + Outgoing face: + The face to which data from the publisher or router are expected + to transmit for the specified name prefix. It is also the face on + which the Request messages is received. + + Upstream router: + The router that connects to an Incoming face of a router. + + Downstream router: + The router that connects to an Outgoing face of a router. + + First-hop router (FHR): + The router that matches a FIB entry with an Outgoing face + referring to a local application or a publisher. + + Last-hop router (LHR): + The router that is directly connected to a consumer. + +3. CCNinfo Message Formats + + CCNinfo Request and Reply messages are encoded in the CCNx TLV format + (see [RFC8609] and Figure 3). The Request message consists of a + fixed header, Request block TLV (Figure 5), and Report block TLV(s) + (Figure 7). The Reply message consists of a fixed header, Request + block TLV, Report block TLV(s), Reply block TLV (Figure 9), and Reply + sub-block TLV(s) (Figure 10). + + 1 2 3 + 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 + +---------------+---------------+---------------+---------------+ + | Version | PacketType | PacketLength | + +---------------+---------------+---------------+---------------+ + | PacketType specific fields | HeaderLength | + +---------------+---------------+---------------+---------------+ + / Optional Hop-by-hop header TLVs / + +---------------+---------------+---------------+---------------+ + / PacketPayload TLVs / + +---------------+---------------+---------------+---------------+ + / Optional CCNx ValidationAlgorithm TLV / + +---------------+---------------+---------------+---------------+ + / Optional CCNx ValidationPayload TLV (ValidationAlg required) / + +---------------+---------------+---------------+---------------+ + + Figure 3: Packet Format [RFC8609] + + The PacketType values in the fixed header shown in Figure 3 are + PT_CCNINFO_REQUEST and PT_CCNINFO_REPLY (see Table 1). CCNinfo + Request and Reply messages are forwarded in a hop-by-hop manner. + When the Request message reaches the content forwarder, the content + forwarder turns it into a Reply message by changing the Type field + value in the fixed header from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY + and forwards it back toward the node that initiated the Request + message. + + +======+=======================+ + | Type | Name | + +======+=======================+ + | 0x00 | PT_INTEREST [RFC8609] | + +------+-----------------------+ + | 0x01 | PT_CONTENT [RFC8609] | + +------+-----------------------+ + | 0x02 | PT_RETURN [RFC8609] | + +------+-----------------------+ + | 0x03 | PT_CCNINFO_REQUEST | + +------+-----------------------+ + | 0x04 | PT_CCNINFO_REPLY | + +------+-----------------------+ + + Table 1: CCNx Packet Types + + Following a fixed header, there can be a sequence of optional hop-by- + hop header TLV(s) for a Request message. In the case of a Request + message, it is followed by a sequence of Report blocks, each from a + router on the path toward the publisher or caching router. + + At the beginning of PacketPayload TLVs, a top-level TLV type, + T_DISCOVERY (Table 2), exists at the outermost level of a CCNx + protocol message. This TLV indicates that the Name segment TLV(s) + and Reply block TLV(s) would follow in the Request or Reply message. + + +========+================================+ + | Type | Name | + +========+================================+ + | 0x0000 | Reserved [RFC8609] | + +--------+--------------------------------+ + | 0x0001 | T_INTEREST [RFC8609] | + +--------+--------------------------------+ + | 0x0002 | T_OBJECT [RFC8609] | + +--------+--------------------------------+ + | 0x0003 | T_VALIDATION_ALG [RFC8609] | + +--------+--------------------------------+ + | 0x0004 | T_VALIDATION_PAYLOAD [RFC8609] | + +--------+--------------------------------+ + | 0x0005 | T_DISCOVERY | + +--------+--------------------------------+ + + Table 2: CCNx Top-Level Types + +3.1. Request Message + + When a CCNinfo user initiates a discovery request (e.g., via the + ccninfo command described in Appendix A), a CCNinfo Request message + is created and forwarded to its upstream router through the Incoming + face(s) determined by its FIB. + + The Request message format is shown in Figure 4. It consists of a + fixed header, Request header block TLV (Figure 5), Report block + TLV(s) (Figure 7), Name TLV, and Request block TLV. Request header + block TLV and Report block TLV(s) are contained in the hop-by-hop + header, as those might change from hop to hop. Request block TLV is + encoded in the PacketPayload TLV by content forwarder as the protocol + message itself. The PacketType value of the Request message is + PT_CCNINFO_REQUEST (Table 1). The Type value of the CCNx Top-Level + type is T_DISCOVERY (Table 2). + + 1 2 3 + 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 + +---------------+---------------+---------------+---------------+ + | Version | PacketType | PacketLength | + +---------------+---------------+---------------+---------------+ + | HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength | + +===============+===============+===============+===============+ + / Request header block TLV / + +---------------+---------------+---------------+---------------+ + / Report block TLV 1 / + +---------------+---------------+---------------+---------------+ + / Report block TLV 2 / + +---------------+---------------+---------------+---------------+ + / . / + / . / + +---------------+---------------+---------------+---------------+ + / Report block TLV n / + +===============+===============+===============+===============+ + | Type (=T_DISCOVERY) | MessageLength | + +---------------+---------------+---------------+---------------+ + | T_NAME | Length | + +---------------+---------------+---------------+---------------+ + / Name segment TLVs (name prefix specified by CCNinfo user) / + +---------------+---------------+---------------+---------------+ + / Request block TLV / + +---------------+---------------+---------------+---------------+ + / Optional CCNx ValidationAlgorithm TLV / + +---------------+---------------+---------------+---------------+ + / Optional CCNx ValidationPayload TLV (ValidationAlg required) / + +---------------+---------------+---------------+---------------+ + + Figure 4: Request Message + + HopLimit: 8 bits + + HopLimit is a counter that is decremented with each hop whenever a + Request packet is forwarded. It is specified by the CCNinfo user + program. The HopLimit value MUST be decremented by 1 prior to + forwarding the Request packet. The packet is discarded if + HopLimit is decremented to zero. HopLimit limits the distance + that a Request may travel on the network. Only the specified + number of hops from the CCNinfo user traces the Request. The last + router stops the trace and sends the Reply message back to the + CCNinfo user. + + ReturnCode: 8 bits + + ReturnCode is used for the Reply message. This value is replaced + by the content forwarder when the Request message is returned as + the Reply message (see Section 3.2). Until then, this field MUST + be transmitted as zeros and ignored on receipt. + + +=======+=================+================================+ + | Value | Name | Description | + +=======+=================+================================+ + | 0x00 | NO_ERROR | No error | + +-------+-----------------+--------------------------------+ + | 0x01 | WRONG_IF | CCNinfo Request arrived on an | + | | | interface to which this router | + | | | would not forward for the | + | | | specified name and/or function | + | | | toward the publisher. | + +-------+-----------------+--------------------------------+ + | 0x02 | INVALID_REQUEST | Invalid CCNinfo Request is | + | | | received. | + +-------+-----------------+--------------------------------+ + | 0x03 | NO_ROUTE | This router has no route for | + | | | the name prefix and no way to | + | | | determine a route. | + +-------+-----------------+--------------------------------+ + | 0x04 | NO_INFO | This router has no cache | + | | | information for the specified | + | | | name prefix. | + +-------+-----------------+--------------------------------+ + | 0x05 | NO_SPACE | There was not enough room to | + | | | insert another Report block in | + | | | the packet. | + +-------+-----------------+--------------------------------+ + | 0x06 | INFO_HIDDEN | Information is hidden from | + | | | this discovery owing to some | + | | | policy. | + +-------+-----------------+--------------------------------+ + | 0x0E | ADMIN_PROHIB | CCNinfo Request is | + | | | administratively prohibited. | + +-------+-----------------+--------------------------------+ + | 0x0F | UNKNOWN_REQUEST | This router does not support | + | | | or recognize the Request | + | | | message. | + +-------+-----------------+--------------------------------+ + | 0x80 | FATAL_ERROR | In a fatal error, the router | + | | | may know the upstream router | + | | | but cannot forward the message | + | | | to it. | + +-------+-----------------+--------------------------------+ + + Table 3: ReturnCode Used for the Reply Message + + Reserved (MBZ): 8 bits + + The reserved fields in the Value field MUST be transmitted as + zeros and ignored on receipt. + +3.1.1. Request Header Block and Request Block + + When a CCNinfo user transmits the Request message, they MUST insert + their Request header block TLV (Figure 5) into the hop-by-hop header + and Request block TLV (Figure 6) into the message before sending it + through the Incoming face(s). + + 1 2 3 + 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 + +---------------+---------------+---------------+---------------+ + | Type (=T_DISC_REQHDR) | Length | + +---------------+---------------+-------+-------+-------+-+-+-+-+ + | Request ID |SkipHop| Flags |V|F|O|C| + +---------------+---------------+-------+-------+-------+-+-+-+-+ + + Figure 5: Request Header Block TLV (Hop-by-Hop Header) + + +===============+=======================+ + | Type | Name | + +===============+=======================+ + | 0x0000 | Reserved [RFC8609] | + +---------------+-----------------------+ + | 0x0001 | T_INTLIFE [RFC8609] | + +---------------+-----------------------+ + | 0x0002 | T_CACHETIME [RFC8609] | + +---------------+-----------------------+ + | 0x0003 | T_MSGHASH [RFC8609] | + +---------------+-----------------------+ + | 0x0004-0x0007 | Reserved [RFC8609] | + +---------------+-----------------------+ + | 0x0008 | T_DISC_REQHDR | + +---------------+-----------------------+ + | 0x0009 | T_DISC_REPORT | + +---------------+-----------------------+ + | 0x0FFE | T_PAD [RFC8609] | + +---------------+-----------------------+ + | 0x0FFF | T_ORG [RFC8609] | + +---------------+-----------------------+ + | 0x1000-0x1FFF | Reserved [RFC8609] | + +---------------+-----------------------+ + + Table 4: CCNx Hop-by-Hop Types + + Type: 16 bits + + Format of the Value field. The type value of the Request header + block TLV MUST be T_DISC_REQHDR. + + Length: 16 bits + + Length of the Value field in octets. + + Request ID: 16 bits + + This field is used as a unique identifier for the CCNinfo Request + so that the duplicate or delayed Reply messages can be detected. + + SkipHop (Skip Hop Count): 4 bits + + Number of skipped routers for a Request. It is specified by the + CCNinfo user program. The number of routers corresponding to the + value specified in this field are skipped, and the CCNinfo Request + messages are forwarded to the next router without the addition of + Report blocks; the next upstream router then starts the trace. + The maximum value of this parameter is 15. This value MUST be + lower than that of HopLimit at the fixed header. + + Flags: 12 bits + + The Flags field is used to indicate the types of the content or + path discoveries. Currently, as shown in Table 5, four bits ("C", + "O", "F", and "V") are assigned, and the other 8 bits are reserved + (MBZ) for the future use. Each flag can be mutually specified + with other flags. These flags are set by the CCNinfo user program + when they initiate Requests (see Appendix A), and the routers that + receive the Requests deal with the flags and change the behaviors + (see Section 5 for details). The Flag values defined in this + Flags field correspond to the Reply sub-blocks. + + +======+=======+=====================================+ + | Flag | Value | Description | + +======+=======+=====================================+ + | C | 0 | Path discovery (i.e., no cache | + | | | information retrieved) (default) | + +------+-------+-------------------------------------+ + | C | 1 | Path and cache information | + | | | retrieval | + +------+-------+-------------------------------------+ + | O | 0 | Request to any content forwarder | + | | | (default) | + +------+-------+-------------------------------------+ + | O | 1 | Publisher discovery (i.e., only FHR | + | | | can reply) | + +------+-------+-------------------------------------+ + | F | 0 | Request based on FIB's forwarding | + | | | strategy (default) | + +------+-------+-------------------------------------+ + | F | 1 | Full discovery request. Request to | + | | | possible multiple upstream routers | + | | | specified in FIB simultaneously | + +------+-------+-------------------------------------+ + | V | 0 | No reply validation (default) | + +------+-------+-------------------------------------+ + | V | 1 | Reply sender validates Reply | + | | | message | + +------+-------+-------------------------------------+ + + Table 5: Codes and Types Specified in Flags Field + + 1 2 3 + 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 + +---------------+---------------+---------------+---------------+ + | Type (=T_DISC_REQ) | Length | + +---------------+---------------+---------------+---------------+ + | Request Arrival Time | + +---------------+---------------+---------------+---------------+ + / Node Identifier / + +---------------+---------------+---------------+---------------+ + + Figure 6: Request Block TLV (Packet Payload) + + +===============+==========================+ + | Type | Name | + +===============+==========================+ + | 0x0000 | T_NAME [RFC8609] | + +---------------+--------------------------+ + | 0x0001 | T_PAYLOAD [RFC8609] | + +---------------+--------------------------+ + | 0x0002 | T_KEYIDRESTR [RFC8609] | + +---------------+--------------------------+ + | 0x0003 | T_OBJHASHRESTR [RFC8609] | + +---------------+--------------------------+ + | 0x0005 | T_PAYLDTYPE [RFC8609] | + +---------------+--------------------------+ + | 0x0006 | T_EXPIRY [RFC8609] | + +---------------+--------------------------+ + | 0x0007-0x000C | Reserved [RFC8609] | + +---------------+--------------------------+ + | 0x000D | T_DISC_REQ | + +---------------+--------------------------+ + | 0x000E | T_DISC_REPLY | + +---------------+--------------------------+ + | 0x0FFE | T_PAD [RFC8609] | + +---------------+--------------------------+ + | 0x0FFF | T_ORG [RFC8609] | + +---------------+--------------------------+ + | 0x1000-0x1FFF | Reserved [RFC8609] | + +---------------+--------------------------+ + + Table 6: CCNx Message Types + + Type: 16 bits + + Format of the Value field. For the Request block TLV, the type + value(s) MUST be T_DISC_REQ (see Table 6) in the current + specification. + + Length: 16 bits + + Length of the Value field in octets. + + Request Arrival Time: 32 bits + + The Request Arrival Time is a 32-bit NTP timestamp specifying the + arrival time of the CCNinfo Request message at the router. The + 32-bit form of an NTP timestamp consists of the middle 32 bits of + the full 64-bit form, that is, the low 16 bits of the integer part + and the high 16 bits of the fractional part. + + The following formula converts from a timespec (fractional part in + nanoseconds) to a 32-bit NTP timestamp: + + request_arrival_time + = ((tv.tv_sec + 32384) << 16) + ((tv.tv_nsec << 7) / 1953125) + + The constant 32384 is the number of seconds from Jan 1, 1900 to + Jan 1, 1970 truncated to 16 bits. ((tv.tv_nsec << 7) / 1953125) + is a reduction of ((tv.tv_nsec / 1000000000) << 16), where "<<" + denotes a logical left shift. + + Note that it is RECOMMENDED for all the routers on the path to + have synchronized clocks to measure one-way latency per hop; + however, even if they do not have synchronized clocks, CCNinfo + measures the RTT between the content forwarder and the consumer. + + Node Identifier: variable length + + This field specifies the node identifier (e.g., node name or hash- + based self-certifying name [DCAuth]) or all-zeros if unknown. + This document assumes that the Name TLV defined in the CCNx TLV + format [RFC8609] can be used for this field and the node + identifier is specified in it. + +3.1.2. Report Block TLV + + A CCNinfo user and each upstream router along the path would insert + their own Report block TLV without changing the Type field of the + fixed header of the Request message until one of these routers is + ready to send a Reply. In the Report block TLV (Figure 7), the + Request Arrival Time and Node Identifier values MUST be inserted. + + 1 2 3 + 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 + +---------------+---------------+---------------+---------------+ + | Type (=T_DISC_REPORT) | Length | + +---------------+---------------+---------------+---------------+ + | Request Arrival Time | + +---------------+---------------+---------------+---------------+ + / Node Identifier / + +---------------+---------------+---------------+---------------+ + + Figure 7: Report Block TLV (Hop-by-Hop Header) + + Type: 16 bits + + Format of the Value field. For the Report block TLV, the type + value(s) MUST be T_DISC_REPORT in the current specification. For + all the available types of the CCNx hop-by-hop types, please see + Table 4. + + Length: 16 bits + + Length of the Value field in octets. + + Request Arrival Time: 32 bits + + Same definition as given in Section 3.1.1. + + Node Identifier: variable length + + Same definition as given in Section 3.1.1. + +3.1.3. Content Name Specification + + Specifications of the Name TLV (whose type value is T_NAME) and the + Name Segment TLVs are described in [RFC8609], which is followed by + CCNinfo. CCNinfo enables the specification of the content name with + either a prefix name without chunk number (such as "ccnx:/news/ + today") or an exact name (such as "ccnx:/news/today/Chunk=10"). When + a CCNinfo user specifies a prefix name, they will obtain the summary + information of the matched Content Objects in the content forwarder. + In contrast, when a CCNinfo user specifies an exact name, they will + obtain information only about the specified Content Object in the + content forwarder. A CCNinfo Request message MUST NOT be sent only + with a scheme name, ccnx:/. It will be rejected and discarded by + routers. + +3.2. Reply Message + + When a content forwarder receives a CCNinfo Request message from an + appropriate adjacent neighbor router, it inserts its own Reply block + TLV and Reply sub-block TLV(s) to the Request message and turns the + Request into the Reply by changing the Type field of the fixed header + of the Request message from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY. + The Reply message (see Figure 8) is then forwarded back toward the + CCNinfo user in a hop-by-hop manner. + + 1 2 3 + 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 + +---------------+---------------+---------------+---------------+ + | Version | PacketType | PacketLength | + +---------------+---------------+-------------+-+---------------+ + | HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength | + +===============+===============+=============+=+===============+ + / Request header block TLV / + +---------------+---------------+---------------+---------------+ + / . / + / . / + / n Report block TLVs / + / . / + / . / + +===============+===============+===============+===============+ + | Type (=T_DISCOVERY) | MessageLength | + +---------------+---------------+---------------+---------------+ + | T_NAME | Length | + +---------------+---------------+---------------+---------------+ + / Name segment TLVs (name prefix specified by CCNinfo user) / + +---------------+---------------+---------------+---------------+ + / Request block TLV / + +---------------+---------------+---------------+---------------+ + / Reply block TLV / + +---------------+---------------+---------------+---------------+ + / Reply sub-block TLV 1 / + +---------------+---------------+---------------+---------------+ + / . / + / . / + +---------------+---------------+---------------+---------------+ + / Reply sub-block TLV k / + +---------------+---------------+---------------+---------------+ + / Optional CCNx ValidationAlgorithm TLV / + +---------------+---------------+---------------+---------------+ + / Optional CCNx ValidationPayload TLV (ValidationAlg required) / + +---------------+---------------+---------------+---------------+ + + Figure 8: Reply Message + +3.2.1. Reply Block TLV + + The Reply block TLV is an envelope for the Reply sub-block TLV(s) + (explained in the next section). + + 1 2 3 + 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 + +---------------+---------------+---------------+---------------+ + | Type (=T_DISC_REPLY) | Length | + +---------------+---------------+---------------+---------------+ + | Request Arrival Time | + +---------------+---------------+---------------+---------------+ + / Node Identifier / + +---------------+---------------+---------------+---------------+ + + Figure 9: Reply Block TLV (Packet Payload) + + Type: 16 bits + + Format of the Value field. For the Reply block TLV, the type + value MUST be T_DISC_REPLY shown in Table 6 in the current + specification. + + Length: 16 bits + + Length of the Value field in octets. This length is the total + length of the Reply sub-block(s). + + Request Arrival Time: 32 bits + + Same definition as given in Section 3.1.1. + + Node Identifier: variable length + + Same definition as given in Section 3.1.1. + +3.2.1.1. Reply Sub-Block TLV + + The router on the traced path will add one or multiple Reply sub- + blocks followed by the Reply block TLV before sending the Reply to + its neighbor router. This section describes the Reply sub-block TLV + for informing various cache states and conditions as shown in + Figure 10. (Other Reply sub-block TLVs will be discussed in separate + document(s).) + + Note that some routers may not be capable of reporting the following + values: Object Size, Object Count, # Received Interest, First Seqnum, + Last Seqnum, Elapsed Cache Time, and Remain Cache Lifetime (shown in + Figure 10). Or, some routers do not report these values due to their + policy. In that case, the routers MUST set these fields to a value + of all ones (i.e., 0xFFFFFFFF). The value of each field MUST be also + all-one when the value is equal to or bigger than the maximum size + expressed by the 32-bit field. The CCNinfo user program MUST inform + that these values are not valid if the fields received are set to the + value of all ones. + + If the cache is refreshed after reboot, the value in each field MUST + be refreshed (i.e., MUST be set to 0). If the cache remains after + reboot, the value MUST NOT be refreshed (i.e., MUST be reflected as + it is). + + 1 2 3 + 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 + +---------------+---------------+---------------+---------------+ + | Type | Length | + +---------------+---------------+---------------+---------------+ + | Object Size | + +---------------+---------------+---------------+---------------+ + | Object Count | + +---------------+---------------+---------------+---------------+ + | # Received Interest | + +---------------+---------------+---------------+---------------+ + | First Seqnum | + +---------------+---------------+---------------+---------------+ + | Last Seqnum | + +---------------+---------------+---------------+---------------+ + | Elapsed Cache Time | + +---------------+---------------+---------------+---------------+ + | Remain Cache Lifetime | + +---------------+---------------+---------------+---------------+ + | T_NAME | Length | + +---------------+---------------+---------------+---------------+ + / Name Segment TLVs / + +---------------+---------------+---------------+---------------+ + + Figure 10: Reply Sub-Block TLV for T_DISC_CONTENT and + T_DISC_CONTENT_PUBLISHER (Packet Payload) + + +===============+===============================+ + | Type | Name | + +===============+===============================+ + | 0x0000 | T_DISC_CONTENT | + +---------------+-------------------------------+ + | 0x0001 | T_DISC_CONTENT_PUBLISHER | + +---------------+-------------------------------+ + | 0x0FFF | T_ORG | + +---------------+-------------------------------+ + | 0x1000-0x1FFF | Reserved for Experimental Use | + +---------------+-------------------------------+ + + Table 7: CCNx Reply Types + + Type: 16 bits + + Format of the Value field. For the Reply sub-block TLV, the type + value MUST be either T_DISC_CONTENT or T_DISC_CONTENT_PUBLISHER + defined in the CCNx Reply Types (Table 7). T_DISC_CONTENT is + specified when a content forwarder replies with the cache + information. T_DISC_CONTENT_PUBLISHER is specified when a FHR + attached to a publisher replies with the original content + information. + + Length: 16 bits + + Length of the Value field in octets. + + Object Size: 32 bits + + The total size (KB) of the unexpired Content Objects. Values less + than 1 KB are truncated. Note that the maximum size expressed by + the 32-bit field is approximately 4.29 TB. + + Object Count: 32 bits + + The number of the unexpired Content Objects. Note that the + maximum count expressed by the 32-bit field is approximately 4.29 + billion. + + # Received Interest: 32 bits + + The total number of the received Interest messages to retrieve the + cached Content Objects. + + First Seqnum: 32 bits + + The first sequential number of the unexpired Content Objects. + + Last Seqnum: 32 bits + + The last sequential number of the unexpired Content Objects. The + First Seqnum and Last Seqnum do not guarantee the consecutiveness + of the cached Content Objects; however, knowing these values may + help in the analysis of consecutive or discontinuous chunks such + as [CONSEC-CACHING]. + + Elapsed Cache Time: 32 bits + + The elapsed time (seconds) after the oldest Content Object of the + content is cached. + + Remain Cache Lifetime: 32 bits + + The lifetime (seconds) of a Content Object, which is lastly + cached. + +4. CCNinfo User Behavior + +4.1. Sending CCNinfo Request + + A CCNinfo user invokes a CCNinfo user program (e.g., ccninfo command) + that initiates a CCNinfo Request message and sends it to the user's + adjacent neighbor router(s) of interest. The user later obtains both + the routing path information and in-network cache information in the + single Reply. + + When the CCNinfo user program initiates a Request message, it MUST + insert the necessary values, i.e., the "Request ID" and the "Node + Identifier", in the Request block. The Request ID MUST be unique for + the CCNinfo user until they receive the corresponding Reply + message(s) or the Request is timed out. + + Owing to some policies, a router may want to validate the CCNinfo + Requests using the CCNx ValidationPayload TLV (whether it accepts the + Request or not) especially when the router receives the "full + discovery request" (see Section 5.3.2). Accordingly, the CCNinfo + user program MAY require validating the Request message and appending + the user's signature into the CCNx ValidationPayload TLV. The router + then forwards the Request message. If the router does not approve + the Request, it rejects the Request message as described in + Section 6.11. + + After the CCNinfo user program sends the Request message, until the + Reply is timed out or the expected numbers of Replies or a Reply + message with a non-zero ReturnCode in the fixed header is received, + the CCNinfo user program MUST keep the following information: + HopLimit (specified in the fixed header), Request ID and Flags + (specified in the Request header block), and Node Identifier and + Request Arrival Time (specified in the Request block). + +4.1.1. Routing Path Information + + A CCNinfo user can send a CCNinfo Request for investigating the + routing path information for the specified named content. Using the + Request, a legitimate user can obtain 1) the node identifiers of the + intermediate routers, 2) the node identifier of the content + forwarder, 3) the number of hops between the content forwarder and + the consumer, and 4) the RTT between the content forwarder and the + consumer, per name prefix. This CCNinfo Request is terminated when + it reaches the content forwarder. + +4.1.2. In-Network Cache Information + + A CCNinfo user can send a CCNinfo Request for investigating in- + network cache information. Using the Request, a legitimate user can + obtain 1) the size of cached Content Objects, 2) the number of cached + Content Objects, 3) the number of accesses (i.e., received Interests) + per content, and 4) the lifetime and expiration time of the cached + Content Objects, for Content Store (CS) in the content forwarder, + unless the content forwarder is capable of reporting them (see + Section 3.2.1.1). This CCNinfo Request is terminated when it reaches + the content forwarder. + +4.2. Receiving CCNinfo Reply + + A CCNinfo user program will receive one or multiple CCNinfo Reply + messages from the adjacent neighbor router(s). When the program + receives the Reply, it MUST compare the kept Request ID and Node + Identifier values to identify the Request and Reply pair. If they do + not match, the Reply message MUST be silently discarded. + + If the number of Report blocks in the received Reply is more than the + initial HopLimit value (which was inserted in the original Request), + the Reply MUST be silently ignored. + + After the CCNinfo user has determined that they have traced the whole + path or the maximum path that they can be expected to, they might + collect statistics by waiting for a timeout. Useful statistics + provided by CCNinfo are stated in Section 8. + +5. Router Behavior + +5.1. User and Neighbor Verification + + Upon receiving a CCNinfo Request message, a router MAY examine + whether a valid CCNinfo user has sent the message. If the router + recognizes that the Request sender's signature specified in the + Request is invalid, it SHOULD terminate the Request, as defined in + Section 6.4. + + Upon receiving a CCNinfo Request or Reply message, a router MAY + examine whether the message comes from a valid adjacent neighbor + node. If the router recognizes that the Request or Reply sender is + invalid, it SHOULD silently ignore the message, as specified in + Section 10.9. + +5.2. Receiving CCNinfo Request + + After a router accepts the CCNinfo Request message, it performs the + following steps. + + 1. The value of "HopLimit" in the fixed header and the value of + "SkipHop (Skip Hop Count)" in the Request block are counters that + are decremented with each hop. If the HopLimit value is zero, + the router terminates the Request, as defined in Section 6.5. If + the SkipHop value is equal to or more than the HopLimit value, + the router terminates the Request, as defined in Section 6.4; + otherwise, until the SkipHop value becomes zero, the router + forwards the Request message to the upstream router(s) without + adding its own Report block and without replying to the Request. + If the router does not know the upstream router(s) regarding the + specified name prefix, it terminates the Request, as defined in + Section 6.5. It should be noted that the Request messages are + terminated at the FHR; therefore, although the maximum value for + the HopLimit is 255 and that for SkipHop is 15, if the Request + messages reach the FHR before the HopLimit or SkipHop value + becomes 0, the FHR silently discards the Request message and the + Request is timed out. + + 2. The router examines the Flags field (specified in Table 5) in the + Request block of the received CCNinfo Request. If the "C" flag + is not set, it is categorized as the "routing path information + discovery". If the "C" flag is set, it is the "cache information + discovery". If the "O" flag is set, it is the "publisher + discovery". + + 3. If the Request is either "cache information discovery" or + "routing path information discovery", the router examines its FIB + and CS. If the router caches the specified content, it sends the + Reply message with its own Reply block and sub-block(s). If the + router cannot insert its own Reply block or sub-block(s) because + of no space, it terminates the Request, as specified in + Section 6.7. If the router does not cache the specified content + but knows the upstream neighbor router(s) for the specified name + prefix, it creates the PIT entry, inserts its own Report block in + the hop-by-hop header, and forwards the Request to the upstream + neighbor(s). If the router cannot insert its own Report block + because of no space, or if the router does not cache the + specified content and does not know the upstream neighbor + router(s) for the specified name prefix, it terminates the + Request, as defined in Section 6.5. + + 4. If the Request is the "publisher discovery", the router examines + whether it is the FHR for the requested content. If the router + is the FHR, it sends the Reply message with its own Report block + and sub-blocks (in the case of cache information discovery) or + the Reply message with its own Report block without adding any + Reply sub-blocks (in the case of routing path information + discovery). If the router is not the FHR but knows the upstream + neighbor router(s) for the specified name prefix, it creates the + PIT entry, inserts its own Report block, and forwards the Request + to the upstream neighbor(s). If the router cannot insert its own + Report block in the hop-by-hop header because of no space, it + terminates the Request, as specified in Section 6.7. If the + router is not the FHR and does not know the upstream neighbor + router(s) for the specified name prefix, it terminates the + Request, as defined in Section 6.5. Note that in Cefore + [Cefore-site], there is an API by which a publisher informs the + application prefix to the FHR, and the FHR registers it into the + FIB. The prefix entry then can be statically configured on other + routers or announced by a routing protocol. + +5.3. Forwarding CCNinfo Request + +5.3.1. Regular Request + + When a router decides to forward a Request message with its Report + block to its upstream router(s), it specifies the Request Arrival + Time and Node Identifier values in the Report block of the Request + message. The router then forwards the Request message upstream + toward the publisher or caching router based on the FIB entry like + the ordinary Interest-Data exchanges in CCN. + + When the router forwards the Request message, it MUST record the F + flag and Request ID in the Request block of the Request message and + exploiting path labels (specified in Section 1) at the corresponding + PIT entry. The router can later check the PIT entry to correctly + forward the Reply message(s) back. + + CCNinfo supports multipath forwarding. The Request messages can be + forwarded to multiple neighbor routers. Some routers may have a + strategy for multipath forwarding; when a router sends Interest + messages to multiple neighbor routers, it may delay or prioritize to + send the message to the upstream routers. The CCNinfo Request, as + the default, complies with such strategies; a CCNinfo user could + trace the actual forwarding path based on the forwarding strategy and + will receive a single Reply message such as a Content Object. + +5.3.2. Full Discovery Request + + There may be a case wherein a CCNinfo user wants to discover all + possible forwarding paths and content forwarders based on the + routers' FIBs. The "full discovery request" enables this + functionality. If a CCNinfo user sets the F flag in the Request + block of the Request message (as seen in Table 5) to request the full + discovery, the upstream routers simultaneously forward the Requests + to all multiple upstream routers based on the FIBs. Then, the + CCNinfo user can trace all possible forwarding paths. As seen in + Figure 11, each router forwards the Reply message along its PIT + entry, and finally, the CCNinfo user receives two Reply messages: one + from the FHR (Router C) and the other from the Caching router. + + 3. Reply(C) 2. Reply(C) + 3. Reply(P) 2. Reply(P) 1. Reply(P) + +----+ +----+ +----+ + | | | | | | + v | v | v | + +--------+ +--------+ +--------+ +--------+ +---------+ + | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| + | user | | A | | B | | C | | | + +--------+ +--------+ +--------+ +--------+ +---------+ + ^ + \ +-------+ + 1. Reply(C) \ | Cache | + \ +---------+ | + \| Caching |----+ + | router | + +---------+ + + Figure 11: Full Discovery Request: Reply Messages Forwarded by + the Publisher and Routers + + To receive different Reply messages forwarded from different routers, + the PIT entries initiated by CCNinfo remain until the configured + CCNinfo Reply Timeout (Section 7.1) is expired. In other words, + unlike the ordinary Interest-Data exchanges in CCN, if routers that + accept the full discovery request receive the full discovery request, + the routers SHOULD NOT remove the PIT entry created by the full + discovery request until the CCNinfo Reply Timeout value expires. + + Note that the full discovery request is an OPTIONAL implementation of + CCNinfo; it may not be implemented on routers. Even if it is + implemented on a router, it may not accept the full discovery request + from non-validated CCNinfo users or routers or because of its policy. + If a router does not accept the full discovery request, it rejects + the full discovery request as described in Section 6.11. Routers + that enable the full discovery request MAY rate-limit Replies, as + described in Section 10.8 as well. + +5.4. Sending CCNinfo Reply + + If there is a caching router or FHR for the specified content within + the specified hop count along the path, the caching router or FHR + sends back the Reply message toward the CCNinfo user and terminates + the Request. + + When a router decides to send a Reply message to its downstream + neighbor router or the CCNinfo user with a NO_ERROR return code, it + inserts a Report block with the Request Arrival Time and Node + Identifier values to the Request message. Then, the router inserts + the corresponding Reply sub-block(s) (Figure 10) to the payload. The + router finally changes the Type field in the fixed header from + PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY and forwards the message back + as the Reply toward the CCNinfo user in a hop-by-hop manner. + + If a router cannot continue the Request, the router MUST put an + appropriate ReturnCode in the Request message, change the Type field + value in the fixed header from PT_CCNINFO_REQUEST to + PT_CCNINFO_REPLY, and forward the Reply message back toward the + CCNinfo user to terminate the Request (see Section 6). + +5.5. Forwarding CCNinfo Reply + + When a router receives a CCNinfo Reply whose Request ID and Node + Identifier values match those in the PIT entry, which is sent from a + valid adjacent neighbor router, it forwards the CCNinfo Reply back + toward the CCNinfo user. If the router does not receive the + corresponding Reply within the [CCNinfo Reply Timeout] period, then + it removes the corresponding PIT entry and terminates the trace. + + The Flags field in the Request block TLV is used to indicate whether + the router keeps the PIT entry during the CCNinfo Reply Timeout even + after one or more corresponding Reply messages are forwarded. When + the CCNinfo user does not set the F flag (i.e., "0"), the + intermediate routers immediately remove the PIT entry whenever they + forward the corresponding Reply message. When the CCNinfo user sets + the F flag (i.e., "1"), which means the CCNinfo user chooses the + "full discovery request" (see Section 5.3.2), the intermediate + routers keep the PIT entry within the [CCNinfo Reply Timeout] period. + After this timeout, the PIT entry is removed. + + CCNinfo Replies MUST NOT be cached in routers upon the transmission + of Reply messages. + +5.6. PIT Entry Management for Multipath Support + + Within a network with a multipath condition, there is a case + (Figure 12) wherein a single CCNinfo Request is split into multiple + Requests (e.g., at Router A), which are injected into a single router + (Router D). In this case, multiple Replies with the same Request ID + and Node Identifier values, including different Report blocks, are + received by the router (Router D). + + +--------+ + | Router | + | B | + +--------+ + / \ + / \ + +--------+ +--------+ +--------+ +---------+ + | CCNinfo|----| Router | | Router | ... |Publisher| + | user | | A | | D | | | + +--------+ +--------+ +--------+ +---------+ + \ / + \ / + +--------+ + | Router | + | C | + +--------+ + + Figure 12: An Example of Multipath Network Topology + + To recognize different CCNinfo Reply messages, the routers MUST + distinguish the PIT entries by the Request ID and exploiting path + labels, which could be a hash value of the concatenation information + of the cumulate node identifiers in the hop-by-hop header and the + specified content name. For example, when Router D in Figure 12 + receives a CCNinfo Request from Router B, its PIT includes the + Request ID and value such as H((Router_A|Router_B)|content_name), + where "H" indicates some hash function and "|" indicates + concatenation. When Router D receives a CCNinfo Request from Router + C, its PIT includes the same Request ID and value of + H((Router_A|Router_C)|content_name). Two different Replies are later + received on Router D, and each Reply is appropriately forwarded to + Router B and Router C, respectively. Note that two Reply messages + coming from Router B and Router C are reached at Router A, but the + CCNinfo user can only receive the first Reply message either from + Router B or Router C as Router A removes the corresponding PIT entry + after it forwards the first Reply. + + To avoid routing loops, when a router seeks the cumulate node + identifiers of the Report blocks in the hop-by-hop header, it MUST + examine whether its own node identifier is not previously inserted. + If a router detects its own node identifier in the hop-by-hop header, + the router inserts its Report block and terminates the Request as + will be described in Section 6.8. + +6. CCNinfo Termination + + When performing a hop-by-hop trace, it is necessary to determine when + to stop the trace. There are several cases when an intermediate + router might return a Reply before a Request reaches the caching + router or the FHR. + +6.1. Arriving at First-Hop Router + + A CCNinfo Request can be determined to have arrived at the FHR. To + ensure that a router recognizes that it is the FHR for the specified + content, it needs to have a FIB entry (or to attach) to the + corresponding publisher or the content. + +6.2. Arriving at Router Having Cache + + A CCNinfo Request can be determined to have arrived at the router + having the specified content cache within the specified HopLimit. + +6.3. Arriving at Last Router + + A CCNinfo Request can be determined to have arrived at the last + router of the specified HopLimit. If the last router does not have + the corresponding cache, it MUST insert its Report block and send the + Reply message with a NO_INFO return code without appending any Reply + block or sub-block TLVs. + +6.4. Invalid Request + + If the router does not validate the Request or the Reply even it is + required, the router MUST note a ReturnCode of INVALID_REQUEST in the + fixed header of the message, insert its Report block, and forward the + message as the Reply back to the CCNinfo user. The router MAY, + however, randomly ignore the received invalid messages. (See + Section 10.7.) + +6.5. No Route + + If the router cannot determine the routing paths or neighbor routers + for the specified name prefix within the specified HopLimit, it MUST + note a ReturnCode of NO_ROUTE in the fixed header of the message, + insert its Report block, and forward the message as the Reply back to + the CCNinfo user. + +6.6. No Information + + If the router does not have any information about the specified name + prefix within the specified HopLimit, it MUST note a ReturnCode of + NO_INFO in the fixed header of the message, insert its Report block, + and forward the message as the Reply back to the CCNinfo user. + +6.7. No Space + + If appending the Report block, the Reply block, or Reply sub-block + would make the hop-by-hop header longer than 247 bytes or the Request + packet longer than the MTU of the Incoming face, the router MUST note + a ReturnCode of NO_SPACE in the fixed header of the message and + forward the message as the Reply back to the CCNinfo user. + +6.8. Fatal Error + + If a CCNinfo Request has encountered a fatal error, the router MUST + note a ReturnCode of FATAL_ERROR in the fixed header of the message + and forward the message as the Reply back to the CCNinfo user. This + may happen, for example, when the router detects some routing loop in + the Request blocks (see Section 1). The fatal error can be encoded + with another error: if a router detects routing loop but cannot + insert its Report block, it MUST note NO_SPACE and FATAL_ERROR + ReturnCodes (i.e., 0x85) in the fixed header and forward the message + back to the CCNinfo user. + +6.9. CCNinfo Reply Timeout + + If a router receives the Request or Reply message that expires its + own [CCNinfo Reply Timeout] value (Section 7.1), the router will + silently discard the Request or Reply message. + +6.10. Non-Supported Node + + Cases will arise in which a router or a FHR along the path does not + support CCNinfo. In such cases, a CCNinfo user and routers that + forward the CCNinfo Request will time out the CCNinfo request. + +6.11. Administratively Prohibited + + If CCNinfo is administratively prohibited, the router rejects the + Request message and MUST send the CCNinfo Reply with the ReturnCode + of ADMIN_PROHIB. The router MAY, however, randomly ignore the + Request messages to be rejected (see Section 10.7). + +7. Configurations + +7.1. CCNinfo Reply Timeout + + The [CCNinfo Reply Timeout] value is used to time out a CCNinfo + Reply. The value for a router can be statically configured by the + router's administrators and/or operators. The default value is 3 + (seconds). The [CCNinfo Reply Timeout] value SHOULD NOT be larger + than 4 (seconds) and SHOULD NOT be lower than 2 (seconds). + +7.2. HopLimit in Fixed Header + + If a CCNinfo user does not specify the HopLimit value in the fixed + header for a Request message as the HopLimit, the HopLimit is set to + 32. Note that 0 HopLimit is an invalid Request; hence, the router in + this case follows the way defined in Section 6.4. + +7.3. Access Control + + A router MAY configure the valid or invalid networks to enable an + access control. The access control MAY be defined per name prefix, + such as "who can retrieve which name prefix" (see Section 10.2). + +8. Diagnosis and Analysis + +8.1. Number of Hops and RTT + + A CCNinfo Request message is forwarded in a hop-by-hop manner and + each forwarding router appends its own Report block. We can then + verify the number of hops to reach the content forwarder or publisher + and the RTT between the content forwarder or publisher. + +8.2. Caching Router Identification + + While some routers may hide their node identifiers with all-zeros in + the Report blocks (as seen in Section 10.1), the routers in the path + from the CCNinfo user to the content forwarder can be identified. + +8.3. TTL or Hop Limit + + By taking the HopLimit from the content forwarder and forwarding the + TTL threshold over all hops, it is possible to discover the TTL or + hop limit required for the content forwarder to reach the CCNinfo + user. + +8.4. Time Delay + + If the routers have synchronized clocks, it is possible to estimate + the propagation and queuing delays from the differences between the + timestamps at the successive hops. However, this delay includes the + control processing overhead; therefore, it is not necessarily + indicative of the delay that would be experienced by the data + traffic. + +8.5. Path Stretch + + By obtaining the path stretch "d / P", where "d" is the hop count of + the data and "P" is the hop count from the consumer to the publisher, + we can measure the improvements in path stretch in various cases, + such as in different caching and routing algorithms. We can then + facilitate the investigation of the performance of the protocol. + +8.6. Cache Hit Probability + + CCNinfo can show the number of received Interests per cache or chunk + on a router. Accordingly, CCNinfo measures the content popularity + (i.e., the number of accesses for each content and/or cache), thereby + enabling the investigation of the routing/caching strategy in + networks. + +9. IANA Considerations + + This section details each kind of CCNx protocol value that has been + registered. As per [RFC8126], four assignments have been made in + existing registries, and a new Reply Type registry has been created + in the "Content-Centric Networking (CCNx)" registry group. + +9.1. Packet Type Registry + + As shown in Table 1, CCNinfo defines two packet types, + PT_CCNINFO_REQUEST and PT_CCNINFO_REPLY, whose values are 0x03 and + 0x04, respectively. + +9.2. Top-Level Type Registry + + As shown in Table 2, CCNinfo defines one top-level type, T_DISCOVERY, + whose value is 0x0005. + +9.3. Hop-by-Hop Type Registry + + As shown in Table 4, CCNinfo defines two hop-by-hop types, + T_DISC_REQHDR and T_DISC_REPORT, whose values are 0x0008 and 0x0009, + respectively. + +9.4. Message Type Registry + + As shown in Table 6, CCNinfo defines two message types, T_DISC_REQ + and T_DISC_REPLY, whose values are 0x000D and 0x000E, respectively. + +9.5. Reply Type Registry + + IANA has created the "CCNx Reply Types" registry and allocated the + reply types. The registration procedure is "RFC Required" [RFC8126]. + The Type value is 2 octets. The range is 0x0000-0xFFFF. As shown in + Table 7, CCNinfo defines three reply types, T_DISC_CONTENT, + T_DISC_CONTENT_PUBLISHER, and T_ORG, whose values are 0x0000, 0x0001, + and 0x0FFF, respectively. + +10. Security Considerations + + This section addresses some of the security considerations. + +10.1. Policy-Based Information Provisioning for Request + + Although CCNinfo gives excellent troubleshooting cues, some network + administrators or operators may not want to disclose everything about + their network to the public or may wish to securely transmit private + information to specific members of their networks. CCNinfo provides + policy-based information provisioning, thereby allowing network + administrators to specify their response policy for each router. + + The access policy regarding "who is allowed to retrieve" and/or "what + kind of cache information" can be defined for each router. For the + former type of access policy, routers with the specified content MAY + examine the signature enclosed in the Request message and decide + whether they should notify the content information in the Reply. If + the routers decide to not notify the content information, they MUST + send the CCNinfo Reply with the ReturnCode of ADMIN_PROHIB without + appending any Reply block or sub-block TLVs. For the latter type of + policy, the permission, whether (1) All (all cache information is + disclosed), (2) Partial (cache information with a particular name + prefix can (or cannot) be disclosed), or (3) Deny (no cache + information is disclosed), is defined at the routers. + + In contrast, we entail that each router does not disrupt the + forwarding of CCNinfo Request and Reply messages. When a Request + message is received, the router SHOULD insert the Report block if the + ReturnCode is NO_ERROR. Here, according to the policy configuration, + the Node Identifier field in the Report block MAY be null (i.e., all- + zeros), but the Request Arrival Time field SHOULD NOT be null. + Finally, the router SHOULD forward the Request message to the + upstream router toward the content forwarder if the ReturnCode is + kept with NO_ERROR. + +10.2. Filtering CCNinfo Users Located in Invalid Networks + + A router MAY support an access control mechanism to filter out + Requests from invalid CCNinfo users. To accomplish this, invalid + networks (or domains) could, for example, be configured via a list of + allowed or disallowed networks (as observed in Section 7.3). If a + Request is received from a disallowed network (according to the node + identifier in the Request block), the Request MUST NOT be processed + and the Reply with the ReturnCode of INFO_HIDDEN SHOULD be used to + note that. The router MAY, however, perform rate-limited logging of + such events. + +10.3. Topology Discovery + + CCNinfo can be used to discover actively used topologies. If a + network topology is not disclosed, CCNinfo Requests SHOULD be + restricted at the border of the domain using the ADMIN_PROHIB return + code. + +10.4. Characteristics of Content + + CCNinfo can be used to discover the type of content being sent by + publishers. If this information is a secret, CCNinfo Requests SHOULD + be restricted at the border of the domain, using the ADMIN_PROHIB + return code. + +10.5. Computational Attacks + + CCNinfo may impose heavy tasks at content forwarders because it makes + content forwarders seek their internal cache states reported in the + Reply messages whenever they form the Reply messages. The current + CCNinfo specification allows to return null values for several + fields, such as First/Last Seqnum or Elapsed Cache Time fields in the + Reply sub-block. As mentioned in Section 3.2.1.1, these values MAY + be null. This means that the content forwarder cannot only hide + these values owing to privacy and security policies but also skip the + implementations of the complex functions to report these values. + +10.6. Longer or Shorter CCNinfo Reply Timeout + + Routers can configure CCNinfo Reply Timeout (Section 7.1), which is + the allowable timeout value to keep the PIT entry. If routers + configure a longer timeout value, there may be an attractive attack + vector against the PIT memory. Moreover, especially when the full + discovery request option (Section 5.3) is specified for the CCNinfo + Request, several Reply messages may be returned and cause a response + storm. (See Section 10.8 for rate-limiting to avoid the storm). To + avoid DoS attacks, routers MAY configure the timeout value, which is + shorter than the user-configured CCNinfo timeout value. However, if + it is too short, the Request may be timed out and the CCNinfo user + does not receive all Replies; they only retrieve the partial path + information (i.e., information about a part of the tree). + + There may be a way to enable incremental exploration (i.e., to + explore the part of the tree that was not explored by the previous + operation); however, discussing such mechanisms is out of scope of + this document. + +10.7. Limiting Request Rates + + A router MAY rate-limit CCNinfo Requests by ignoring some of the + consecutive messages. The router MAY randomly ignore the received + messages to minimize the processing overhead, i.e., to keep fairness + in processing requests or to prevent traffic amplification. In such + a case, no error message is returned. The rate limit function is + left to the router's implementation. + +10.8. Limiting Reply Rates + + CCNinfo supporting multipath forwarding may result in one Request + returning multiple Reply messages. To prevent abuse, the routers in + the traced path MAY need to rate-limit the Replies. In such a case, + no error message is returned. The rate limit function is left to the + router's implementation. + +10.9. Adjacency Verification + + It is assumed that the CCNinfo Request and Reply messages are + forwarded by adjacent neighbor nodes or routers. The CCNx message + format or semantics do not define a secure way to verify the node + and/or router adjacency, while a hop-by-hop authentication such as + [DCAuth] provides a possible method for an adjacency verification and + defines the corresponding message format for adjacency verification + as well as the router behaviors. CCNinfo MAY use a similar method + for node adjacency verification. + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric + Networking (CCNx) Semantics", RFC 8569, + DOI 10.17487/RFC8569, July 2019, + . + + [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric + Networking (CCNx) Messages in TLV Format", RFC 8609, + DOI 10.17487/RFC8609, July 2019, + . + +11.2. Informative References + + [Cefore] Asaeda, H., Ooka, A., Matsuzono, K., and R. Li, "Cefore: + Software Platform Enabling Content-Centric Networking and + Beyond", IEICE Transaction on Communications, Volume + E102-B, Issue 9, pp. 1792-1803, + DOI 10.1587/transcom.2018EII0001, September 2019, + . + + [Cefore-site] + "Cefore", . + + [CONSEC-CACHING] + Li, R., Matsuzono, K., Asaeda, H., and X. Fu, "Consecutive + Caching and Adaptive Retrieval for In-Network Big Data + Sharing", Proc. IEEE ICC, Kansas City, MO, USA, + DOI 10.1109/ICC.2018.8422233, May 2018, + . + + [Contrace] Asaeda, H., Matsuzono, K., and T. Turletti, "Contrace: A + tool for measuring and tracing content-centric networks", + IEEE Communications Magazine, Vol. 53, No. 3, pp. 182-188, + DOI 10.1109/MCOM.2015.7060502, March 2015, + . + + [DCAuth] Li, R., Asaeda, H., and J. Wu, "DCAuth: Data-Centric + Authentication for Secure In-Network Big-Data Retrieval", + IEEE Transactions on Network Science and Engineering, Vol. + 7, No. 1, pp. 15-27, DOI 10.1109/TNSE.2018.2872049, + October 2018, . + + [ICN-PING] Mastorakis, S., Oran, D., Gibson, J., Moiseenko, I., and + R. Droms, "ICN Ping Protocol Specification", Work in + Progress, Internet-Draft, draft-irtf-icnrg-icnping-07, 16 + October 2022, . + + [ICN-TRACEROUTE] + Mastorakis, S., Oran, D., Moiseenko, I., Gibson, J., and + R. Droms, "ICN Traceroute Protocol Specification", Work in + Progress, Internet-Draft, draft-irtf-icnrg-icntraceroute- + 07, 16 October 2022, + . + + [RFC8487] Asaeda, H., Meyer, K., and W. Lee, Ed., "Mtrace Version 2: + Traceroute Facility for IP Multicast", RFC 8487, + DOI 10.17487/RFC8487, October 2018, + . + + [RFC8793] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, + D., and C. Tschudin, "Information-Centric Networking + (ICN): Content-Centric Networking (CCNx) and Named Data + Networking (NDN) Terminology", RFC 8793, + DOI 10.17487/RFC8793, June 2020, + . + +Appendix A. ccninfo Command and Options + + CCNinfo is implemented in Cefore [Cefore] [Cefore-site]. The command + invoked by the CCNinfo user (e.g., consumer) is named "ccninfo". The + ccninfo command sends the Request message and receives the Reply + message(s). There are several options that can be specified with + ccninfo, while the content name prefix (e.g., ccnx:/news/today) is + the mandatory parameter. + + The usage of the ccninfo command is as follows: + + ccninfo [-c] [-f] [-o] [-V] [-r hop_count] [-s hop_count] + [-v algorithm] name_prefix + + name_prefix: + The prefix name of content (e.g., ccnx:/news/today) or exact name + of content (e.g., ccnx:/news/today/Chunk=10) the CCNinfo user + wants to trace. + + c option: + This option can be specified if a CCNinfo user needs the cache + information as well as the routing path information for the + specified content/cache and RTT between the CCNinfo user and + content forwarder. + + f option: + This option enables the "full discovery request"; routers send + CCNinfo Requests to multiple upstream faces based on their FIBs + simultaneously. The CCNinfo user can then trace all possible + forwarding paths. + + o option: + This option enables the tracing of the path to the content + publisher. Each router along the path to the publisher inserts + each Report block and forwards the Request message. It does not + send Reply even if it caches the specified content. FHR that + attaches the publisher (who has the complete set of content and is + not a caching router) sends the Reply message. + + V option: + This option requests the Reply sender to validate the Reply + message with the Reply sender's signature. The Reply message will + then include the CCNx ValidationPayload TLV. The validation + algorithm is selected by the Reply sender. + + r option: + The number of traced routers. This value is set in the "HopLimit" + field located in the fixed header of the Request. For example, + when the CCNinfo user invokes the ccninfo command with this + option, such as "-r 3", only three routers along the path examine + their path and cache information. + + s option: + The number of skipped routers. This value is set in the "SkipHop" + field located in the Request block TLV. For example, when the + CCNinfo user invokes the ccninfo command with this option, such as + "-s 3", three upstream routers along the path only forward the + Request message but do not append their Report blocks in the hop- + by-hop header and do not send Reply messages despite having the + corresponding cache. + + v option: + This option enables the CCNinfo user to validate the Request + message with their signature. The Request message will include + the CCNx ValidationPayload TLV. The validation algorithm is + specified by the CCNinfo user. + +Acknowledgements + + The authors would like to thank Jérôme François, Erik Kline, Spyridon + Mastorakis, Paulo Mendes, Ilya Moiseenko, David Oran, and Thierry + Turletti for their valuable comments and suggestions on this + document. + +Authors' Addresses + + Hitoshi Asaeda + National Institute of Information and Communications Technology + 4-2-1 Nukui-Kitamachi, Koganei, Tokyo + 184-8795 + Japan + Email: asaeda@nict.go.jp + + + Atsushi Ooka + National Institute of Information and Communications Technology + 4-2-1 Nukui-Kitamachi, Koganei, Tokyo + 184-8795 + Japan + Email: a-ooka@nict.go.jp + + + Xun Shao + Toyohashi University of Technology + 1-1 Hibarigaoka Tempaku-cho, Toyohashi, Aichi + 441-8580 + Japan + Email: shao.xun.ls@tut.jp -- cgit v1.2.3