RFC 9344
CCNinfo: Discovering Content and Network Information in Content-Centric Networks
RFC 9344: CCNinfo 🦋
Okay bestie, RFC 9344 is called CCNinfo: Discovering Content and Network Information in Content-Centric Networks 💖 It's an Experimental doc from the IRTF, the research side of the internet world, not the IETF standards side 🧪 It came out in February 2023 and has three authors: H. Asaeda and A. Ooka from NICT, and X. Shao from Toyohashi University of Technology 👑 It's a product of the Information-Centric Networking Research Group (ICNRG), and its ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates, so it's standing on its own 🌸
Abstract ✨
Okay, so this doc describes a mechanism called "CCNinfo" 🔍 It finds out stuff about the network topology and the in-network cache in Content-Centric Networks (CCNs) 🧚 CCNinfo looks into three things:
- the CCN routing path information per name prefix,
- the Round-Trip Time (RTT) between the content forwarder and the consumer, and
- the states of in-network cache per name prefix.
It's giving debugging superpowers for testbed networks and other experimental CCN deployments 🛠️💅
This doc is a product of the IRTF Information-Centric Networking Research Group (ICNRG) 🌈 It represents the consensus view of ICNRG and got reviewed really thoroughly by several ICN community members and the RG 🫶 The authors and RG chairs approve of the contents. It's sponsored under the IRTF, it's not issued by the IETF, and it's not an IETF standard 🙈 This is an experimental protocol, so the spec might change later on 🦋
Status of This Memo ✨
Ngl, this part is the fine print 📜 This document isn't an Internet Standards Track specification. It's published so people can examine it, try it out in experimental implementations, and evaluate it 🔬
It defines an Experimental Protocol for the Internet community and is a product of the Internet Research Task Force (IRTF) 🌸 The IRTF publishes results of Internet-related research and development, and those results might not be suitable for deployment 💀 This RFC represents the consensus of the Information-Centric Networking Research Group of the IRTF. Documents the IRSG approves for publication are not candidates for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the full story 🎀
Info about the current status of this doc, any errata, and how to send feedback lives 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) as they're in effect on the date of publication 📄 Please read those carefully, because they spell out your rights and restrictions for 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' Addresses1. Introduction 🌷
So in Content-Centric Networks (CCNs), publishers provide content through the network, and receivers grab it by name 🎀 Routers forward content requests through their Forwarding Information Bases (FIBs), which get filled in by name-based routing protocols 🛣️ CCN also lets receivers pull content from an in-network cache 🍓
Here's the thing: consumers don't usually need to know which content forwarder is sending them stuff 🙈 But operators and developers might want to identify the content forwarder and check the routing path information per name prefix, for troubleshooting or to figure out what's going on with the network 🔍
IP traceroute is a super useful tool for checking routing in IP networks, because it gives you the intermediate router addresses between source and destination, plus the RTT for the path 💅 But it can't trace the name prefix paths CCN uses, and these IP tools don't pull the in-network cache states you want to find 💀 Contrace [Contrace] lets end users (aka consumers) poke at path and in-network cache conditions in CCN 🧚 It runs as an external daemon over TCP/IP and talks to an older CCNx forwarding daemon (CCNx-0.8.2) to get caching info from it. It's flexible, but it needs common APIs defined for global TCP/IP deployment, which is a whole thing 😭 ICN (Information-Centric Networking) ping [ICN-PING] and traceroute [ICN-TRACEROUTE] are lightweight operational tools that let a user explore the path(s) to a publisher or to a cache holding the named content ✨ They don't expose detailed info about the forwarders a network operator deployed, though 🙃
This document describes "CCNinfo," an active networking tool for discovering path and content-caching info in CCN 🦋 It defines the protocol messages for investigating path and in-network cache conditions in CCN 🫶 It's embedded in the CCNx forwarding process, and it works with non-IP networks just like the basic CCN concept does 🌈
The two message types, Request and Reply messages, are encoded in the CCNx TLV format [RFC8609] 💜 The Request-and-Reply flow walks up the tree from a consumer toward a publisher, which is kind of similar to how the IP multicast traceroute facility works [RFC8487] 👑
CCNinfo helps you trace a routing path and gives you three things: 1) the RTT between the content forwarder (aka the caching router or first-hop router) and the consumer, 2) the states of the in-network cache per name prefix, and 3) the routing path info per name prefix 🔥
It also checks the cache states, like the metrics for the Content Store (CS) in the content forwarder, which are:
- size of cached Content Objects,
- number of cached Content Objects,
- number of accesses (i.e., received Interests) per content, and
- elapsed cache time and remaining cache lifetime of content.
CCNinfo supports multipath forwarding 🌸 Request messages can get forwarded to multiple neighbor routers, and when they do, the different Reply messages come back from different routers or publishers 🧚
Plus, CCNinfo has policy-based information provisioning, so admins can "hide" secure or private info without messing up message forwarding 🎀 That makes it way easier for operators to install and run CCNinfo on their routers 🫶
Last thing, promise! This document represents the consensus of the Information-Centric Networking Research Group (ICNRG) 🌈 It was read and reviewed by active research group members. It is not an IETF product and it's not a standard 💅
1.1. CCNinfo as an Experimental Tool ✨
To run meaningful experiments with CCNx protocols, you need serious instrumentation and management info 📊 so you can measure things and see how the protocols and the apps riding on them perform and hold up 💪. CCNinfo's main job is to collect that info and report it back 🎀. As we learn more about CCNx and CCNinfo, we can sharpen the instrumentation, figure out what extra capabilities CCNinfo might need, and spot the features that aren't worth the implementation complexity and execution overhead they cost 🧹.
CCNinfo is meant to be a full-on experimental tool for CCNx-based networks 🧪. It gives you a ton of info from forwarders, including on-path in-network cache conditions and forwarding path instrumentation across multiple paths toward content forwarders 🛣️. Since it exposes detailed info about the forwarders a network operator deploys, CCNinfo uses more granular authorization policies than ICN ping or ICN traceroute 🔐.
CCNinfo has two message types: Request and Reply 💌. A CCNinfo user (say, a consumer) starts a CCNinfo Request when they want routing path and cache info 🙋♀️. When an adjacent neighbor router gets that Request, it checks its own cache. If the router doesn't have the specified content cached, it adds its Report block to the hop-by-hop header of the Request and forwards it to whichever upstream neighbor router(s) its FIB picks 🚀. In Figure 1, the CCNinfo user and Routers A, B, and C each add their own Report blocks to the Request and send it along 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 RoutersWhen the Request reaches the content forwarder, the content forwarder builds the Reply message 🎁. It adds its own Reply block TLV and Reply sub-block TLV(s) to the Request message. The Reply then travels back toward the user, hop by hop, along the Pending Interest Table (PIT) entries 🔁. In Figure 2, Routers C, B, and A each pass the Reply along their PIT entry, and the CCNinfo user finally gets a Reply from Router C, which is the first-hop router for the publisher 🎯. Another Reply from the caching router (that's Reply(C)) gets dropped at Router B if Router B already forwarded the other Reply (that's Reply(P)) 🗑️. Iconic behavior, honestly 💅.
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 User2. 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 read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly like this 🤓.
2.1. Definitions 🗂️
This document follows the basic terminology and definitions in [RFC8609] 💡. CCNinfo Requests travel the opposite way from the data flow, but we still talk about "upstream" and "downstream" with respect to data, unless it's explicitly stated otherwise 🔄.
- 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 take on 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 has the same definition as the ICN Consumer given in [RFC8793] 🛍️.
- Publisher: A node that creates Content Objects and makes them available for retrieval. It has the same definition as the ICN Producer given in [RFC8793] 📣.
- Router: A node that implements stateful forwarding on the path between consumer and publisher 🚦.
- Caching router: A node that temporarily stores, and may carry, Interests or Content Objects before forwarding them 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. It 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 the "ccninfo" command described in Appendix A or other similar commands, starts the Request message to get 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 be transmitted 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 ✨
okay so bestie, this is where the packets get their outfits 👗 CCNinfo Request and Reply messages are encoded in the CCNx TLV format (see [RFC8609] and Figure 3). A Request is a fixed header, then the Request block TLV (Figure 5), then Report block TLV(s) (Figure 7). A Reply is a fixed header, then Request block TLV, Report block TLV(s), Reply block TLV (Figure 9), and Reply sub-block TLV(s) (Figure 10). It's giving layers 🧅
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 that fixed header 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 then forwards it back toward the node that started the Request. Main character glow-up arc 🦋
+======+=======================+
| 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
After the fixed header, there can be a sequence of optional hop-by-hop header TLV(s) for a Request message. For a Request message, those are followed by a sequence of Report blocks, each one from a router on the path toward the publisher or caching router 🌸
At the start of the PacketPayload TLVs sits a top-level TLV type, T_DISCOVERY (Table 2), at the outermost level of a CCNx protocol message. It's the signal that Name segment TLV(s) and Reply block TLV(s) are coming up next 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 starts a discovery request (for example, with the ccninfo command described in Appendix A), a CCNinfo Request message gets created and forwarded to its upstream router through the Incoming face(s) decided by its FIB 🎀
The Request message format is in Figure 4. It's made of a fixed header, Request header block TLV (Figure 5), Report block TLV(s) (Figure 7), Name TLV, and Request block TLV. The Request header block TLV and Report block TLV(s) live in the hop-by-hop header, since those can change from hop to hop. The Request block TLV is encoded in the PacketPayload TLV by the content forwarder, as the protocol message itself. The PacketType value of the Request message is PT_CCNINFO_REQUEST (Table 1), and 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 goes down by one with each hop whenever a Request packet is forwarded. The CCNinfo user program sets it. The HopLimit value MUST be decremented by 1 prior to forwarding the Request packet. If HopLimit hits zero, the packet is discarded. HopLimit limits how far a Request can 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. The content forwarder replaces this value 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. Here's the full list of codes:
+=======+=================+================================+
| 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. Don't touch them, bestie 🙈
3.1.1. Request Header Block and Request Block ✨
okay so bestie, when a CCNinfo user sends the Request message, they MUST put their Request header block TLV (Figure 5) into the hop-by-hop header, and the Request block TLV (Figure 6) into the message, before sending it out 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 TypesType: 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 TypesType: 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 ✨
okay so the Name TLV (T_NAME) and the Name Segment TLVs are specced in [RFC8609], and CCNinfo just follows that bestie 💅 CCNinfo lets you name your content in two ways. You can use a prefix name with no chunk number, like ccnx:/news/today 🍓, or an exact name, like ccnx:/news/today/Chunk=10 🎀. With a prefix, you get the summary info for all the matching Content Objects in the content forwarder 🌈. With an exact name, you only get info about that one specific Content Object 🦋.
One big no-no 🙅♀️: a CCNinfo Request message MUST NOT be sent with only a scheme name, ccnx:/. Routers will reject it and throw it away 💀
3.2. Reply Message
okay this is the glow-up part 💖 when a content forwarder gets a CCNinfo Request from a legit adjacent neighbor router, it adds its own Reply block TLV and Reply sub-block TLV(s) to the Request. Then it turns the Request into a Reply by changing the Type field in the fixed header from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY. The Reply message (see Figure 8) then gets forwarded back toward the CCNinfo user hop by hop ✨
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 basically an envelope 🎁 that holds the Reply sub-block TLV(s), which we'll get into 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, which is shown in Table 6 in the current specification. 💅
Length: 16 bits This is the length of the Value field in octets. It's 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
okay this one is the juicy stuff 🧃 The router on the traced path adds one or more Reply sub-blocks, followed by the Reply block TLV, before it sends the Reply to its neighbor router. This section covers the Reply sub-block TLV, which reports various cache states and conditions, as shown in Figure 10. (Other Reply sub-block TLVs will be discussed in separate document(s).) 🔍
ngl some routers can't report every value. The ones that might be missing are Object Size, Object Count, # Received Interest, First Seqnum, Last Seqnum, Elapsed Cache Time, and Remain Cache Lifetime (all shown in Figure 10) 🙈. Some routers also just don't report these due to their policy. When that happens, the routers MUST set these fields to a value of all ones (i.e., 0xFFFFFFFF) 🌀 And if a value is equal to or bigger than the maximum size the 32-bit field can hold, that field MUST also be all-one. The CCNinfo user program MUST inform the user that these values are not valid whenever the fields come back as all ones 🚨
Also, if the cache gets refreshed after a reboot, every field in it MUST be refreshed (i.e., MUST be set to 0) 🔄 But if the cache survives the 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, as defined in the CCNx Reply Types (Table 7). T_DISC_CONTENT is used when a content forwarder replies with cache info. T_DISC_CONTENT_PUBLISHER is used when a FHR attached to a publisher replies with the original content info. 🧠
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 get truncated ✂️. The maximum size the 32-bit field can express is approximately 4.29 TB 💾
Object Count: 32 bits The number of unexpired Content Objects. The maximum count the 32-bit field can express is approximately 4.29 billion 🤯
# Received Interest: 32 bits The total number of received Interest messages that tried to retrieve the cached Content Objects 📬
First Seqnum: 32 bits The first sequential number of the unexpired Content Objects 1️⃣
Last Seqnum: 32 bits The last sequential number of the unexpired Content Objects. First Seqnum and Last Seqnum do not guarantee that the cached Content Objects are consecutive. Still, knowing these values can help when analyzing consecutive or discontinuous chunks, such as in [CONSEC-CACHING] 🧩
Elapsed Cache Time: 32 bits The elapsed time (seconds) since the oldest Content Object of the content was cached ⏳
Remain Cache Lifetime: 32 bits The lifetime (seconds) of a Content Object that was cached most recently ⌛
4. CCNinfo User Behavior ✨
4.1. Sending CCNinfo Request 📤
okay so a CCNinfo user runs a CCNinfo user program (like the ccninfo command 💅) that builds a CCNinfo Request message and sends it to their adjacent neighbor router(s) of interest. Then they get both the routing path info AND the in-network cache info back together in one single Reply 🫶 ngl that's so efficient.
When the CCNinfo user program starts a Request message, it MUST pop the necessary values in, i.e., the Request ID and the Node Identifier, into the Request block 🎀 The Request ID MUST be unique for that CCNinfo user until they get the matching Reply message(s) or the Request times out ⏰
Some policies mean a router might wanna validate CCNinfo Requests using the CCNx ValidationPayload TLV (whether it accepts the Request or not), especially when it gets the "full discovery request" (see Section 5.3.2) 🔍 So the CCNinfo user program MAY require validating the Request message and attaching the user's signature into the CCNx ValidationPayload TLV ✍️ The router then forwards the Request message. If the router doesn't approve the Request, it rejects the Request message as described in Section 6.11 🙅♀️
After the CCNinfo user program sends the Request message, it MUST keep track of this info until the Reply times out, or the expected number of Replies comes in, or a Reply message with a non-zero ReturnCode in the fixed header shows up 📝 That info is: HopLimit (from the fixed header), Request ID and Flags (from the Request header block), and Node Identifier and Request Arrival Time (from the Request block). Main character bookkeeping 💜
4.1.1. Routing Path Information 🛣️
A CCNinfo user can send a CCNinfo Request to investigate the routing path information for a specified named content 🗺️ With it, a legit user can get 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 ends once it reaches the content forwarder 🏁
4.1.2. In-Network Cache Information 🗄️
A CCNinfo user can also send a CCNinfo Request to investigate in-network cache information 👀 With it, a legit user can get 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 the Content Store (CS) in the content forwarder 🧁 unless the content forwarder is able to report them itself (see Section 3.2.1.1). This CCNinfo Request ends once it reaches the content forwarder too 🏁
4.2. Receiving CCNinfo Reply 📥
The CCNinfo user program will get one or multiple CCNinfo Reply messages from the adjacent neighbor router(s) 📬 When the program gets a Reply, it MUST compare the saved Request ID and Node Identifier values to match the Request and Reply pair 💕 If they don't 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 (the one that was put into the original Request), the Reply MUST be silently ignored 🙈
Once the CCNinfo user has figured out that they've traced the whole path, or the max path they could reasonably expect, they might collect statistics by just waiting for a timeout ⏳ The useful stats CCNinfo gives you are covered in Section 8 📊
5. Router Behavior ✨
5.1. User and Neighbor Verification 🕵️♀️
When a router gets a CCNinfo Request message, it MAY check whether a valid CCNinfo user sent it 🪪 If the router notices that the Request sender's signature in the Request is invalid, it SHOULD terminate the Request, as defined in Section 6.4 🚫
When a router gets a CCNinfo Request or Reply message, it MAY check whether the message comes from a valid adjacent neighbor node 🤝 If the router notices 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 does the following steps 📝
- The value of
HopLimitin the fixed header and the value ofSkipHop (Skip Hop Count)in the Request block are counters that go down by one with each hop ⬇️ If theHopLimitvalue is zero, the router terminates the Request, as defined in Section 6.5 💀 If theSkipHopvalue is equal to or more than theHopLimitvalue, the router terminates the Request, as defined in Section 6.4 🛑 Otherwise, until theSkipHopvalue hits 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 doesn't know the upstream router(s) for the specified name prefix, it terminates the Request, as defined in Section 6.5 🙃 It should be noted that Request messages get terminated at the FHR 🧱 So even though the maximum value forHopLimitis255and forSkipHopis15, if the Request messages reach the FHR before theHopLimitorSkipHopvalue becomes0, the FHR silently discards the Request message and the Request times out 🥲 - The router checks the
Flagsfield (specified in Table 5) in the Request block of the received CCNinfo Request 🔎 If theCflag is not set, it's categorized as the "routing path information discovery" 🛣️ If theCflag is set, it's the "cache information discovery" 🗄️ If theOflag is set, it's the "publisher discovery" 📢 - If the Request is either "cache information discovery" or "routing path information discovery", the router checks its FIB and CS 👀 If the router has the specified content cached, it sends the Reply message with its own Reply block and sub-block(s) 🎁 If the router can't insert its own Reply block or sub-block(s) because there's no space, it terminates the Request, as specified in Section 6.7 😭 If the router doesn't cache the specified content but knows the upstream neighbor router(s) for the specified name prefix, it creates the PIT entry, puts its own Report block in the hop-by-hop header, and forwards the Request to the upstream neighbor(s) 🚀 If the router can't insert its own Report block because there's no space, or if it doesn't cache the specified content AND doesn't know the upstream neighbor router(s) for the specified name prefix, it terminates the Request, as defined in Section 6.5 💔
- If the Request is the "publisher discovery", the router checks whether it's the FHR for the requested content 🧐 If it is the FHR, it sends the Reply message with its own Report block and sub-blocks (for cache information discovery), or the Reply message with its own Report block and no Reply sub-blocks (for routing path information discovery) 🎉 If the router isn't 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 can't insert its own Report block in the hop-by-hop header because there's no space, it terminates the Request, as specified in Section 6.7 🫠 If the router isn't the FHR AND doesn't know the upstream neighbor router(s) for the specified name prefix, it terminates the Request, as defined in Section 6.5 🥀 Also, in Cefore [Cefore-site], there's an API where a publisher tells the FHR the application prefix, and the FHR registers it into the FIB 🗂️ That prefix entry can then 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 sets 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, just 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 use path labels (specified in Section 1) at the corresponding PIT entry 🏷️ The router can check the PIT entry later to forward the Reply message(s) back the right way 🔁
CCNinfo supports multipath forwarding 🛤️🛤️ The Request messages can be forwarded to multiple neighbor routers 🧩 Some routers have a strategy for multipath forwarding, and when a router sends Interest messages to multiple neighbor routers, it may delay or prioritize sending the message to the upstream routers ⚖️ By default, the CCNinfo Request complies with such strategies, so a CCNinfo user can trace the actual forwarding path based on the forwarding strategy and will get a single Reply message, such as a Content Object 🎀💅
5.3.2. Full Discovery Request 🕵️♀️
Okay so sometimes a CCNinfo user wants to find every possible forwarding path and content forwarder based on the routers' FIBs. That's full detective mode 🔍✨ The "full discovery request" is the feature that makes it happen. If a CCNinfo user sets the F flag in the Request block of the Request message (as seen in Table 5) to ask for 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 at the end the CCNinfo user gets 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 stick around until the configured CCNinfo Reply Timeout (Section 7.1) expires. This is the twist! Unlike the ordinary Interest-Data exchanges in CCN, if routers that accept the full discovery request receive it, those 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, so it may not be implemented on routers at all. Even if a router does implement it, that router may not accept the full discovery request from non-validated CCNinfo users or routers, or it may refuse 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 💌
Here's the happy path! If there is a caching router or FHR for the specified content within the specified hop count along the path, that caching router or FHR sends the Reply message back toward the CCNinfo user and terminates the Request 🎉
When a router decides to send a Reply message to its downstream neighbor router or to the CCNinfo user with a NO_ERROR return code, it inserts a Report block with the Request Arrival Time and Node Identifier values into the Request message. Then the router inserts the corresponding Reply sub-block(s) (Figure 10) into the payload. Finally, the router 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 🦋
What if the router can't keep going? 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, and the Reply comes from a valid adjacent neighbor router, the router forwards the CCNinfo Reply back toward the CCNinfo user. If the router does not receive the corresponding Reply within the [CCNinfo Reply Timeout] period, it removes the corresponding PIT entry and terminates the trace ⏰
The Flags field in the Request block TLV is what decides whether the router keeps the PIT entry during the CCNinfo Reply Timeout, even after one or more corresponding Reply messages have been 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 chose 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 🛤️
Multipath is giving chaos energy 🌈 Within a network with a multipath condition, there is a case (Figure 12) where a single CCNinfo Request is split into multiple Requests (e.g., at Router A), and those get 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 that 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 by 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 a 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 the value 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 reach Router A, but the CCNinfo user can only receive the first Reply message, either from Router B or from Router C, because Router A removes the corresponding PIT entry after it forwards the first Reply 🏃♀️💨
To avoid routing loops, when a router looks at the cumulate node identifiers of the Report blocks in the hop-by-hop header, it MUST examine whether its own node identifier has not previously been 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 🚦
Let's talk about when to stop the trace! When performing a hop-by-hop trace, it's necessary to determine when to stop. There are several cases where 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 make sure 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 though 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 a 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, the CCNinfo user and the 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 💅
okay so the CCNinfo Reply Timeout is the timer that decides when a CCNinfo Reply has taken too long and gets timed out 🫶⏰. the router's admins and/or operators can set it statically, and the default is 3 (seconds) ✨. it SHOULD NOT be larger than 4 (seconds) and SHOULD NOT be lower than 2 (seconds) 🎀. bestie, keep it in that sweet spot!
7.2. HopLimit in Fixed Header 🦋
so if a CCNinfo user doesn't set the HopLimit in the fixed header for a Request message, it defaults to 32 🌸. and periodt, a 0 HopLimit is an invalid Request 💀, so the router handles that one the way Section 6.4 says 🙈.
7.3. Access Control 🔐
a router MAY configure the valid or invalid networks to set up an access control 🧚. this access control MAY be defined per name prefix, like "who can retrieve which name prefix" (see Section 10.2) 💜. main character energy for network policy, honestly 👑.
8. Diagnosis and Analysis 🔍
8.1. Number of Hops and RTT 🌈
so a CCNinfo Request message gets forwarded hop-by-hop, and every forwarding router tacks on its own Report block 🧩. that means we can verify how many hops it takes to reach the content forwarder or publisher, plus the RTT between them ✨. literally a little breadcrumb trail 🍓.
8.2. Caching Router Identification 🕵️♀️
some routers hide their node identifiers with all-zeros in the Report blocks (as seen in Section 10.1) 🙈. even so, the routers on the path from the CCNinfo user to the content forwarder can still be identified 💖.
8.3. TTL or Hop Limit ⏳
by taking the HopLimit from the content forwarder and forwarding the TTL threshold over all hops, you can figure out the TTL or hop limit the content forwarder needs to reach the CCNinfo user 🎯. not gonna lie, that's kinda genius 🧠.
8.4. Time Delay ⏱️
if the routers have synchronized clocks, you can estimate the propagation and queuing delays from the differences between timestamps at successive hops 🫧. BUT ngl, this delay includes control processing overhead, so it's not necessarily what data traffic would actually experience 😭. so don't take it as gospel 💅.
8.5. Path Stretch 📏
by getting 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 improvements in path stretch across different cases 🦄. like different caching and routing algorithms 🌷. this helps us investigate how the protocol performs 👑.
8.6. Cache Hit Probability 🎯
CCNinfo can show the number of received Interests per cache or chunk on a router 📊. so it measures content popularity (the number of accesses for each content and/or cache) 🔥. that lets us investigate the routing/caching strategy in networks, iykyk 🫶.
9. IANA Considerations 📋
this section details each kind of CCNx protocol value that's been registered 🗂️. per [RFC8126], four assignments were made in existing registries, and a new Reply Type registry was 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, with values 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, with values 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, with values 0x000D and 0x000E respectively 🎀.
9.5. Reply Type Registry 🧾
IANA created the "CCNx Reply Types" registry and allocated the reply types 🎉. the registration procedure is "RFC Required" [RFC8126] 🔐. the Type value is 2 octets, and 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, with values 0x0000, 0x0001, and 0x0FFF respectively 👑.
10. Security Considerations 🛡️
this section covers some of the security considerations, and bestie, they are SERIOUS 😭🔥.
10.1. Policy-Based Information Provisioning for Request 🙅♀️
CCNinfo gives excellent troubleshooting cues, but some network admins or operators may not want to disclose everything about their network to the public 🙈. others may want to securely send private info to specific members of their networks 🔒. so CCNinfo provides policy-based information provisioning, letting network admins set a response policy for each router 💅.
the access policy for "who is allowed to retrieve" and/or "what kind of cache information" can be defined for each router 🧱. for the first type, routers with the specified content MAY examine the signature enclosed in the Request message and decide whether to notify the content information in the Reply 🔍. if they decide not to notify it, they MUST send the CCNinfo Reply with the ReturnCode of ADMIN_PROHIB, without appending any Reply block or sub-block TLVs 🚫. for the second type, the permission is one of three options: (1) All, where all cache information is disclosed; (2) Partial, where cache information with a particular name prefix can (or cannot) be disclosed; or (3) Deny, where no cache information is disclosed 💜.
⚠️ the vibe check: we entail that each router does NOT disrupt the forwarding of CCNinfo Request and Reply messages 💀.
so when a Request message comes in, the router SHOULD insert the Report block if the ReturnCode is NO_ERROR 🧩. depending on the policy config, the Node Identifier field in the Report block MAY be null (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 stays 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 🕶️. invalid networks (or domains) could be configured as a list of allowed or disallowed networks (as noted in Section 7.3) 📝. if a Request comes 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 isn't 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 that info 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 on content forwarders, because it makes them seek their internal cache states reported in the Reply messages whenever they form those Replies 🥵. the current CCNinfo spec allows null values for several fields, such as First/Last Seqnum or Elapsed Cache Time in the Reply sub-block 🫥. as mentioned in Section 3.2.1.1, these values MAY be null ✨. this means the content forwarder can not only hide these values for privacy and security reasons, but also skip implementing the complex functions needed to report them 🧠.
10.6. Longer or Shorter CCNinfo Reply Timeout ⏳
routers can configure the CCNinfo Reply Timeout (Section 7.1), which is the allowable timeout value for keeping a PIT entry 🗂️. if routers configure a longer timeout, there may be an attractive attack vector against PIT memory 😱. especially when the full discovery request option (Section 5.3) is specified for the CCNinfo Request, several Reply messages may come back and cause a response storm 🌪️. (see Section 10.8 for rate-limiting to avoid the storm). to avoid DoS attacks, routers MAY configure a timeout value that is shorter than the user-configured CCNinfo timeout value 🛡️. however, if it's too short, the Request may time out and the CCNinfo user won't receive all Replies, so they only get partial path information (i.e., information about part of the tree) 🌳.
there may be a way to enable incremental exploration (i.e., exploring the part of the tree that the previous operation didn't explore) 🔎. however, discussing such mechanisms is out of scope for 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 received messages to minimize processing overhead, i.e., to keep request processing fair or to prevent traffic amplification ⚖️. in that 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 on the traced path MAY need to rate-limit the Replies 🚥. in that case, no error message is returned 🤫. the rate limit function is left to the router's implementation 🛠️.
10.9. Adjacency Verification 🤝
it's assumed that CCNinfo Request and Reply messages are forwarded by adjacent neighbor nodes or routers 👯♀️. the CCNx message format or semantics don't define a secure way to verify node and/or router adjacency 😬, but a hop-by-hop authentication such as [DCAuth] provides a possible method for adjacency verification, and it defines the corresponding message format and router behaviors as well 🔐. 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, <https://www.rfc-editor.org/info/rfc2119>.
- [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, <https://www.rfc-editor.org/info/rfc8126>.
- [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
- [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, July 2019, <https://www.rfc-editor.org/info/rfc8569>.
- [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Messages in TLV Format", RFC 8609, DOI 10.17487/RFC8609, July 2019, <https://www.rfc-editor.org/info/rfc8609>.
11.2. Informative References
These are the extra reads, bestie, the ones that aren't strictly required but give you the whole backstory 🌸📚
[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,https://doi.org/10.1587/transcom.2018EII0001. 💜[Cefore-site]: "Cefore",https://cefore.net/. 🌐[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,https://doi.org/10.1109/ICC.2018.8422233. 🧠[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,https://doi.org/10.1109/MCOM.2015.7060502. 🔍[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,https://doi.org/10.1109/TNSE.2018.2872049. 🔐[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,https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-icnping-07. 🏓[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,https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-icntraceroute-07. 🗺️[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,https://www.rfc-editor.org/info/rfc8487. ✨[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,https://www.rfc-editor.org/info/rfc8793. 📖
Appendix A. ccninfo Command and Options 💅
Okay so CCNinfo is implemented in Cefore [Cefore] [Cefore-site], and the command your CCNinfo user (say, a consumer) actually types is called ccninfo. 🎀 It sends the Request message and collects the Reply message(s). It has a bunch of options, but the content name prefix (like ccnx:/news/today) is the one thing you can't skip. It's the mandatory parameter, bestie. 🫶
The usage looks like this:
ccninfo [-c] [-f] [-o] [-V] [-r hop_count] [-s hop_count]
[-v algorithm] name_prefixname_prefix is the prefix name of the content (for example ccnx:/news/today) or the exact name of the content (for example ccnx:/news/today/Chunk=10) that the CCNinfo user wants to trace. 🔍
The -c option is for when the CCNinfo user wants the cache information, the routing path information for that content or cache, and the RTT between the CCNinfo user and the content forwarder. Main character energy 👑
The -f option turns on the "full discovery request". Routers send CCNinfo Requests to multiple upstream faces based on their FIBs all at once, so the CCNinfo user can trace every possible forwarding path. It's giving thorough 🧚
The -o option turns on tracing of the path to the content publisher. Each router along that path inserts its Report block and forwards the Request message. It does not send Reply even if it caches the specified content 🙈 The FHR that attaches the publisher (the one holding the complete set of content, which isn't a caching router) is the one that sends the Reply message. 🦋
The -V option asks the Reply sender to validate the Reply message with its own signature. The Reply message then includes the CCNx ValidationPayload TLV, and the validation algorithm is picked by the Reply sender. Iykyk 🔐
The -r hop_count option sets the number of traced routers. This value goes in the "HopLimit" field in the fixed header of the Request. So if the CCNinfo user runs ccninfo with -r 3, only three routers along the path examine their path and cache information. Tiny but mighty 💖
The -s hop_count option sets the number of skipped routers. This value goes in the "SkipHop" field of the Request block TLV. For example, with -s 3, three upstream routers along the path only forward the Request message. They don't append their Report blocks in the hop-by-hop header, and they don't send Reply messages even if they have the corresponding cache. Not me skipping routers and still being chill about it 🙃
The -v algorithm option lets the CCNinfo user validate the Request message with their signature. The Request message then includes the CCNx ValidationPayload TLV, and 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. 🫶💜 Such a squad.
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.jpAtsushi Ooka 🦋
National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi, Koganei, Tokyo
184-8795
Japan
Email: a-ooka@nict.go.jpXun Shao 🎀
Toyohashi University of Technology
1-1 Hibarigaoka Tempaku-cho, Toyohashi, Aichi
441-8580
Japan
Email: shao.xun.ls@tut.jpAnd that's a wrap on RFC 9344, bestie! 🌈✨💅
📦 where this page comes from
- ietf: rfc9344 2023-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms