CCNinfo: Discovering Content and Network Information in Content-Centric Networks

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 s/he wants to obtain routing path and cache information. When an adjacent neighbor router receives the Request message, it examines 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 (Router 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 |
                                          +---------+

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 PIT entries. In Figure 2, each router (Router 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 |
                                          +---------+

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 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 s/he has traced the whole path or the maximum path that s/he can be expected to, s/he might collect statistics by waiting for a timeout. Useful statistics provided by CCNinfo are stated in Section 8.¶

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 that 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 Figure 9) 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, and 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, and 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 [14], 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

       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 |
                                          +---------+

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 NO_ERROR return code, it inserts a Report block with the Request Arrival Time and Node Identifier to the Request message. Then, the router inserts the corresponding Reply sub-block(s) (Figure 15) 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).¶

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.7. No Space

If appending the Report block or the 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., %x85) in the fixed header and forward the message back to the CCNinfo user.¶

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.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/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.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.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.¶

9.1. Packet Type Registry

As shown in Figure 4, CCNinfo defines two packet types, PT_CCNINFO_REQUEST and PT_CCNINFO_REPLY, whose suggested values are %x03 and %x04, respectively.¶

9.2. Top-Level Type Registry

As shown in Figure 5, CCNinfo defines one top-level type, T_DISCOVERY, whose suggested value is %x0005.¶

9.3. Hop-by-Hop Type Registry

As shown in Figure 8, CCNinfo defines two hop-by-hop types, T_DISC_REQHDR and T_DISC_REPORT, whose suggested values are %x0008 and %x0009, respectively.¶

9.4. Message Type Registry

As shown in Figure 11, CCNinfo defines two message types, T_DISC_REQ and T_DISC_REPLY, whose suggested values are %x0007 and %x0008, respectively.¶

9.5. Reply Type Registry

IANA has created the "CCNx Reply Types" registry and allocated the reply types. The Type value is 2 octets. The range is %x0000-%xFFFF. As shown in Figure 16, CCNinfo defines three reply types, T_DISC_CONTENT, T_DISC_CONTENT_PUBLISHER, and T_ORG, whose suggested values are %x0000, %x0001, and %x0FFF, respectively.¶

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 (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/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.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 can not only hide these values owing to privacy/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; s/he only retrieves 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 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/router adjacency, while HopAuth [11] 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.¶