< draft-irtf-icnrg-ccninfo-01.txt   draft-irtf-icnrg-ccninfo-02.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: September 12, 2019 X. Shao Expires: January 9, 2020 X. Shao
Kitami Institute of Technology Kitami Institute of Technology
March 11, 2019 July 8, 2019
CCNinfo: Discovering Content and Network Information in Content-Centric CCNinfo: Discovering Content and Network Information in Content-Centric
Networks Networks
draft-irtf-icnrg-ccninfo-01 draft-irtf-icnrg-ccninfo-02
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 content forwarder and consumer, and 3) the states of (RTT) between content forwarder and consumer, and 3) the states of
in-network cache per name prefix. in-network cache per name prefix.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 September 12, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
3.1.1. Request Block . . . . . . . . . . . . . . . . . . . . 11 3.1.1. Request Block . . . . . . . . . . . . . . . . . . . . 11
3.1.2. Report Block . . . . . . . . . . . . . . . . . . . . 13 3.1.2. Report Block . . . . . . . . . . . . . . . . . . . . 13
3.2. Reply Message . . . . . . . . . . . . . . . . . . . . . . 14 3.2. Reply Message . . . . . . . . . . . . . . . . . . . . . . 14
3.2.1. Reply Block . . . . . . . . . . . . . . . . . . . . . 16 3.2.1. Reply Block . . . . . . . . . . . . . . . . . . . . . 16
3.2.1.1. Reply Sub-Block . . . . . . . . . . . . . . . . . 16 3.2.1.1. Reply Sub-Block . . . . . . . . . . . . . . . . . 16
4. CCNinfo User Behavior . . . . . . . . . . . . . . . . . . . . 19 4. CCNinfo User Behavior . . . . . . . . . . . . . . . . . . . . 19
4.1. Sending CCNinfo Request . . . . . . . . . . . . . . . . . 19 4.1. Sending CCNinfo Request . . . . . . . . . . . . . . . . . 19
4.1.1. Routing Path Information . . . . . . . . . . . . . . 20 4.1.1. Routing Path Information . . . . . . . . . . . . . . 20
4.1.2. In-Network Cache Information . . . . . . . . . . . . 20 4.1.2. In-Network Cache Information . . . . . . . . . . . . 20
4.2. Receiving CCNinfo Reply . . . . . . . . . . . . . . . . . 20 4.2. Receiving CCNinfo Reply . . . . . . . . . . . . . . . . . 20
5. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 20 5. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. User and Neighbor Verification . . . . . . . . . . . . . 20 5.1. User and Neighbor Verification . . . . . . . . . . . . . 21
5.2. Receiving CCNinfo Request . . . . . . . . . . . . . . . . 21 5.2. Receiving CCNinfo Request . . . . . . . . . . . . . . . . 21
5.2.1. Normal Processing . . . . . . . . . . . . . . . . . . 21 5.2.1. Normal Processing . . . . . . . . . . . . . . . . . . 21
5.3. Forwarding CCNinfo Request . . . . . . . . . . . . . . . 22 5.3. Forwarding CCNinfo Request . . . . . . . . . . . . . . . 22
5.4. Sending CCNinfo Reply . . . . . . . . . . . . . . . . . . 23 5.4. Sending CCNinfo Reply . . . . . . . . . . . . . . . . . . 23
5.5. Forwarding CCNinfo Reply . . . . . . . . . . . . . . . . 23 5.5. Forwarding CCNinfo Reply . . . . . . . . . . . . . . . . 23
6. CCNinfo Termination . . . . . . . . . . . . . . . . . . . . . 24 6. CCNinfo Termination . . . . . . . . . . . . . . . . . . . . . 24
6.1. Arriving at First-hop router . . . . . . . . . . . . . . 24 6.1. Arriving at First-hop router . . . . . . . . . . . . . . 24
6.2. Arriving at Router Having Cache . . . . . . . . . . . . . 24 6.2. Arriving at Router Having Cache . . . . . . . . . . . . . 24
6.3. Invalid Request . . . . . . . . . . . . . . . . . . . . . 24 6.3. Invalid Request . . . . . . . . . . . . . . . . . . . . . 24
6.4. No Route . . . . . . . . . . . . . . . . . . . . . . . . 24 6.4. No Route . . . . . . . . . . . . . . . . . . . . . . . . 24
6.5. No Information . . . . . . . . . . . . . . . . . . . . . 24 6.5. No Information . . . . . . . . . . . . . . . . . . . . . 25
6.6. No Space . . . . . . . . . . . . . . . . . . . . . . . . 24 6.6. No Space . . . . . . . . . . . . . . . . . . . . . . . . 25
6.7. Fatal Error . . . . . . . . . . . . . . . . . . . . . . . 25 6.7. Fatal Error . . . . . . . . . . . . . . . . . . . . . . . 25
6.8. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 25 6.8. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 25
6.9. Non-Supported Node . . . . . . . . . . . . . . . . . . . 25 6.9. Non-Supported Node . . . . . . . . . . . . . . . . . . . 25
6.10. Administratively Prohibited . . . . . . . . . . . . . . . 25 6.10. Administratively Prohibited . . . . . . . . . . . . . . . 25
7. Configurations . . . . . . . . . . . . . . . . . . . . . . . 25 7. Configurations . . . . . . . . . . . . . . . . . . . . . . . 25
7.1. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 25 7.1. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 25
7.2. HopLimit in Fixed Header . . . . . . . . . . . . . . . . 25 7.2. HopLimit in Fixed Header . . . . . . . . . . . . . . . . 26
7.3. Access Control . . . . . . . . . . . . . . . . . . . . . 25 7.3. Access Control . . . . . . . . . . . . . . . . . . . . . 26
8. Diagnosis and Analysis . . . . . . . . . . . . . . . . . . . 26 8. Diagnosis and Analysis . . . . . . . . . . . . . . . . . . . 26
8.1. Number of Hops . . . . . . . . . . . . . . . . . . . . . 26 8.1. Number of Hops . . . . . . . . . . . . . . . . . . . . . 26
8.2. Caching Router Identification . . . . . . . . . . . . . . 26 8.2. Caching Router Identification . . . . . . . . . . . . . . 26
8.3. TTL or Hop Limit . . . . . . . . . . . . . . . . . . . . 26 8.3. TTL or Hop Limit . . . . . . . . . . . . . . . . . . . . 26
8.4. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 26 8.4. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 26
8.5. Path Stretch . . . . . . . . . . . . . . . . . . . . . . 26 8.5. Path Stretch . . . . . . . . . . . . . . . . . . . . . . 27
8.6. Cache Hit Probability . . . . . . . . . . . . . . . . . . 26 8.6. Cache Hit Probability . . . . . . . . . . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9.1. Policy-Based Information Provisioning for Request . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9.2. Filtering of CCNinfo Users Located in Invalid Networks . 27 10.1. Policy-Based Information Provisioning for Request . . . 27
9.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 28 10.2. Filtering of CCNinfo Users Located in Invalid Networks . 28
9.4. Characteristics of Content . . . . . . . . . . . . . . . 28 10.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 28
9.5. Longer or Shorter CCNinfo Reply Timeout . . . . . . . . . 28 10.4. Characteristics of Content . . . . . . . . . . . . . . . 28
9.6. Limiting Request Rates . . . . . . . . . . . . . . . . . 28 10.5. Longer or Shorter CCNinfo Reply Timeout . . . . . . . . 28
9.7. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 28 10.6. Limiting Request Rates . . . . . . . . . . . . . . . . . 29
9.8. Adjacency Verification . . . . . . . . . . . . . . . . . 29 10.7. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 29
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 10.8. Adjacency Verification . . . . . . . . . . . . . . . . . 29
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
11.1. Normative References . . . . . . . . . . . . . . . . . . 29 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . 29 12.1. Normative References . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. ccninfo Command and Options . . . . . . . . . . . . 30 Appendix A. ccninfo Command and Options . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
In Content-Centric Networks (CCN), publishers provide content through In Content-Centric Networks (CCN), publishers provide content through
the network, and receivers retrieve content by name. In this network the network, and receivers retrieve content by name. In this network
architecture, routers forward content requests by means of their architecture, routers forward content requests by means of 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.
In CCN, while consumers do not generally need to know which content In CCN, while consumers do not generally need to know which content
forwarder is transmitting the content to them, operators and forwarder is transmitting the content to them, operators and
developers may want to identify the content forwarder and observe the developers may want to identify the content forwarder and observe the
routing path information per name prefix for troubleshooting or routing path information per name prefix for troubleshooting or
investigating the network conditions. investigating the network conditions.
Traceroute [6] is a useful tool for discovering the routing Traceroute [7] is a useful tool for discovering the routing
conditions in IP networks as it provides intermediate router conditions in IP networks as it provides intermediate router
addresses along the path between source and destination and the addresses along the path between source and destination and the
Round-Trip Time (RTT) for the path. However, this IP-based network Round-Trip Time (RTT) for the path. However, this IP-based network
tool cannot trace the name prefix paths used in CCN. Moreover, such tool cannot trace the name prefix paths used in CCN. Moreover, such
IP-based network tool does not obtain the states of the in-network IP-based network tool does not obtain the states of the in-network
cache to be discovered. cache to be discovered.
This document describes the specification of "CCNinfo", an active This document describes the specification 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 is designed based on the work previously information in CCN. CCNinfo is designed based on the work previously
published in [5]. published in [6].
CCNinfo can be implemented with the ccninfo user command and the CCNinfo can be implemented with the ccninfo user command and the
forwarding function implementation on a content forwarder (e.g., forwarding function implementation on a content forwarder (e.g.,
router). The CCNinfo user (e.g., consumer) invokes the ccninfo router). The CCNinfo user (e.g., consumer) invokes the ccninfo
command (described in Appendix A) with the name prefix of the command (described in Appendix A) with the name prefix of the
content. The ccninfo command initiates the "Request" message content. The ccninfo command initiates the "Request" message
(described in Section 3.1). The Request message, for example, (described in Section 3.1). The Request message, for example,
obtains routing path and cache information. When an appropriate obtains routing path and cache information. When an appropriate
adjacent neighbor router receives the Request message, it retrieves adjacent neighbor router receives the Request message, it retrieves
cache information. If the router is not the content forwarder for cache information. If the router is not the content forwarder for
skipping to change at page 4, line 29 skipping to change at page 4, line 29
In this way, the Request message is forwarded by routers toward the In this way, the Request message is forwarded by routers toward the
content publisher, and the Report record is inserted by each content publisher, and the Report record is inserted by each
intermediate router. When the Request message reaches the content intermediate router. When the Request message reaches the content
forwarder (i.e., a router who can forward the specified cache or forwarder (i.e., a router who can forward the specified cache or
content), the content forwarder forms the "Reply" message (described content), the content forwarder forms the "Reply" message (described
in Section 3.2) and sends it to the downstream neighbor router. The 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 Reply message is forwarded back toward the user in a hop-by-hop
manner. This request-reply message flow, walking up the tree from a manner. This request-reply message flow, walking up the tree from a
consumer toward a publisher, is similar to the behavior of the IP consumer toward a publisher, is similar to the behavior of the IP
multicast traceroute facility [7]. multicast traceroute facility [8].
CCNinfo supports multipath forwarding. The Request messages can be CCNinfo supports multipath forwarding. The Request messages can be
forwarded to multiple neighbor routers. When the Request messages forwarded to multiple neighbor routers. When the Request messages
forwarded to multiple routers, the different Reply messages will be forwarded to multiple routers, the different Reply messages will be
forwarded from different routers or publisher. forwarded from different routers or publisher.
1. Request 2. Request 3. Request 1. Request 2. Request 3. Request
(+U) (U+A) (U+A+B) (+U) (U+A) (U+A+B)
+----+ +----+ +----+ +----+ +----+ +----+
| | | | | | | | | | | |
skipping to change at page 8, line 43 skipping to change at page 8, line 43
/ Optional CCNx ValidationPayload TLV (ValidationAlg required) / / Optional CCNx ValidationPayload TLV (ValidationAlg required) /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 4: Packet format [1] Figure 4: Packet format [1]
The Request and Reply Type values in the fixed header are PT_REQUEST The Request and Reply Type values in the fixed header are PT_REQUEST
and PT_REPLY, respectively (Figure 5). These messages are forwarded and PT_REPLY, respectively (Figure 5). These messages are forwarded
in a hop-by-hop manner. When the Request message reaches the content in a hop-by-hop manner. When the Request message reaches the content
forwarder, the content forwarder turns the Request message into a forwarder, the content forwarder turns the Request message into a
Reply message by changing the Type field value in the fixed header Reply message by changing the Type field value in the fixed header
from PT_REQUEST to PT_REPLY and forwards back to the node that has from PT_REQUEST to PT_REPLY and forwards back toward the node that
initiated the Request message. has 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_REQUEST %x03 PT_REQUEST
%x04 PT_REPLY %x04 PT_REPLY
Figure 5: Packet Type Namespace Figure 5: Packet Type Namespace
skipping to change at page 10, line 29 skipping to change at page 10, line 29
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ . / / . /
/ . / / . /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Report block TLV n / / Report block TLV n /
+===============+===============+===============+===============+ +===============+===============+===============+===============+
| T_DISCOVERY | MessageLength | | T_DISCOVERY | MessageLength |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_NAME | Length | | T_NAME | Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Name segment TLVs (name prefix specified by ccninfo command) / / Name segment TLVs (name prefix specified by ccninfo command) /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 7: Request message consists of a fixed header, Request block Figure 7: Request message consists of a fixed header, Request block
TLV, Report block TLV(s), and Name TLV TLV, Report block TLV(s), and Name TLV
HopLimit: 8 bits HopLimit: 8 bits
HopLimit is a counter that is decremented with each hop whenever a HopLimit is a counter that is decremented with each hop whenever a
Request packet is forwarded. It limits the distance a Request may Request packet is forwarded. It limits the distance a Request may
travel on the network. travel on the network.
skipping to change at page 12, line 9 skipping to change at page 12, line 9
When a CCNinfo user transmits the Request message, it MUST insert the When a CCNinfo user transmits the Request message, it MUST insert the
Request block TLV (Figure 8) and the Report block TLV (Figure 11) of Request block TLV (Figure 8) and the Report block TLV (Figure 11) of
its own to the Request message before sending it through the Incoming its own to the Request message before sending it through the Incoming
face(s). 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
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_DISC_REQ | Length | | T_DISC_REQ | Length |
+---------------+---------------+---------------+---------+-+-+-+ +---------------+---------------+----+----------+---------+-+-+-+
| Request ID | SkipHopCount | Flags |F|O|C| | Request ID |SHC | Flags |F|O|C|
+---------------+---------------+---------------+---------+-+-+-+ +---------------+---------------+----+----------+---------+-+-+-+
| Request Arrival Time | | Request Arrival Time |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Node Identifier / / Node Identifier /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 8: Request block TLV (hop-by-hop header) Figure 8: Request block TLV (hop-by-hop header)
Code Type name Code Type name
============= ========================= ============= =========================
%x0000 Reserved [1] %x0000 Reserved [1]
skipping to change at page 12, line 49 skipping to change at page 12, line 49
Length: 16 bits Length: 16 bits
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 this CCNinfo Request This field is used as a unique identifier for this CCNinfo Request
so that duplicate or delayed Reply messages can be detected. so that duplicate or delayed Reply messages can be detected.
SkipHopCount: 8 bits SHC (Skip Hop Count): 4 bits
Number of skipped routers for a Request. This value MUST be lower Number of skipped routers for a Request. This value MUST be lower
than the value of HopLimit at the fixed header. than the value of HopLimit at the fixed header.
Flags: 16 bits Flags: 12 bits
Flags field is used to indicate the types of the content or path Flags field is used to indicate the types of the content or path
discoveries. Currently, as shown in Figure 10, three bits, "C", discoveries. Currently, as shown in Figure 10, three bits, "C",
"O", and "F", are assigned, and the other 5 bits are reserved "O", and "F", are assigned, and the other 9 bits are reserved
(MBZ) for the future use. These flags are set by CCNinfo users (MBZ) for the future use. These flags are set by CCNinfo users
when they initiate Requests (see Appendix A), and routers that when they initiate Requests (see Appendix A), and routers that
receive the Requests deal with the flags and change the behaviors receive the Requests deal with the flags and change the behaviors
(see Section 5 for details). (see Section 5 for details). Flag values defined in this Flags
field will match corresponding Reply sub-blocks.
Flag Value Description Flag Value Description
----- ----- ---------------------------------------------------- ----- ----- ----------------------------------------------------
C 0 Path discovery (i.e., no cache information retried) C 0 Path discovery (i.e., no cache information retried)
C 1 Cache information retrieval (default) C 1 Cache information retrieval (default)
O 0 Request to any content forwarder (default) O 0 Request to any content forwarder (default)
O 1 Publisher reachability (i.e., only FHR can reply) O 1 Publisher reachability (i.e., only FHR can reply).
Type of Reply sub-block will be T_DISC_CONTENT_OWNER
F 0 Request based on FIB's strategy (default) F 0 Request based on FIB's strategy (default)
F 1 Full discovery request. Request to multiple upstream F 1 Full discovery request. Request to multiple upstream
routers simultaneously routers simultaneously
Figure 10: Codes and types specified in Flags field Figure 10: Codes and types specified in Flags field
3.1.2. Report Block 3.1.2. Report Block
A CCNinfo user and each upstream router along the path would insert A CCNinfo user and each upstream router along the path would insert
its own Report block TLV without changing the Type field of the fixed its own Report block TLV without changing the Type field of the fixed
skipping to change at page 15, line 28 skipping to change at page 15, line 28
/ . / / . /
/ . / / . /
/ n Report block TLVs / / n Report block TLVs /
/ . / / . /
/ . / / . /
+===============+===============+===============+===============+ +===============+===============+===============+===============+
| T_DISCOVERY | MessageLength | | T_DISCOVERY | MessageLength |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_NAME | Length | | T_NAME | Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Name segment TLVs (name prefix specified by ccninfo command) / / Name segment TLVs (name prefix specified by ccninfo command) /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Reply block TLV / / Reply block TLV /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Reply sub-block TLV 1 / / Reply sub-block TLV 1 /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ Reply sub-block TLV 2 / / Reply sub-block TLV 2 /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ . / / . /
/ . / / . /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
skipping to change at page 18, line 11 skipping to change at page 18, line 11
cache information is replied from a caching router. cache information is replied from a caching router.
T_DISC_CONTENT_OWNER is specified when the content information is T_DISC_CONTENT_OWNER is specified when the content information is
replied from a FHR attached to a publisher. replied from a FHR attached to a publisher.
Length: 16 bits Length: 16 bits
Length of Value field in octets. Length of Value field in octets.
Object Size: 32 bits Object Size: 32 bits
The total size (byte) of the (cached) content objects. Note that The total size (KB) of the unexpired content objects. Note that
the maximum size expressed by 32 bit field is about 4.29 GB. This the maximum size expressed by 32 bit field is about 4.29 TB. This
value MAY be null when FHR sends the Reply message. value MAY be null because the router may not know the value or
cannot report the value due to its policy. If the cache is
refreshed after reboot, the counter MUST be refreshed (i.e., MUST
set to 0). If the cache remains after reboot, the counter MUST
NOT be refreshed (i.e., MUST kept as is).
Object Count: 32 bits Object Count: 32 bits
The number of the (cached) content objects. Note that the maximum The number of the unexpired content objects. Note that the
count expressed by 32 bit field is about 4.29 billion. This value maximum count expressed by 32 bit field is about 4.29 billion.
MAY be null when FHR sends the Reply message. This value MAY be null because the router may not know the value
or cannot report the value due to its policy. If the cache is
refreshed after reboot, the counter MUST be refreshed (i.e., MUST
set to 0). If the cache remains after reboot, the counter MUST
NOT be refreshed (i.e., MUST kept as is).
# Received Interest: 32 bits # Received Interest: 32 bits
The total number of the received Interest messages to retrieve the The total number of the received Interest messages to retrieve the
cached content objects. cached content objects.
First Seqnum: 32 bits First Seqnum: 32 bits
The first sequential number of the (cached) content objects. This The first sequential number of the unexpired content objects.
value MAY be null if the router does not know or cannot report. This value MAY be null because the router may not know the value
or cannot report the value due to its policy.
Last Seqnum: 32 bits Last Seqnum: 32 bits
The last sequential number of the (cached) content objects. Above The last sequential number of the unexpired content objects.
First Seqnum and this Last Seqnum do not guarantee the Above First Seqnum and this Last Seqnum do not guarantee the
consecutiveness of the cached content objects. This value MAY be consecutiveness of the cached content objects. This value MAY be
null if the router does not know or cannot report. null because the router may not know the value or cannot report
the value due to its policy.
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. This value MAY be null if the router does not content is cached. This value MAY be null because the router may
know or cannot report. not know the value or cannot report the value due to its policy.
Remain Cache Lifetime: 32 bits Remain Cache Lifetime: 32 bits
The lifetime (seconds) of a content object, which is removed first The lifetime (seconds) of a content object, which is removed first
among the cached content objects. This value MAY be null if the among the cached content objects. This value MAY be null because
router does not know or cannot report. the router may not know the value or cannot report the value due
to its policy.
Specification of the Name TLV (whose type value is T_NAME) and the Specification of the Name TLV (whose type value is T_NAME) and the
Name Segment TLVs are described in [1], and CCNinfo follows that Name Segment TLVs are described in [1], and CCNinfo follows that
specification. CCNinfo also allows to specify the content name specification. CCNinfo also allows to specify the content name
either with a prefix name (such as "ccn:/news/today") or an exact either with a prefix name (such as "ccn:/news/today") or an exact
name (such as "ccn:/news/today/Chunk=10"). When a CCNinfo user name (such as "ccn:/news/today/Chunk=10"). When a CCNinfo user
specifies a prefix name, s/he will obtain the information of the specifies a prefix name, s/he will obtain the summary information of
matched content objects in the content forwarder. On the other hand, the matched content objects in the content forwarder. On the other
when a CCNinfo user specifies an exact name, s/he will obtain only hand, when a CCNinfo user specifies an exact name, s/he will obtain
about the specified content object in the content forwarder. only about the specified content object in the content forwarder.
4. CCNinfo User Behavior 4. CCNinfo User Behavior
4.1. Sending CCNinfo Request 4.1. Sending CCNinfo Request
The CCNinfo user's program (e.g., ccninfo command) enables user to The CCNinfo user's program (e.g., ccninfo command) enables user to
obtain both the routing path information and in-network cache obtain both the routing path information and in-network cache
information in a same time. information in a same time.
A CCNinfo user initiates a CCNinfo Request by sending the Request A CCNinfo user initiates a CCNinfo Request by sending the Request
skipping to change at page 21, line 8 skipping to change at page 21, line 18
Upon receiving a CCNinfo Request message, a router MAY examine Upon receiving a CCNinfo Request message, a router MAY examine
whether the message comes from a valid CCNinfo user. If the router whether the message comes from a valid CCNinfo user. If the router
recognizes that the Request sender's signature specified in the recognizes that the Request sender's signature specified in the
Request is invalid, it terminates the Request as defined in Request is invalid, it terminates the Request as defined in
Section 6.3. Section 6.3.
Upon receiving a CCNinfo Request/Reply message, a router MAY examine Upon receiving a CCNinfo Request/Reply message, a router MAY examine
whether the message comes from a valid adjacent neighbor node. If whether the message comes from a valid adjacent neighbor node. If
the router recognizes that the Request/Reply sender is invalid, the the router recognizes that the Request/Reply sender is invalid, the
Request/Reply message MUST be silently ignored. See Section 9.8. Request/Reply message MUST be silently ignored. See Section 10.8.
5.2. Receiving CCNinfo Request 5.2. Receiving CCNinfo Request
5.2.1. Normal Processing 5.2.1. Normal Processing
After the CCNinfo Request message verification, the router performs After the CCNinfo Request message verification, the router performs
the following steps. the following steps.
1. The value of the "HopLimit" in the fixed header and the value of 1. The value of the "HopLimit" in the fixed header and the value of
the "SkipHopCount" in the Request block are counters that are the "SkipHopCount" in the Request block are counters that are
skipping to change at page 22, line 48 skipping to change at page 23, line 8
discover all potential forwarding paths based on routers' FIBs. The discover all potential forwarding paths based on routers' FIBs. The
"full discovery request" enables this function. If a CCNinfo user "full discovery request" enables this function. If a CCNinfo user
sets the F flag in the Request block of the Request message (as seen sets the F flag in the Request block of the Request message (as seen
in Figure 10) to request the full discovery, the upstream routers in Figure 10) to request the full discovery, the upstream routers
forward the Requests to the all multiple upstream routers based on forward the Requests to the all multiple upstream routers based on
the FIBs simultaneously. Then the CCNinfo user could trace the all the FIBs simultaneously. Then the CCNinfo user could trace the all
potential forwarding paths. Note that some routers MAY ignore the potential forwarding paths. Note that some routers MAY ignore the
full discovery request according to their policy. In that case, the full discovery request according to their policy. In that case, the
router terminates the Request as defined in Section 6.10. router terminates the Request as defined in Section 6.10.
When the Request messages forwarded to multiple routers, the When a CCNinfo user sets the F flag in the Request block of the
different Reply messages will be forwarded from different routers or Request message to request the full discovery, to receive the
publisher. To support this case, PIT entries initiated by CCNinfo different Reply messages forwarded from different routers, PIT
remain until the configured CCNinfo Reply Timeout (Section 7.1) entries initiated by CCNinfo remain until the configured CCNinfo
passes. In other words, unlike the ordinary Interest-Data Reply Timeout (Section 7.1) passes. In other words, unlike the
communications in CCN, the router SHOULD NOT remove the PIT entry ordinary Interest-Data communications in CCN, if the router accepts
created by the CCNinfo Request until the timeout value expires. the fill discovery request, the router SHOULD NOT remove the PIT
entry created by the CCNinfo Request until the timeout value expires.
CCNinfo Requests SHOULD NOT result in PIT aggregation in routers CCNinfo Requests SHOULD NOT result in PIT aggregation in routers
during the Request message transmission. during the Request message transmission. On the other hand, CCNinfo
Requests MAY result rate limit as described in Section 10.6. The
router behavior looks similar but it is not PIT aggregation.
5.4. Sending CCNinfo Reply 5.4. Sending CCNinfo Reply
When a router decides to send a Reply message to its downstream When a router decides to send a Reply message to its downstream
neighbor router or the CCNinfo user with NO_ERROR return code, it neighbor router or the CCNinfo user with NO_ERROR return code, it
inserts a Report block having the Request Arrival Time and Node inserts a Report block having the Request Arrival Time and Node
Identifier to the hop-by-hop TLV header of the Request message. And Identifier to the hop-by-hop TLV header of the Request message. And
then the router inserts the corresponding Reply block with an then the router inserts the corresponding Reply block with an
appropriate type value (Figure 15) and Reply sub-block(s) to the appropriate type value (Figure 15) and Reply sub-block(s) to the
payload. The router does not insert any Reply block/sub-block if payload. The router does not insert any Reply block/sub-block if
skipping to change at page 24, line 10 skipping to change at page 24, line 21
PIT entry is removed. PIT entry is removed.
CCNinfo Replies MUST NOT be cached in routers upon the Reply message CCNinfo Replies MUST NOT be cached in routers upon the Reply message
transmission. transmission.
6. CCNinfo Termination 6. CCNinfo Termination
When performing an expanding hop-by-hop trace, it is necessary to When performing an expanding hop-by-hop trace, it is necessary to
determine when to stop expanding. There are several cases an determine when to stop expanding. There are several cases an
intermediate router might return a Reply before a Request reaches the intermediate router might return a Reply before a Request reaches the
caching router or the publisher. caching router or the FHR as described in Section 3.2.
6.1. Arriving at First-hop router 6.1. Arriving at First-hop router
A CCNinfo Request can be determined to have arrived at the first-hop A CCNinfo Request can be determined to have arrived at the first-hop
router. router.
6.2. Arriving at Router Having Cache 6.2. Arriving at Router Having Cache
A CCNinfo Request can be determined to have arrived at the router A CCNinfo Request can be determined to have arrived at the router
having the specified content cache within the specified HopLimit. having the specified content cache within the specified HopLimit.
6.3. Invalid Request 6.3. Invalid Request
If the router does not accept the Request, the router MUST note a If the router does not validate the Request, the router MUST note a
ReturnCode of INVALID_REQUEST in the fixed header of the message and ReturnCode of INVALID_REQUEST in the fixed header of the message and
forward the message without appending any Reply (sub-)block TLV as forward the message without appending any Reply (sub-)block TLV as
the Reply back to the CCNinfo user. The router MAY, however, the Reply back to the CCNinfo user. The router MAY, however,
randomly ignore the received invalid messages. (See Section 9.6.) randomly ignore the received invalid messages. (See Section 10.6.)
6.4. No Route 6.4. 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, the for the specified name prefix within the specified HopLimit, the
router MUST note a ReturnCode of NO_ROUTE in the fixed header of the router MUST note a ReturnCode of NO_ROUTE in the fixed header of the
message and forward the message as the Reply back to the CCNinfo message and forward the message as the Reply back to the CCNinfo
user. user.
6.5. No Information 6.5. No Information
If the router does not have any information about the specified name If the router does not have any information about the specified name
prefix within the specified HopLimit, the router MUST note a prefix within the specified HopLimit, the router MUST note a
ReturnCode of NO_INFO in the fixed header of the message and forward ReturnCode of NO_INFO in the fixed header of the message and forward
the message as the Reply back to the CCNinfo user. the message as the Reply back to the CCNinfo user.
6.6. No Space 6.6. No Space
If appending the Report block would exceed the maximum (i.e., 255 If appending the Report block would make the Request packet longer
byte) header length or make the CCNinfo Request message longer than than the MTU of the Incoming face, or longer than 1280 bytes (in the
the MTU of the Incoming face or longer than 1280 bytes (especially in case of IPv6 as the payload [5]), the router MUST note a ReturnCode
the situation supporting IPv6 as the payload [4]), the router MUST of NO_SPACE in the fixed header of the message and forward the
note a ReturnCode of NO_SPACE in the fixed header of the message and message as the Reply back to the CCNinfo user.
forward the message as the Reply back to the CCNinfo user.
6.7. Fatal Error 6.7. Fatal Error
A CCNinfo Request has encountered a fatal error if the last If a CCNinfo Request has encountered a fatal error, the router MUST
ReturnCode in the trace has the 0x80 bit set (see Section 3.1). 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.
6.8. CCNinfo Reply Timeout 6.8. CCNinfo Reply Timeout
If a router receives the Request or Reply message that expires its If a router receives the Request or Reply message that expires its
own [CCNinfo Reply Timeout] value (Section 7.1), the router will own [CCNinfo Reply Timeout] value (Section 7.1), the router will
silently discard the Request or Reply message. silently discard the Request or Reply message.
6.9. Non-Supported Node 6.9. Non-Supported Node
Cases will arise in which a router or a publisher along the path does Cases will arise in which a router or a FHR along the path does not
not support CCNinfo. In such cases, a CCNinfo user and routers that support CCNinfo. In such cases, a CCNinfo user and routers that
forward the CCNinfo Request will time out the CCNinfo request. forward the CCNinfo Request will time out the CCNinfo request.
6.10. Administratively Prohibited 6.10. Administratively Prohibited
If CCNinfo is administratively prohibited, the router rejects the If CCNinfo is administratively prohibited, the router rejects the
Request message and MUST reply the CCNinfo Reply with the ReturnCode Request message and MUST reply the CCNinfo Reply with the ReturnCode
of ADMIN_PROHIB. The router MAY, however, randomly ignore the of ADMIN_PROHIB. The router MAY, however, randomly ignore the
rejected messages. (See Section 9.6.) Request messages to be rejected. (See Section 10.6.)
7. Configurations 7. Configurations
7.1. CCNinfo Reply Timeout 7.1. CCNinfo Reply Timeout
The [CCNinfo Reply Timeout] value is used to time out a CCNinfo The [CCNinfo Reply Timeout] value is used to time out a CCNinfo
Reply. The value for a router can be statically configured by the Reply. The value for a router can be statically configured by the
router's administrators/operators. The default value is 4 (seconds). router's administrators/operators. The default value is 3 (seconds).
The [CCNinfo Reply Timeout] value SHOULD NOT be larger than 5
The [CCNinfo Reply Timeout] value SHOULD NOT be larger than 4
(seconds) and SHOULD NOT be lower than 2 (seconds). (seconds) and SHOULD NOT be lower than 2 (seconds).
7.2. HopLimit in Fixed Header 7.2. HopLimit in Fixed Header
If a CCNinfo user does not specify the HopLimit value in a fixed If a CCNinfo user does not specify the HopLimit value in a fixed
header for a Request message as the HopLimit, the HopLimit is set to header for a Request message as the HopLimit, the HopLimit is set to
32. Note that 0 HopLimit is an invalid Request; hence the router in 32. Note that 0 HopLimit is an invalid Request; hence the router in
this case follows the way defined in Section 6.3. this case follows the way defined in Section 6.3.
7.3. Access Control 7.3. Access Control
A router MAY configure the valid or invalid networks to enable an A router MAY configure the valid or invalid networks to enable an
access control. The access control can be defined per name prefix, access control. The access control can be defined per name prefix,
such as "who can retrieve which name prefix". See Section 9.2. such as "who can retrieve which name prefix". See Section 10.2.
8. Diagnosis and Analysis 8. Diagnosis and Analysis
8.1. Number of Hops 8.1. Number of Hops
A CCNinfo Request message is forwarded in a hop-by-hop manner and A CCNinfo Request message is forwarded in a hop-by-hop manner and
each forwarding router appended its own Report block. We can then each forwarding router appended its own Report block. We can then
verify the number of hops to reach the content forwarder or the verify the number of hops to reach the content forwarder or the
publisher. publisher.
8.2. Caching Router Identification 8.2. Caching Router Identification
It is possible to identify the routers in the path from the CCNinfo It is possible to identify the routers in the path from the CCNinfo
user to the content forwarder, while some routers may hide their user to the content forwarder, while some routers may hide their
identifier (e.g., IP address) with all-zeros in the Report blocks identifier (e.g., IP address) with all-zeros in the Report blocks
(Section 9.1). (Section 10.1).
8.3. TTL or Hop Limit 8.3. TTL or Hop Limit
By taking the HopLimit from the content forwarder and forwarding TTL By taking the HopLimit from the content forwarder and forwarding TTL
threshold over all hops, it is possible to discover the TTL or hop threshold over all hops, it is possible to discover the TTL or hop
limit required for the content forwarder to reach the CCNinfo user. limit required for the content forwarder to reach the CCNinfo user.
8.4. Time Delay 8.4. Time Delay
If the routers have synchronized clocks, it is possible to estimate If the routers have synchronized clocks, it is possible to estimate
skipping to change at page 27, line 5 skipping to change at page 27, line 20
as different caching and routing algorithms. We can then facilitate as different caching and routing algorithms. We can then facilitate
investigation of the performance of the protocol. investigation of the performance of the protocol.
8.6. Cache Hit Probability 8.6. Cache Hit Probability
CCNinfo can show the number of received interests per cache or chunk CCNinfo can show the number of received interests per cache or chunk
on a router. By this, CCNinfo measures the content popularity (i.e., on a router. By this, CCNinfo measures the content popularity (i.e.,
the number of accesses for each content/cache), and you can the number of accesses for each content/cache), and you can
investigate the routing/caching strategy in networks. investigate the routing/caching strategy in networks.
9. Security Considerations 9. IANA Considerations
New assignments can only be made via a Standards Action as specified
in [4]. The current document does not intend to be the standard
document. However, the new assignments such as ReturnCode and
various type values will be considered when this specification
becomes the RFC.
10. Security Considerations
This section addresses some of the security considerations. This section addresses some of the security considerations.
9.1. Policy-Based Information Provisioning for Request 10.1. Policy-Based Information Provisioning for Request
Although CCNinfo gives excellent troubleshooting cues, some network Although CCNinfo gives excellent troubleshooting cues, some network
administrators or operators may not want to disclose everything about administrators or operators may not want to disclose everything about
their network to the public, or may wish to securely transmit private their network to the public, or may wish to securely transmit private
information to specific members of their networks. CCNinfo provides information to specific members of their networks. CCNinfo provides
policy-based information provisioning allowing network administrators policy-based information provisioning allowing network administrators
to specify their response policy for each router. to specify their response policy for each router.
The access policy regarding "who is allowed to retrieve" and/or "what The access policy regarding "who is allowed to retrieve" and/or "what
kind of information" can be defined for each router. For the former kind of information" can be defined for each router. For the former
skipping to change at page 27, line 41 skipping to change at page 28, line 15
On the other hand, we entail that each router does not disrupt On the other hand, we entail that each router does not disrupt
forwarding CCNinfo Request and Reply messages. When a Request forwarding CCNinfo Request and Reply messages. When a Request
message is received, the router SHOULD insert Report block if the message is received, the router SHOULD insert Report block if the
ReturnCode is NO_ERROR. Here, according to the policy configuration, ReturnCode is NO_ERROR. Here, according to the policy configuration,
the Node Identifier field in the Report block MAY be null (i.e., all- 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. At zeros), but the Request Arrival Time field SHOULD NOT be null. At
last, the router SHOULD forward the Request message to the upstream last, the router SHOULD forward the Request message to the upstream
router toward the content forwarder if the ReturnCode is kept with router toward the content forwarder if the ReturnCode is kept with
NO_ERROR. NO_ERROR.
9.2. Filtering of CCNinfo Users Located in Invalid Networks 10.2. Filtering of CCNinfo Users Located in Invalid Networks
A router MAY support an access control mechanism to filter out A router MAY support an access control mechanism to filter out
Requests from invalid CCNinfo users. For it, invalid networks (or Requests from invalid CCNinfo users. For it, invalid networks (or
domains) could, for example, be configured via a list of allowed/ domains) could, for example, be configured via a list of allowed/
disallowed networks (as seen in Section 7.3). If a Request is disallowed networks (as seen in Section 7.3). If a Request is
received from the disallowed network (according to the Node received from the disallowed network (according to the Node
Identifier in the Request block), the Request MUST NOT be processed Identifier in the Request block), the Request MUST NOT be processed
and the Reply with the ReturnCode of INFO_HIDDEN may be used to note and the Reply with the ReturnCode of INFO_HIDDEN SHOULD be used to
that. The router MAY, however, perform rate-limited logging of such note that. The router MAY, however, perform rate-limited logging of
events. such events.
9.3. Topology Discovery 10.3. Topology Discovery
CCNinfo can be used to discover actively-used topologies. If a CCNinfo can be used to discover actively-used topologies. If a
network topology is a secret, CCNinfo Requests SHOULD be restricted network topology is a secret, CCNinfo Requests SHOULD be restricted
at the border of the domain, using the ADMIN_PROHIB return code. at the border of the domain, using the ADMIN_PROHIB return code.
9.4. Characteristics of Content 10.4. Characteristics of Content
CCNinfo can be used to discover what publishers are sending to what CCNinfo can be used to discover what publishers are sending to what
kinds of contents. If this information is a secret, CCNinfo Requests kinds of contents. If this information is a secret, CCNinfo Requests
SHOULD be restricted at the border of the domain, using the SHOULD be restricted at the border of the domain, using the
ADMIN_PROHIB return code. ADMIN_PROHIB return code.
9.5. Longer or Shorter CCNinfo Reply Timeout 10.5. Longer or Shorter CCNinfo Reply Timeout
Routers can configure the CCNinfo Reply Timeout (Section 7.1), which Routers can configure the CCNinfo Reply Timeout (Section 7.1), which
is the allowable timeout value to keep the PIT entry. If routers is the allowable timeout value to keep the PIT entry. If routers
configure the longer timeout value, there may be an attractive attack configure the longer timeout value, there may be an attractive attack
vector against PIT memory. Moreover, especially when the full vector against PIT memory. Moreover, especially when the full
discovery request option (Section 5.3) is specified for the CCNinfo discovery request option (Section 5.3) is specified for the CCNinfo
Request, a number of Reply messages may come back and cause a Request, a number of Reply messages may come back and cause a
response storm. (See Section 9.7 for rate limiting to avoid the response storm. (See Section 10.7 for rate limiting to avoid the
storm). In order to avoid DoS attacks, routers may configure the storm). In order to avoid DoS attacks, routers MAY configure the
timeout value, which is shorter than the user-configured CCNinfo timeout value, which is shorter than the user-configured CCNinfo
timeout value. However, if it is too short, the Request may be timed timeout value. However, if it is too short, the Request may be timed
out and the CCNinfo user does not receive the all Replies and only out and the CCNinfo user does not receive the all Replies and only
retrieves the partial path information (i.e., information about part retrieves the partial path information (i.e., information about part
of the tree). of the tree).
There may be the way to allow for incremental exploration (i.e., to There may be the way to allow for incremental exploration (i.e., to
explore the part of the tree the previous operation did not explore), explore the part of the tree the previous operation did not explore),
whereas discussing such mechanism is out of scope of this document. whereas discussing such mechanism is out of scope of this document.
9.6. Limiting Request Rates 10.6. Limiting Request Rates
A router may limit CCNinfo Requests by ignoring some of the A router may limit CCNinfo Requests by ignoring some of the
consecutive messages. The router MAY randomly ignore the received consecutive messages. The router MAY randomly ignore the received
messages to minimize the processing overhead, i.e., to keep fairness messages to minimize the processing overhead, i.e., to keep fairness
in processing requests, or prevent traffic amplification. No error in processing requests, or prevent traffic amplification. No error
is returned. The rate limit is left to the router's implementation. is returned. The rate limit is left to the router's implementation.
9.7. Limiting Reply Rates 10.7. Limiting Reply Rates
CCNinfo supporting multipath forwarding may result in one Request CCNinfo supporting multipath forwarding may result in one Request
returning multiple Reply messages. In order to prevent abuse, the returning multiple Reply messages. In order to prevent abuse, the
routers in the traced path MAY need to rate-limit the Replies. No routers in the traced path MAY need to rate-limit the Replies. No
error is returned. The rate limit function is left to the router's error is returned. The rate limit function is left to the router's
implementation. implementation.
9.8. Adjacency Verification 10.8. Adjacency Verification
It is assumed that CCNinfo Request and Reply messages are forwarded It is assumed that CCNinfo Request and Reply messages are forwarded
by adjacent neighbor nodes or routers. Defining the secure way to by adjacent neighbor nodes or routers. Defining the secure way to
verify the adjacency cannot rely on the way specified in CCNx message verify the adjacency cannot rely on the way specified in CCNx message
format or semantics, yet specifying the mechanism to validate format or semantics, yet specifying the mechanism to validate
adjacent neighbor routers is out of scope of this document. An adjacent neighbor routers is out of scope of this document. An
adjacency verification mechanism and the corresponding TLV for adjacency verification mechanism and the corresponding TLV for
adjacency verification using hop-by-hop TLV header such as [8] is the adjacency verification using hop-by-hop TLV header such as [9] is the
potential way and will be defined in a separate document. potential way, and the corresponding router behaviors and messages
are defined in [10].
10. Acknowledgements 11. Acknowledgements
The authors would like to thank Spyridon Mastorakis, Ilya Moiseenko, The authors would like to thank Spyridon Mastorakis, Ilya Moiseenko,
David Oran, and Thierry Turletti for their valuable comments and David Oran, and Thierry Turletti for their valuable comments and
suggestions on this document. suggestions on this document.
11. References 12. References
11.1. Normative References 12.1. Normative References
[1] Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV [1] Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV
Format", draft-irtf-icnrg-ccnxmessages-09 (work in Format", draft-irtf-icnrg-ccnxmessages-09 (work in
progress), January 2019. progress), January 2019.
[2] Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", [2] Mosko, M., Solis, I., and C. Wood, "CCNx Semantics",
draft-irtf-icnrg-ccnxsemantics-10 (work in progress), draft-irtf-icnrg-ccnxsemantics-10 (work in progress),
January 2019. January 2019.
[3] Bradner, S., "Key words for use in RFCs to indicate [3] Bradner, S., "Key words for use in RFCs to Indicate
requirement levels", RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [4] 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>.
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 8200, July 2017. (IPv6) Specification", RFC 8200, July 2017.
11.2. Informative References 12.2. Informative References
[5] Asaeda, H., Matsuzono, K., and T. Turletti, "Contrace: A [6] 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.
[6] Malkin, G., "Traceroute Using an IP Option", RFC 1393, [7] Malkin, G., "Traceroute Using an IP Option", RFC 1393,
January 1993. January 1993.
[7] Asaeda, H., Mayer, K., and W. Lee, "Mtrace Version 2: [8] 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.
[8] Li, R., Asaeda, H., and J. Wu, "DCAuth: Data-Centric [9] Li, R., Asaeda, H., and J. Wu, "DCAuth: Data-Centric
Authentication for Secure In-Network Big-Data Retrieval", Authentication for Secure In-Network Big-Data Retrieval",
IEEE Transactions on Network Science and Engineering IEEE Transactions on Network Science and Engineering
(TNSE) , October 2018. (TNSE) , October 2018.
[10] Li, R. and H. Asaeda, "Hop-by-Hop Authentication in
Content-Centric Networking/Named Data Networking", draft-
li-icnrg-hopauth-00 (work in progress), July 2019.
Appendix A. ccninfo Command and Options Appendix A. ccninfo Command and Options
The ccninfo command enables the CCNinfo user to investigate the The ccninfo command enables the CCNinfo user to investigate the
routing path based on the name prefix of the content (e.g., routing path based on the name prefix of the content (e.g.,
ccn:/news/today). The name prefix is mandatory but exclusive ccn:/news/today). The name prefix is mandatory but exclusive
options; that is, only one of them should be used with the ccninfo options; that is, only one of them should be used with the ccninfo
command at once. command at once.
The usage of ccninfo command is as follows: The usage of ccninfo command is as follows:
 End of changes. 65 change blocks. 
114 lines changed or deleted 152 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/