| < draft-irtf-icnrg-ccninfo-09.txt | draft-irtf-icnrg-ccninfo-10.txt > | |||
|---|---|---|---|---|
| ICN Research Group H. Asaeda | ICN Research Group H. Asaeda | |||
| Internet-Draft A. Ooka | Internet-Draft A. Ooka | |||
| Intended status: Experimental NICT | Intended status: Experimental NICT | |||
| Expires: August 14, 2022 X. Shao | Expires: October 27, 2022 X. Shao | |||
| Kitami Institute of Technology | Kitami Institute of Technology | |||
| February 10, 2022 | April 25, 2022 | |||
| CCNinfo: Discovering Content and Network Information in Content-Centric | CCNinfo: Discovering Content and Network Information in Content-Centric | |||
| Networks | Networks | |||
| draft-irtf-icnrg-ccninfo-09 | draft-irtf-icnrg-ccninfo-10 | |||
| Abstract | Abstract | |||
| This document describes a mechanism named "CCNinfo" that discovers | This document describes a mechanism named "CCNinfo" that discovers | |||
| information about the network topology and in-network cache in | information about the network topology and in-network cache in | |||
| Content-Centric Networks (CCN). CCNinfo investigates: 1) the CCN | Content-Centric Networks (CCN). CCNinfo investigates: 1) the CCN | |||
| routing path information per name prefix, 2) the Round-Trip Time | routing path information per name prefix, 2) the Round-Trip Time | |||
| (RTT) between the content forwarder and consumer, and 3) the states | (RTT) between the content forwarder and consumer, and 3) the states | |||
| of in-network cache per name prefix. CCNinfo is useful to understand | of in-network cache per name prefix. CCNinfo is useful to understand | |||
| and debug the behavior of testbed networks and other experimental | and debug the behavior of testbed networks and other experimental | |||
| skipping to change at page 1, line 48 ¶ | skipping to change at page 1, line 48 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on August 14, 2022. | This Internet-Draft will expire on October 27, 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.1. CCNinfo as an Experimental Tool . . . . . . . . . . . . . 6 | 1.1. CCNinfo as an Experimental Tool . . . . . . . . . . . . . 5 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 3. CCNinfo Message Formats . . . . . . . . . . . . . . . . . . . 8 | 3. CCNinfo Message Formats . . . . . . . . . . . . . . . . . . . 9 | |||
| 3.1. Request Message . . . . . . . . . . . . . . . . . . . . . 9 | 3.1. Request Message . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 3.1.1. Request Header Block and Request Block . . . . . . . 11 | 3.1.1. Request Header Block and Request Block . . . . . . . 12 | |||
| 3.1.2. Report Block TLV . . . . . . . . . . . . . . . . . . 15 | 3.1.2. Report Block TLV . . . . . . . . . . . . . . . . . . 16 | |||
| 3.1.3. Content Name Specification . . . . . . . . . . . . . 16 | 3.1.3. Content Name Specification . . . . . . . . . . . . . 17 | |||
| 3.2. Reply Message . . . . . . . . . . . . . . . . . . . . . . 16 | 3.2. Reply Message . . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 3.2.1. Reply Block TLV . . . . . . . . . . . . . . . . . . . 17 | 3.2.1. Reply Block TLV . . . . . . . . . . . . . . . . . . . 18 | |||
| 3.2.1.1. Reply Sub-Block TLV . . . . . . . . . . . . . . . 18 | 3.2.1.1. Reply Sub-Block TLV . . . . . . . . . . . . . . . 19 | |||
| 4. CCNinfo User Behavior . . . . . . . . . . . . . . . . . . . . 21 | 4. CCNinfo User Behavior . . . . . . . . . . . . . . . . . . . . 22 | |||
| 4.1. Sending CCNinfo Request . . . . . . . . . . . . . . . . . 21 | 4.1. Sending CCNinfo Request . . . . . . . . . . . . . . . . . 22 | |||
| 4.1.1. Routing Path Information . . . . . . . . . . . . . . 21 | 4.1.1. Routing Path Information . . . . . . . . . . . . . . 22 | |||
| 4.1.2. In-Network Cache Information . . . . . . . . . . . . 21 | 4.1.2. In-Network Cache Information . . . . . . . . . . . . 22 | |||
| 4.2. Receiving CCNinfo Reply . . . . . . . . . . . . . . . . . 22 | 4.2. Receiving CCNinfo Reply . . . . . . . . . . . . . . . . . 23 | |||
| 5. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 22 | 5. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
| 5.1. User and Neighbor Verification . . . . . . . . . . . . . 22 | 5.1. User and Neighbor Verification . . . . . . . . . . . . . 23 | |||
| 5.2. Receiving CCNinfo Request . . . . . . . . . . . . . . . . 22 | 5.2. Receiving CCNinfo Request . . . . . . . . . . . . . . . . 23 | |||
| 5.3. Forwarding CCNinfo Request . . . . . . . . . . . . . . . 24 | 5.3. Forwarding CCNinfo Request . . . . . . . . . . . . . . . 25 | |||
| 5.3.1. Regular Request . . . . . . . . . . . . . . . . . . . 24 | 5.3.1. Regular Request . . . . . . . . . . . . . . . . . . . 25 | |||
| 5.3.2. Full Discovery Request . . . . . . . . . . . . . . . 24 | 5.3.2. Full Discovery Request . . . . . . . . . . . . . . . 25 | |||
| 5.4. Sending CCNinfo Reply . . . . . . . . . . . . . . . . . . 25 | 5.4. Sending CCNinfo Reply . . . . . . . . . . . . . . . . . . 26 | |||
| 5.5. Forwarding CCNinfo Reply . . . . . . . . . . . . . . . . 26 | 5.5. Forwarding CCNinfo Reply . . . . . . . . . . . . . . . . 27 | |||
| 5.6. PIT Entry Management for Multipath Support . . . . . . . 26 | 5.6. PIT Entry Management for Multipath Support . . . . . . . 27 | |||
| 6. CCNinfo Termination . . . . . . . . . . . . . . . . . . . . . 28 | 6. CCNinfo Termination . . . . . . . . . . . . . . . . . . . . . 29 | |||
| 6.1. Arriving at First-hop Router . . . . . . . . . . . . . . 28 | 6.1. Arriving at First-hop Router . . . . . . . . . . . . . . 29 | |||
| 6.2. Arriving at Router Having Cache . . . . . . . . . . . . . 28 | 6.2. Arriving at Router Having Cache . . . . . . . . . . . . . 29 | |||
| 6.3. Arriving at Last Router . . . . . . . . . . . . . . . . . 28 | 6.3. Arriving at Last Router . . . . . . . . . . . . . . . . . 29 | |||
| 6.4. Invalid Request . . . . . . . . . . . . . . . . . . . . . 28 | 6.4. Invalid Request . . . . . . . . . . . . . . . . . . . . . 29 | |||
| 6.5. No Route . . . . . . . . . . . . . . . . . . . . . . . . 28 | 6.5. No Route . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
| 6.6. No Information . . . . . . . . . . . . . . . . . . . . . 28 | 6.6. No Information . . . . . . . . . . . . . . . . . . . . . 30 | |||
| 6.7. No Space . . . . . . . . . . . . . . . . . . . . . . . . 29 | 6.7. No Space . . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
| 6.8. Fatal Error . . . . . . . . . . . . . . . . . . . . . . . 29 | 6.8. Fatal Error . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
| 6.9. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 29 | 6.9. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 30 | |||
| 6.10. Non-Supported Node . . . . . . . . . . . . . . . . . . . 29 | 6.10. Non-Supported Node . . . . . . . . . . . . . . . . . . . 30 | |||
| 6.11. Administratively Prohibited . . . . . . . . . . . . . . . 29 | 6.11. Administratively Prohibited . . . . . . . . . . . . . . . 30 | |||
| 7. Configurations . . . . . . . . . . . . . . . . . . . . . . . 29 | 7. Configurations . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
| 7.1. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 30 | 7.1. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 31 | |||
| 7.2. HopLimit in Fixed Header . . . . . . . . . . . . . . . . 30 | 7.2. HopLimit in Fixed Header . . . . . . . . . . . . . . . . 31 | |||
| 7.3. Access Control . . . . . . . . . . . . . . . . . . . . . 30 | 7.3. Access Control . . . . . . . . . . . . . . . . . . . . . 31 | |||
| 8. Diagnosis and Analysis . . . . . . . . . . . . . . . . . . . 30 | 8. Diagnosis and Analysis . . . . . . . . . . . . . . . . . . . 31 | |||
| 8.1. Number of Hops and RTT . . . . . . . . . . . . . . . . . 30 | 8.1. Number of Hops and RTT . . . . . . . . . . . . . . . . . 31 | |||
| 8.2. Caching Router Identification . . . . . . . . . . . . . . 30 | 8.2. Caching Router Identification . . . . . . . . . . . . . . 31 | |||
| 8.3. TTL or Hop Limit . . . . . . . . . . . . . . . . . . . . 30 | 8.3. TTL or Hop Limit . . . . . . . . . . . . . . . . . . . . 31 | |||
| 8.4. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 30 | 8.4. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
| 8.5. Path Stretch . . . . . . . . . . . . . . . . . . . . . . 31 | 8.5. Path Stretch . . . . . . . . . . . . . . . . . . . . . . 32 | |||
| 8.6. Cache Hit Probability . . . . . . . . . . . . . . . . . . 31 | 8.6. Cache Hit Probability . . . . . . . . . . . . . . . . . . 32 | |||
| 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 | |||
| 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 | |||
| 10.1. Policy-Based Information Provisioning for Request . . . 31 | 10.1. Policy-Based Information Provisioning for Request . . . 32 | |||
| 10.2. Filtering CCNinfo Users Located in Invalid Networks . . 32 | 10.2. Filtering CCNinfo Users Located in Invalid Networks . . 33 | |||
| 10.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 32 | 10.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 33 | |||
| 10.4. Characteristics of Content . . . . . . . . . . . . . . . 32 | 10.4. Characteristics of Content . . . . . . . . . . . . . . . 33 | |||
| 10.5. Computational Attacks . . . . . . . . . . . . . . . . . 32 | 10.5. Computational Attacks . . . . . . . . . . . . . . . . . 34 | |||
| 10.6. Longer or Shorter CCNinfo Reply Timeout . . . . . . . . 33 | 10.6. Longer or Shorter CCNinfo Reply Timeout . . . . . . . . 34 | |||
| 10.7. Limiting Request Rates . . . . . . . . . . . . . . . . . 33 | 10.7. Limiting Request Rates . . . . . . . . . . . . . . . . . 34 | |||
| 10.8. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 33 | 10.8. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 34 | |||
| 10.9. Adjacency Verification . . . . . . . . . . . . . . . . . 33 | 10.9. Adjacency Verification . . . . . . . . . . . . . . . . . 35 | |||
| 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 | 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 | |||
| 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
| 12.1. Normative References . . . . . . . . . . . . . . . . . . 34 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 35 | |||
| 12.2. Informative References . . . . . . . . . . . . . . . . . 34 | 12.2. Informative References . . . . . . . . . . . . . . . . . 35 | |||
| Appendix A. ccninfo Command and Options . . . . . . . . . . . . 35 | Appendix A. ccninfo Command and Options . . . . . . . . . . . . 36 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 | |||
| 1. Introduction | 1. Introduction | |||
| In Content-Centric Networks (CCN), publishers provide the content | In Content-Centric Networks (CCN), publishers provide the content | |||
| through the network, and receivers retrieve it by name. In this | through the network, and receivers retrieve it by name. In this | |||
| network architecture, routers forward content requests through their | network architecture, routers forward content requests through their | |||
| Forwarding Information Bases (FIBs), which are populated by name- | Forwarding Information Bases (FIBs), which are populated by name- | |||
| based routing protocols. CCN also enables receivers to retrieve | based routing protocols. CCN also enables receivers to retrieve | |||
| content from an in-network cache. | content from an in-network cache. | |||
| skipping to change at page 4, line 15 ¶ | skipping to change at page 4, line 15 ¶ | |||
| investigating the network conditions. | investigating the network conditions. | |||
| IP traceroute is a useful tool for discovering the routing conditions | IP traceroute is a useful tool for discovering the routing conditions | |||
| in IP networks because it provides intermediate router addresses | in IP networks because it provides intermediate router addresses | |||
| along the path between the source and destination and the Round-Trip | along the path between the source and destination and the Round-Trip | |||
| Time (RTT) for the path. However, this IP-based network tool cannot | Time (RTT) for the path. However, this IP-based network tool cannot | |||
| trace the name prefix paths used in CCN. Moreover, such IP-based | trace the name prefix paths used in CCN. Moreover, such IP-based | |||
| network tools do not obtain the states of the in-network cache to be | network tools do not obtain the states of the in-network cache to be | |||
| discovered. | discovered. | |||
| Contrace [6] enables end users (i.e., consumers) to investigate path | Contrace [7] enables end users (i.e., consumers) to investigate path | |||
| and in-network cache conditions in CCN. Contrace is implemented as | and in-network cache conditions in CCN. Contrace is implemented as | |||
| an external daemon process running over TCP/IP that can interact with | an external daemon process running over TCP/IP that can interact with | |||
| a previous CCNx forwarding daemon (CCNx-0.8.2) to retrieve the | a previous CCNx forwarding daemon (CCNx-0.8.2) to retrieve the | |||
| caching information on the forwarding daemon. This solution is | caching information on the forwarding daemon. This solution is | |||
| flexible, but it requires TCP/IP networks and defining the common | flexible, but it requires TCP/IP networks and defining the common | |||
| APIs for the global deployment. ICN ping [7] and traceroute [8] are | APIs for the global deployment. ICN ping [8] and traceroute [9] are | |||
| lightweight operational tools that enable a user to explore the | lightweight operational tools that enable a user to explore the | |||
| path(s) that reach a publisher or a cache storing the named content. | path(s) that reach a publisher or a cache storing the named content. | |||
| ICN ping and traceroute, however, do not exposes detailed information | ICN ping and traceroute, however, do not exposes detailed information | |||
| about the forwarders deployed by a network operator. | about the forwarders deployed by a network operator. | |||
| This document describes the specifications of "CCNinfo", an active | This document describes the specifications of "CCNinfo", an active | |||
| networking tool for discovering the path and content caching | networking tool for discovering the path and content caching | |||
| information in CCN. CCNinfo defines the protocol messages to | information in CCN. CCNinfo defines the protocol messages to | |||
| investigate path and in-network cache conditions in CCN. It is | investigate path and in-network cache conditions in CCN. It is | |||
| embedded in the CCNx forwarding process and can facilitate with non- | embedded in the CCNx forwarding process and can facilitate with non- | |||
| IP networks as with the basic CCN concept. | IP networks as with the basic CCN concept. | |||
| The two message types, Request and Reply messages, are encoded in the | The two message types, Request and Reply messages, are encoded in the | |||
| CCNx TLV format [1]. The request-reply message flow, walking up the | CCNx TLV format [1]. The request-reply message flow, walking up the | |||
| tree from a consumer toward a publisher, is similar to the behavior | tree from a consumer toward a publisher, is similar to the behavior | |||
| of the IP multicast traceroute facility [9]. | of the IP multicast traceroute facility [10]. | |||
| CCNinfo facilitates the tracing of a routing path and provides: 1) | CCNinfo facilitates the tracing of a routing path and provides: 1) | |||
| the RTT between the content forwarder (i.e., the caching or first-hop | the RTT between the content forwarder (i.e., caching router or first- | |||
| router) and consumer, 2) the states of the in-network cache per name | hop router) and consumer, 2) the states of the in-network cache per | |||
| prefix, and 3) the routing path information per name prefix. | name prefix, and 3) the routing path information per name prefix. | |||
| In addition, CCNinfo identifies the states of the cache, such as the | In addition, CCNinfo identifies the states of the cache, such as the | |||
| following metrics for Content Store (CS) in the content forwarder: 1) | following metrics for Content Store (CS) in the content forwarder: 1) | |||
| size of cached content objects, 2) number of cached content objects, | size of cached content objects, 2) number of cached content objects, | |||
| 3) number of accesses (i.e., received Interests) per content, and 4) | 3) number of accesses (i.e., received Interests) per content, and 4) | |||
| elapsed cache time and remaining cache lifetime of content. | elapsed cache time and remaining cache lifetime of content. | |||
| CCNinfo supports multipath forwarding. The Request messages can be | ||||
| forwarded to multiple neighbor routers. When the Request messages | ||||
| are forwarded to multiple routers, the different Reply messages are | ||||
| forwarded from different routers or publishers. | ||||
| Furthermore, CCNinfo implements policy-based information provisioning | ||||
| that enables administrators to "hide" secure or private information | ||||
| but does not disrupt message forwarding. This policy-based | ||||
| information provisioning reduces the deployment barrier faced by | ||||
| operators in installing and running CCNinfo on their routers. | ||||
| 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 | 1. Request 2. Request 3. Request | |||
| (+U) (U+A) (U+A+B) | (U) (U+A) (U+A+B) | |||
| +----+ +----+ +----+ | +----+ +----+ +----+ | |||
| | | | | | | | | | | | | | | |||
| | v | v | v | | v | v | v | |||
| +--------+ +--------+ +--------+ +--------+ +---------+ | +--------+ +--------+ +--------+ +--------+ +---------+ | |||
| | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| | | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| | |||
| | user | | A | | B | | C | | | | | user | | A | | B | | C | | | | |||
| +--------+ +--------+ +--------+ +--------+ +---------+ | +--------+ +--------+ +--------+ +--------+ +---------+ | |||
| \ | \ | |||
| \ +-------+ | \ +-------+ | |||
| 3. Request \ | Cache | | 3. Request \ | Cache | | |||
| (U+A+B) \ +---------+ | | (U+A+B) \ +---------+ | | |||
| v| Caching |----+ | v| Caching |----+ | |||
| | router | | | router | | |||
| +---------+ | +---------+ | |||
| Figure 1: Request messages forwarded by consumer and routers. | Figure 1: Request message invoked by CCNinfo user and forwarded by | |||
| CCNinfo user and routers (i.e., Router A, B, C) insert their own | routers. | |||
| Report blocks into the Request message and forward the message toward | ||||
| the content forwarder (i.e., caching router and publisher). | 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) | 3. Reply(P) 2. Reply(P) 1. Reply(P) | |||
| +----+ +----+ +----+ | +----+ +----+ +----+ | |||
| | | | | | | | | | | | | | | |||
| v | v | v | | v | v | v | | |||
| +--------+ +--------+ +--------+ +--------+ +---------+ | +--------+ +--------+ +--------+ +--------+ +---------+ | |||
| | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| | | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| | |||
| | user | | A | | B | | C | | | | | user | | A | | B | | C | | | | |||
| +--------+ +--------+ +--------+ +--------+ +---------+ | +--------+ +--------+ +--------+ +--------+ +---------+ | |||
| ^ | ^ | |||
| \ +-------+ | \ +-------+ | |||
| 1. Reply(C) \ | Cache | | 1. Reply(C) \ | Cache | | |||
| \ +---------+ | | \ +---------+ | | |||
| \| Caching |----+ | \| Caching |----+ | |||
| | router | | | router | | |||
| +---------+ | +---------+ | |||
| Figure 2: Default behavior. Reply messages forwarded by routers. | Figure 2: Reply messages forwarded by routers, and one Reply message | |||
| Each router forwards the Reply message along its PIT entry and | is received by CCNinfo user. | |||
| 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 when the other Reply message (i.e., Reply(P)) was already | ||||
| forwarded by Router B. | ||||
| CCNinfo supports multipath forwarding. The Request messages can be | ||||
| forwarded to multiple neighbor routers. When the Request messages | ||||
| are forwarded to multiple routers, the different Reply messages are | ||||
| forwarded from different routers or publishers. | ||||
| Furthermore, CCNinfo implements policy-based information provisioning | ||||
| that enables administrators to "hide" secure or private information | ||||
| but does not disrupt message forwarding. This policy-based | ||||
| information provisioning reduces the deployment barrier faced by | ||||
| operators in installing and running CCNinfo on their routers. | ||||
| 1.1. CCNinfo as an Experimental Tool | ||||
| CCNinfo is intended as a comprehensive experimental tool for CCN | ||||
| networks. It provides a wealth of information from CCN 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. | ||||
| Usually, the CCNinfo user (e.g., consumer) invokes the CCNinfo user | ||||
| program (such as "ccninfo" command described in Appendix A) with the | ||||
| name prefix of the content. The user program initiates the Request | ||||
| message (described in Section 3.1) to obtain routing path and cache | ||||
| information. When an appropriate adjacent neighbor router receives | ||||
| the Request message, it retrieves own cache information. If the | ||||
| router is not the content forwarder for the specified name prefix, it | ||||
| inserts its Report block (described in Section 3.1.2) into the | ||||
| Request message and forwards it to its upstream neighbor router(s) | ||||
| decided by its FIB. | ||||
| The Request message is forwarded by routers toward the content | ||||
| publisher and the Report record is inserted by each intermediate | ||||
| router. When the Request message reaches the content forwarder | ||||
| (i.e., a router that can forward the specified content), the content | ||||
| forwarder forms the Reply message (described in Section 3.2) and | ||||
| sends it to the downstream neighbor router. The Reply message is | ||||
| forwarded back toward the user in a hop-by-hop manner (along the PIT | ||||
| entries). | ||||
| 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. | ||||
| 2. Terminology | 2. Terminology | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 (RFC2119 [3] and RFC8174 [4]) when, and only when, they appear in | 14 (RFC2119 [3] and RFC8174 [4]) when, and only when, they appear in | |||
| all capitals, as shown here. | all capitals, as shown here. | |||
| 2.1. Definitions | 2.1. Definitions | |||
| This document follows the basic terminologies and definitions | This document follows the basic terminologies and definitions | |||
| described in [1]. Although CCNinfo requests flow in the opposite | described in [1]. Although CCNinfo requests flow in the opposite | |||
| direction to the data flow, we refer to "upstream" and "downstream" | direction to the data flow, we refer to "upstream" and "downstream" | |||
| with respect to data, unless explicitly specified. | with respect to data, unless explicitly specified. | |||
| Router | ||||
| It is a router that facilitates CCN-based content retrieval in the | ||||
| path between the consumer and publisher. | ||||
| Scheme name | Scheme name | |||
| It indicates a URI and protocol. This document only considers | It indicates a URI and protocol. This document only considers | |||
| "ccnx:/" as the scheme name. | "ccnx:/" as the scheme name. | |||
| Prefix name | Prefix name | |||
| A prefix name, which is defined in [2], is a name that does not | A prefix name, which is defined in [2], is a name that does not | |||
| uniquely identify a single content object, but rather a namespace | uniquely identify a single content object, but rather a namespace | |||
| or prefix of an existing content object name. | or prefix of an existing content object name. | |||
| Exact name | Exact name | |||
| An exact name, which is defined in [2], is one that uniquely | An exact name, which is defined in [2], is one that uniquely | |||
| identifies the name of a content object. | identifies the name of a content object. | |||
| Node | Node | |||
| It is a router, publisher, or consumer. | A node within a CCN network can fulfill the role of a data | |||
| publisher, a data consumer, and/or a forwarder for interest and | ||||
| content object as given in [6]. | ||||
| Consumer | ||||
| A node that requests content objects by generating and sending out | ||||
| interests. It is a same definition of ICN Consumer as given in | ||||
| [6]. | ||||
| Publisher | ||||
| A node that creates content objects and makes them available for | ||||
| retrieval. It is a same definition of ICN Producer as given in | ||||
| [6]. | ||||
| Router | ||||
| A node that implements stateful forwarding in the path between | ||||
| consumer and publisher. | ||||
| Caching router | ||||
| A node that temporarily stores and potentially carries interests | ||||
| or content objects before forwarding it to next node. | ||||
| Content forwarder | Content forwarder | |||
| It is either a caching router or a first-hop router that forwards | It is either a caching router or a first-hop router that forwards | |||
| content objects to consumers. | content objects to consumers. | |||
| CCNinfo user | CCNinfo user | |||
| It is a node that initiates the CCNinfo Request, which is usually | A node that initiates the CCNinfo Request, which is consumer or | |||
| invoked by the user program (described in Appendix A) or other | router that invokes the CCNinfo user program with the name prefix | |||
| similar commands. | of the content. The CCNinfo user program, such as "ccninfo" | |||
| command described in Appendix A or other similar commands, | ||||
| initiates the Request message to obtain routing path and cache | ||||
| information. | ||||
| Incoming face | Incoming face | |||
| The face on which data are expected to arrive from the specified | The face on which data are expected to arrive from the specified | |||
| name prefix. | name prefix. | |||
| Outgoing face | Outgoing face | |||
| The face to which data from the publisher or router are expected | The face to which data from the publisher or router are expected | |||
| to transmit for the specified name prefix. It is also the face on | to transmit for the specified name prefix. It is also the face on | |||
| which the Request messages are received. | which the Request messages are received. | |||
| skipping to change at page 8, line 27 ¶ | skipping to change at page 9, line 14 ¶ | |||
| First-hop router (FHR) | First-hop router (FHR) | |||
| The router that matches a FIB entry with an Outgoing face | The router that matches a FIB entry with an Outgoing face | |||
| referring to a local application or a publisher. | referring to a local application or a publisher. | |||
| Last-hop router (LHR) | Last-hop router (LHR) | |||
| The router that is directly connected to a consumer. | The router that is directly connected to a consumer. | |||
| 3. CCNinfo Message Formats | 3. CCNinfo Message Formats | |||
| CCNinfo uses two message types: Request and Reply. Both messages are | CCNinfo Request and Reply messages are encoded in the CCNx TLV format | |||
| encoded in the CCNx TLV format ([1], Figure 3). The Request message | ([1], Figure 3). The Request message consists of a fixed header, | |||
| consists of a fixed header, Request block TLV (Figure 7), and Report | Request block TLV (Figure 7), and Report block TLV(s) (Figure 12). | |||
| block TLV(s) (Figure 12). The Reply message consists of a fixed | The Reply message consists of a fixed header, Request block TLV, | |||
| header, Request block TLV, Report block TLV(s), and Reply block/sub- | Report block TLV(s), Reply block TLV (Figure 14), and Reply sub-block | |||
| block TLV(s) (Figure 14). | TLV(s) (Figure 15). | |||
| 1 2 3 | 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 | 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 | | | Version | PacketType | PacketLength | | |||
| +---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| | PacketType specific fields | HeaderLength | | | PacketType specific fields | HeaderLength | | |||
| +---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| / Optional Hop-by-hop header TLVs / | / Optional Hop-by-hop header TLVs / | |||
| +---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| / PacketPayload TLVs / | / PacketPayload TLVs / | |||
| +---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| / Optional CCNx ValidationAlgorithm TLV / | / Optional CCNx ValidationAlgorithm TLV / | |||
| +---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| / Optional CCNx ValidationPayload TLV (ValidationAlg required) / | / Optional CCNx ValidationPayload TLV (ValidationAlg required) / | |||
| +---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| Figure 3: Packet format [1] | Figure 3: Packet format [1] | |||
| The Request and Reply Type values in the fixed header are | The PacketType values in the fixed header shown in Figure 3 are | |||
| PT_CCNINFO_REQUEST and PT_CCNINFO_REPLY, respectively (Figure 4). | PT_CCNINFO_REQUEST and PT_CCNINFO_REPLY, respectively (Figure 4). | |||
| These messages are forwarded in a hop-by-hop manner. When the | CCNinfo Request and Reply messages are forwarded in a hop-by-hop | |||
| Request message reaches the content forwarder, the content forwarder | manner. When the Request message reaches the content forwarder, the | |||
| turns it into a Reply message by changing the Type field value in the | content forwarder turns it into a Reply message by changing the Type | |||
| fixed header from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY and forwards | field value in the fixed header from PT_CCNINFO_REQUEST to | |||
| it back toward the node that initiated the Request message. | PT_CCNINFO_REPLY and forwards it back toward the node that initiated | |||
| the Request message. | ||||
| Code Type name | Code Type name | |||
| ======== ===================== | ======== ===================== | |||
| %x00 PT_INTEREST [1] | %x00 PT_INTEREST [1] | |||
| %x01 PT_CONTENT [1] | %x01 PT_CONTENT [1] | |||
| %x02 PT_RETURN [1] | %x02 PT_RETURN [1] | |||
| %x03 PT_CCNINFO_REQUEST | %x03 PT_CCNINFO_REQUEST | |||
| %x04 PT_CCNINFO_REPLY | %x04 PT_CCNINFO_REPLY | |||
| Figure 4: Packet Type Namespace | Figure 4: Packet Type Namespace | |||
| The CCNinfo Request and Reply messages MUST begin with a fixed header | Following a fixed header, there can be a sequence of optional hop-by- | |||
| with either a Request or Reply type value to specify whether it is a | hop header TLV(s) for a Request message. In the case of a Request | |||
| Request message or Reply message. Following a fixed header, there | message, it is followed by a sequence of Report blocks, each from a | |||
| can be a sequence of optional hop-by-hop header TLV(s) for a Request | router on the path toward the publisher or caching router. | |||
| message. In the case of a Request message, it is followed by a | ||||
| sequence of Report blocks, each from a router on the path toward the | ||||
| publisher or caching router. | ||||
| At the beginning of PacketPayload TLVs, a top-level TLV type, | At the beginning of PacketPayload TLVs, a top-level TLV type, | |||
| T_DISCOVERY (Figure 5), exists at the outermost level of a CCNx | T_DISCOVERY (Figure 5), exists at the outermost level of a CCNx | |||
| protocol message. This TLV indicates that the Name segment TLV(s) | protocol message. This TLV indicates that the Name segment TLV(s) | |||
| and Reply block TLV(s) would follow in the Request or Reply message. | and Reply block TLV(s) would follow in the Request or Reply message. | |||
| Code Type name | Code Type name | |||
| ============= ========================= | ============= ========================= | |||
| %x0000 Reserved [1] | %x0000 Reserved [1] | |||
| %x0001 T_INTEREST [1] | %x0001 T_INTEREST [1] | |||
| skipping to change at page 10, line 7 ¶ | skipping to change at page 10, line 45 ¶ | |||
| 3.1. Request Message | 3.1. Request Message | |||
| When a CCNinfo user initiates a discovery request (e.g., via the | When a CCNinfo user initiates a discovery request (e.g., via the | |||
| ccninfo command described in Appendix A), a CCNinfo Request message | ccninfo command described in Appendix A), a CCNinfo Request message | |||
| is created and forwarded to its upstream router through the Incoming | is created and forwarded to its upstream router through the Incoming | |||
| face(s) determined by its FIB. | face(s) determined by its FIB. | |||
| The Request message format is shown in Figure 6. It consists of a | The Request message format is shown in Figure 6. It consists of a | |||
| fixed header, Request header block TLV (Figure 7), Report block | fixed header, Request header block TLV (Figure 7), Report block | |||
| TLV(s) (Figure 12), Name TLV, and Request block TLV. The Type value | TLV(s) (Figure 12), Name TLV, and Request block TLV. Request header | |||
| of the Top-Level type namespace is T_DISCOVERY (Figure 5). The Type | block TLV and Report block TLV(s) are contained in the hop-by-hop | |||
| value for the Report message is PT_CCNINFO_REQUEST. | header, as those might change from hop to hop. Request block TLV is | |||
| encoded in the PacketPayload TLV by content forwarder as the protocol | ||||
| message itself. The PacketType value of the Request message is | ||||
| PT_CCNINFO_REQUEST (Figure 4). The Type value of the Top-Level type | ||||
| namespace is T_DISCOVERY (Figure 5). | ||||
| 1 2 3 | 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 | 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 | | | Version | PacketType | PacketLength | | |||
| +---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| | HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength | | | HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength | | |||
| +===============+===============+===============+===============+ | +===============+===============+===============+===============+ | |||
| / Request header block TLV / | / Request header block TLV / | |||
| +---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| skipping to change at page 11, line 47 ¶ | skipping to change at page 12, line 42 ¶ | |||
| Reserved (MBZ): 8 bits | Reserved (MBZ): 8 bits | |||
| The reserved fields in the Value field MUST be transmitted as | The reserved fields in the Value field MUST be transmitted as | |||
| zeros and ignored on receipt. | zeros and ignored on receipt. | |||
| 3.1.1. Request Header Block and Request Block | 3.1.1. Request Header Block and Request Block | |||
| When a CCNinfo user transmits the Request message, s/he MUST insert | When a CCNinfo user transmits the Request message, s/he MUST insert | |||
| her/his Request header block TLV (Figure 7) into the hop-by-hop | her/his Request header block TLV (Figure 7) into the hop-by-hop | |||
| header and Request block TLV (Figure 7) into the message before | header and Request block TLV (Figure 10) into the message before | |||
| sending it through the Incoming face(s). | sending it through the Incoming face(s). | |||
| 1 2 3 | 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 | 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 | | | Type (=T_DISC_REQHDR) | Length | | |||
| +---------------+---------------+-------+-------+-------+-+-+-+-+ | +---------------+---------------+-------+-------+-------+-+-+-+-+ | |||
| | Request ID |SkipHop| Flags |V|F|O|C| | | Request ID |SkipHop| Flags |V|F|O|C| | |||
| +---------------+---------------+-------+-------+-------+-+-+-+-+ | +---------------+---------------+-------+-------+-------+-+-+-+-+ | |||
| skipping to change at page 12, line 47 ¶ | skipping to change at page 13, line 47 ¶ | |||
| Length of Value field in octets. | Length of Value field in octets. | |||
| Request ID: 16 bits | Request ID: 16 bits | |||
| This field is used as a unique identifier for the CCNinfo Request | This field is used as a unique identifier for the CCNinfo Request | |||
| so that the duplicate or delayed Reply messages can be detected. | so that the duplicate or delayed Reply messages can be detected. | |||
| SkipHop (Skip Hop Count): 4 bits | SkipHop (Skip Hop Count): 4 bits | |||
| Number of skipped routers for a Request. It is specified by the | Number of skipped routers for a Request. It is specified by the | |||
| CCNinfo user program. Routers corresponding to the value | CCNinfo user program. The number of routers corresponding to the | |||
| specified in this field are skipped and the CCNinfo Request | value specified in this field are skipped and the CCNinfo Request | |||
| messages are forwarded to the next router without the addition of | messages are forwarded to the next router without the addition of | |||
| Report blocks; the next upstream router then starts the trace. | Report blocks; the next upstream router then starts the trace. | |||
| The maximum value of this parameter is 15. This value MUST be | The maximum value of this parameter is 15. This value MUST be | |||
| lower than that of HopLimit at the fixed header. | lower than that of HopLimit at the fixed header. | |||
| Flags: 12 bits | Flags: 12 bits | |||
| The Flags field is used to indicate the types of the content or | The Flags field is used to indicate the types of the content or | |||
| path discoveries. Currently, as shown in Figure 9, four bits, | path discoveries. Currently, as shown in Figure 9, four bits, | |||
| "C", "O", "F", and "V" are assigned, and the other 8 bits are | "C", "O", "F", and "V" are assigned, and the other 8 bits are | |||
| skipping to change at page 13, line 21 ¶ | skipping to change at page 14, line 21 ¶ | |||
| specified with other flags. These flags are set by the CCNinfo | specified with other flags. These flags are set by the CCNinfo | |||
| user program when they initiate Requests (see Appendix A), and the | user program when they initiate Requests (see Appendix A), and the | |||
| routers that receive the Requests deal with the flags and change | routers that receive the Requests deal with the flags and change | |||
| the behaviors (see Section 5 for details). The Flag values | the behaviors (see Section 5 for details). The Flag values | |||
| defined in this Flags field correspond to the Reply sub-blocks. | defined in this Flags field correspond to the Reply sub-blocks. | |||
| Flag Value Description | Flag Value Description | |||
| ----- ----- ----------------------------------------------------- | ----- ----- ----------------------------------------------------- | |||
| C 0 Path discovery (i.e., no cache information retrieved) | C 0 Path discovery (i.e., no cache information retrieved) | |||
| (default) | (default) | |||
| C 1 Cache information retrieval | C 1 Path and cache information retrieval | |||
| O 0 Request to any content forwarder (default) | O 0 Request to any content forwarder (default) | |||
| O 1 Publisher discovery (i.e., only FHR can reply) | O 1 Publisher discovery (i.e., only FHR can reply) | |||
| F 0 Request based on FIB's strategy (default) | F 0 Request based on FIB's forwarding strategy (default) | |||
| F 1 Full discovery request. Request to possible multiple | F 1 Full discovery request. Request to possible multiple | |||
| upstream routers specified in FIB simultaneously | upstream routers specified in FIB simultaneously | |||
| V 0 No reply validation (default) | V 0 No reply validation (default) | |||
| V 1 Reply sender validates Reply message | V 1 Reply sender validates Reply message | |||
| Figure 9: Codes and types specified in Flags field | Figure 9: Codes and types specified in Flags field | |||
| 1 2 3 | 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 | 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 | |||
| +---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| skipping to change at page 14, line 34 ¶ | skipping to change at page 15, line 34 ¶ | |||
| value(s) MUST be T_DISC_REQ (see Figure 11) in the current | value(s) MUST be T_DISC_REQ (see Figure 11) in the current | |||
| specification. | specification. | |||
| Length: 16 bits | Length: 16 bits | |||
| Length of Value field in octets. | Length of Value field in octets. | |||
| Request Arrival Time: 32 bits | Request Arrival Time: 32 bits | |||
| The Request Arrival Time is a 32-bit NTP timestamp specifying the | The Request Arrival Time is a 32-bit NTP timestamp specifying the | |||
| arrival time of the CCNinfo Request packet at a specific router. | arrival time of the CCNinfo Request message at the router. The | |||
| The 32-bit form of an NTP timestamp consists of the middle 32 bits | 32-bit form of an NTP timestamp consists of the middle 32 bits of | |||
| of the full 64-bit form; that is, the low 16 bits of the integer | the full 64-bit form; that is, the low 16 bits of the integer part | |||
| part and the high 16 bits of the fractional part. | and the high 16 bits of the fractional part. | |||
| The following formula converts from a timespec (fractional part in | The following formula converts from a timespec (fractional part in | |||
| nanoseconds) to a 32-bit NTP timestamp: | nanoseconds) to a 32-bit NTP timestamp: | |||
| request_arrival_time | request_arrival_time | |||
| = ((tv.tv_sec + 32384) << 16) + ((tv.tv_nsec << 7) / 1953125) | = ((tv.tv_sec + 32384) << 16) + ((tv.tv_nsec << 7) / 1953125) | |||
| The constant 32384 is the number of seconds from Jan 1, 1900 to | 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) | Jan 1, 1970 truncated to 16 bits. ((tv.tv_nsec << 7) / 1953125) | |||
| is a reduction of ((tv.tv_nsec / 1000000000) << 16), where "<<" | is a reduction of ((tv.tv_nsec / 1000000000) << 16), where "<<" | |||
| denotes a logical left shift. | denotes a logical left shift. | |||
| Note that it is RECOMMENDED for all the routers on the path to | Note that it is RECOMMENDED for all the routers on the path to | |||
| have synchronized clocks to measure one-way latency per hop; | have synchronized clocks to measure one-way latency per hop; | |||
| however, even if they do not have synchronized clocks, CCNinfo | however, even if they do not have synchronized clocks, CCNinfo | |||
| measures the RTT between the content forwarder and consumer. | measures the RTT between the content forwarder and consumer. | |||
| Node Identifier: variable length | Node Identifier: variable length | |||
| This field specifies the node identifier (e.g., node name or hash- | This field specifies the node identifier (e.g., node name or hash- | |||
| based self-certifying name [10]) or all-zeros if unknown. This | based self-certifying name [11]) or all-zeros if unknown. This | |||
| document assumes that the Name TLV defined in the CCNx TLV format | document assumes that the Name TLV defined in the CCNx TLV format | |||
| [1] can be used for this field and the node identifier is | [1] can be used for this field and the node identifier is | |||
| specified in it. | specified in it. | |||
| 3.1.2. Report Block TLV | 3.1.2. Report Block TLV | |||
| A CCNinfo user and each upstream router along the path would insert | A CCNinfo user and each upstream router along the path would insert | |||
| their own Report block TLV without changing the Type field of the | their own Report block TLV without changing the Type field of the | |||
| fixed header of the Request message until one of these routers is | fixed header of the Request message until one of these routers is | |||
| ready to send a Reply. In the Report block TLV (Figure 12), the | ready to send a Reply. In the Report block TLV (Figure 12), the | |||
| skipping to change at page 20, line 41 ¶ | skipping to change at page 21, line 41 ¶ | |||
| First Seqnum: 32 bits | First Seqnum: 32 bits | |||
| The first sequential number of the unexpired content objects. | The first sequential number of the unexpired content objects. | |||
| Last Seqnum: 32 bits | Last Seqnum: 32 bits | |||
| The last sequential number of the unexpired content objects. The | The last sequential number of the unexpired content objects. The | |||
| First Seqnum and Last Seqnum do not guarantee the consecutiveness | First Seqnum and Last Seqnum do not guarantee the consecutiveness | |||
| of the cached content objects; however, knowing these values may | of the cached content objects; however, knowing these values may | |||
| help in the analysis of consecutive or discontinuous chunks such | help in the analysis of consecutive or discontinuous chunks such | |||
| as [11]. | as [12]. | |||
| Elapsed Cache Time: 32 bits | Elapsed Cache Time: 32 bits | |||
| The elapsed time (seconds) after the oldest content object of the | The elapsed time (seconds) after the oldest content object of the | |||
| content is cached. | content is cached. | |||
| Remain Cache Lifetime: 32 bits | Remain Cache Lifetime: 32 bits | |||
| The lifetime (seconds) of a content object, which is lastly | The lifetime (seconds) of a content object, which is lastly | |||
| cached. | cached. | |||
| skipping to change at page 23, line 31 ¶ | skipping to change at page 24, line 31 ¶ | |||
| flag is not set, it is categorized as the "routing path | 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 "C" flag is set, it is the "cache | |||
| information discovery". If the "O" flag is set, it is the | information discovery". If the "O" flag is set, it is the | |||
| "publisher discovery". | "publisher discovery". | |||
| 3. If the Request is either "cache information discovery" or | 3. If the Request is either "cache information discovery" or | |||
| "routing path information discovery", the router examines its FIB | "routing path information discovery", the router examines its FIB | |||
| and CS. If the router caches the specified content, it sends the | 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 | 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 | router cannot insert its own Reply block or sub-block(s) because | |||
| of no space, it it terminates the Request, as specified in | of no space, it terminates the Request, as specified in | |||
| Section 6.7. If the router does not cache the specified content | Section 6.7. If the router does not cache the specified content | |||
| but knows the upstream neighbor router(s) for the specified name | but knows the upstream neighbor router(s) for the specified name | |||
| prefix, it creates the PIT entry, and inserts its own Report | prefix, it creates the PIT entry, and inserts its own Report | |||
| block in the hop-by-hop header and forwards the Request to the | block in the hop-by-hop header and forwards the Request to the | |||
| upstream neighbor(s). If the router cannot insert its own Report | upstream neighbor(s). If the router cannot insert its own Report | |||
| block because of no space, or if the router does not cache the | block because of no space, or if the router does not cache the | |||
| specified content and does not know the upstream neighbor | specified content and does not know the upstream neighbor | |||
| router(s) for the specified name prefix, it terminates the | router(s) for the specified name prefix, it terminates the | |||
| Request, as defined in Section 6.5. | Request, as defined in Section 6.5. | |||
| skipping to change at page 24, line 5 ¶ | skipping to change at page 25, line 5 ¶ | |||
| whether it is the FHR for the requested content. If the router | 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 | is the FHR, it sends the Reply message with its own Report block | |||
| and sub-blocks (in the case of cache information discovery) or | and sub-blocks (in the case of cache information discovery) or | |||
| the Reply message with its own Report block without adding any | the Reply message with its own Report block without adding any | |||
| Reply sub-blocks (in the case of routing path information | Reply sub-blocks (in the case of routing path information | |||
| discovery). If the router is not the FHR but knows the upstream | discovery). If the router is not the FHR but knows the upstream | |||
| neighbor router(s) for the specified name prefix, it creates the | neighbor router(s) for the specified name prefix, it creates the | |||
| PIT entry, and inserts its own Report block and forwards the | PIT entry, and inserts its own Report block and forwards the | |||
| Request to the upstream neighbor(s). If the router cannot insert | Request to the upstream neighbor(s). If the router cannot insert | |||
| its own Report block in the hop-by-hop header because of no | its own Report block in the hop-by-hop header because of no | |||
| space, it it terminates the Request, as specified in Section 6.7. | space, it terminates the Request, as specified in Section 6.7. | |||
| If the router is not the FHR and does not know the upstream | If the router is not the FHR and does not know the upstream | |||
| neighbor router(s) for the specified name prefix, it terminates | neighbor router(s) for the specified name prefix, it terminates | |||
| the Request, as defined in Section 6.5. Note that in Cefore | the Request, as defined in Section 6.5. Note that in Cefore | |||
| [13], there is an API by which a publisher informs the | [14], there is an API by which a publisher informs the | |||
| application prefix to the FHR and the FHR registers it into the | application prefix to the FHR and the FHR registers it into the | |||
| FIB. The prefix entry then can be statically configured on other | FIB. The prefix entry then can be statically configured on other | |||
| routers or announced by a routing protocol. | routers or announced by a routing protocol. | |||
| 5.3. Forwarding CCNinfo Request | 5.3. Forwarding CCNinfo Request | |||
| 5.3.1. Regular Request | 5.3.1. Regular Request | |||
| When a router decides to forward a Request message with its Report | When a router decides to forward a Request message with its Report | |||
| block to its upstream router(s), it specifies the Request Arrival | block to its upstream router(s), it specifies the Request Arrival | |||
| skipping to change at page 28, line 34 ¶ | skipping to change at page 29, line 34 ¶ | |||
| 6.3. Arriving at Last Router | 6.3. Arriving at Last Router | |||
| A CCNinfo Request can be determined to have arrived at the last | A CCNinfo Request can be determined to have arrived at the last | |||
| router of the specified HopLimit. If the last router does not have | router of the specified HopLimit. If the last router does not have | |||
| the corresponding cache, it MUST insert its Report block and send the | the corresponding cache, it MUST insert its Report block and send the | |||
| Reply message with NO_INFO return code without appending any Reply | Reply message with NO_INFO return code without appending any Reply | |||
| (sub-)block TLVs. | (sub-)block TLVs. | |||
| 6.4. Invalid Request | 6.4. Invalid Request | |||
| If the router does not validate the Request or the Reply, the router | If the router does not validate the Request or the Reply even it is | |||
| MUST note a ReturnCode of INVALID_REQUEST in the fixed header of the | required, the router MUST note a ReturnCode of INVALID_REQUEST in the | |||
| message, insert its Report block, and forward the message as the | fixed header of the message, insert its Report block, and forward the | |||
| Reply back to the CCNinfo user. The router MAY, however, randomly | message as the Reply back to the CCNinfo user. The router MAY, | |||
| ignore the received invalid messages. (See Section 10.7.) | however, randomly ignore the received invalid messages. (See | |||
| Section 10.7.) | ||||
| 6.5. No Route | 6.5. No Route | |||
| If the router cannot determine the routing paths or neighbor routers | If the router cannot determine the routing paths or neighbor routers | |||
| for the specified name prefix within the specified HopLimit, it MUST | for the specified name prefix within the specified HopLimit, it MUST | |||
| note a ReturnCode of NO_ROUTE in the fixed header of the message, | 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 | insert its Report block, and forward the message as the Reply back to | |||
| the CCNinfo user. | the CCNinfo user. | |||
| 6.6. No Information | 6.6. No Information | |||
| skipping to change at page 33, line 51 ¶ | skipping to change at page 35, line 10 ¶ | |||
| returning multiple Reply messages. To prevent abuse, the routers in | returning multiple Reply messages. To prevent abuse, the routers in | |||
| the traced path MAY need to rate-limit the Replies. In such a case, | 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 | no error message is returned. The rate limit function is left to the | |||
| router's implementation. | router's implementation. | |||
| 10.9. Adjacency Verification | 10.9. Adjacency Verification | |||
| It is assumed that the CCNinfo Request and Reply messages are | It is assumed that the CCNinfo Request and Reply messages are | |||
| forwarded by adjacent neighbor nodes or routers. The CCNx message | forwarded by adjacent neighbor nodes or routers. The CCNx message | |||
| format or semantics do not define a secure way to verify the node/ | format or semantics do not define a secure way to verify the node/ | |||
| router adjacency, while HopAuth [10] provides a possible method for | router adjacency, while HopAuth [11] provides a possible method for | |||
| an adjacency verification and defines the corresponding message | an adjacency verification and defines the corresponding message | |||
| format for adjacency verification as well as the router behaviors. | format for adjacency verification as well as the router behaviors. | |||
| CCNinfo MAY use a similar method for node adjacency verification. | CCNinfo MAY use a similar method for node adjacency verification. | |||
| 11. Acknowledgements | 11. Acknowledgements | |||
| The authors would like to thank Spyridon Mastorakis, Paulo Mendes, | The authors would like to thank Spyridon Mastorakis, Paulo Mendes, | |||
| Ilya Moiseenko, David Oran, and Thierry Turletti for their valuable | Ilya Moiseenko, David Oran, and Thierry Turletti for their valuable | |||
| comments and suggestions on this document. | comments and suggestions on this document. | |||
| skipping to change at page 34, line 40 ¶ | skipping to change at page 35, line 47 ¶ | |||
| 2119 Key Words", May 2017, | 2119 Key Words", May 2017, | |||
| <https://www.rfc-editor.org/info/rfc8174>. | <https://www.rfc-editor.org/info/rfc8174>. | |||
| [5] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | [5] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | |||
| Writing an IANA Considerations Section in RFCs", BCP 26, | Writing an IANA Considerations Section in RFCs", BCP 26, | |||
| RFC 8126, DOI 10.17487/RFC8126, June 2017, | RFC 8126, DOI 10.17487/RFC8126, June 2017, | |||
| <https://www.rfc-editor.org/info/rfc8126>. | <https://www.rfc-editor.org/info/rfc8126>. | |||
| 12.2. Informative References | 12.2. Informative References | |||
| [6] Asaeda, H., Matsuzono, K., and T. Turletti, "Contrace: A | [6] 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, June 2020. | ||||
| [7] Asaeda, H., Matsuzono, K., and T. Turletti, "Contrace: A | ||||
| Tool for Measuring and Tracing Content-Centric Networks", | Tool for Measuring and Tracing Content-Centric Networks", | |||
| IEEE Communications Magazine, Vol.53, No.3, pp.182-188, | IEEE Communications Magazine, Vol.53, No.3, pp.182-188, | |||
| March 2015. | March 2015. | |||
| [7] Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and | [8] Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and | |||
| D. Oran, "ICN Ping Protocol Specification", draft-irtf- | D. Oran, "ICN Ping Protocol Specification", draft-irtf- | |||
| icnrg-icnping-03 (work in progress), October 2021. | icnrg-icnping-05 (work in progress), April 2022. | |||
| [8] Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and | [9] Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and | |||
| D. Oran, "ICN Traceroute Protocol Specification", draft- | D. Oran, "ICN Traceroute Protocol Specification", draft- | |||
| irtf-icnrg-icntraceroute-03 (work in progress), October | irtf-icnrg-icntraceroute-05 (work in progress), April | |||
| 2021. | 2022. | |||
| [9] Asaeda, H., Mayer, K., and W. Lee, "Mtrace Version 2: | [10] Asaeda, H., Mayer, K., and W. Lee, "Mtrace Version 2: | |||
| Traceroute Facility for IP Multicast", RFC 8487, October | Traceroute Facility for IP Multicast", RFC 8487, October | |||
| 2018. | 2018. | |||
| [10] Li, R. and H. Asaeda, "Hop-by-Hop Authentication in | [11] Li, R. and H. Asaeda, "Hop-by-Hop Authentication in | |||
| Content-Centric Networking/Named Data Networking", draft- | Content-Centric Networking/Named Data Networking", draft- | |||
| li-icnrg-hopauth-02 (work in progress), February 2020. | li-icnrg-hopauth-02 (work in progress), February 2020. | |||
| [11] Li, R., Matsuzono, K., Asaeda, H., and X. Fu, "Consecutive | [12] Li, R., Matsuzono, K., Asaeda, H., and X. Fu, "Consecutive | |||
| Caching and Adaptive Retrieval for In-Network Big Data | Caching and Adaptive Retrieval for In-Network Big Data | |||
| Sharing", Proc. IEEE ICC, Kansas City, USA, May 2018. | Sharing", Proc. IEEE ICC, Kansas City, USA, May 2018. | |||
| [12] Asaeda, H., Ooka, A., Matsuzono, K., and R. Li, "Cefore: | [13] Asaeda, H., Ooka, A., Matsuzono, K., and R. Li, "Cefore: | |||
| Software Platform Enabling Content-Centric Networking and | Software Platform Enabling Content-Centric Networking and | |||
| Beyond", IEICE Transaction on Communications, Vol.E102-B, | Beyond", IEICE Transaction on Communications, Vol.E102-B, | |||
| No.9, pp.1792-1803, September 2019. | No.9, pp.1792-1803, September 2019. | |||
| [13] "Cefore Home Page", <https://cefore.net/>. | [14] "Cefore Home Page", <https://cefore.net/>. | |||
| Appendix A. ccninfo Command and Options | Appendix A. ccninfo Command and Options | |||
| CCNinfo is implemented in Cefore [12][13]. The command invoked by | CCNinfo is implemented in Cefore [13][14]. The command invoked by | |||
| the CCNinfo user (e.g., consumer) is named "ccninfo". The ccninfo | the CCNinfo user (e.g., consumer) is named "ccninfo". The ccninfo | |||
| command sends the Request message and receives the Reply message(s). | command sends the Request message and receives the Reply message(s). | |||
| There are several options that can be specified with ccninfo, while | There are several options that can be specified with ccninfo, while | |||
| the content name prefix (e.g., ccnx:/news/today) is the mandatory | the content name prefix (e.g., ccnx:/news/today) is the mandatory | |||
| parameter. | parameter. | |||
| The usage of ccninfo command is as follows: | The usage of ccninfo command is as follows: | |||
| Usage: ccninfo [-c] [-f] [-o] [-V] [-r hop_count] [-s hop_count] [-v | Usage: ccninfo [-c] [-f] [-o] [-V] [-r hop_count] [-s hop_count] [-v | |||
| algo] name_prefix | algo] name_prefix | |||
| End of changes. 45 change blocks. | ||||
| 200 lines changed or deleted | 222 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||