requestor         zero or more           data sources or
(node)          forwarding nodes         replica nodes
  |                 | ... |                  |...|
  |   Interest(n)   |     |   Interest(n)    |   |
  | --------------> |     | ---------------> |   |
  |                 |     | -------------------> |
  |                 |     |                  |   |
  |                 |     |  Data([n],c,[s]) |   |
  |                 |     | <--------------- |   |
  |                 |     | <------------------- |
  | Data([n],c,[s]) |     |                  |   |
  | <-------------- |     |                  |   |

      Legend: n=name, c=content, s=signature

• An ICN's lookup service is implemented by defining two types of network packet formats: Interest packets that request content by name and Data packets that carry the requested content. The returned Data packet must match the request's parameters (e.g., having a partially or fully matching name). If the request is ambiguous and several Data packets would satisfy the request, the ICN network returns only one matching Data packet (thus achieving flow balance between Interest and Data packets over individual Layer 2 interfaces).

• Without a strong cryptographic binding between the name of a Data packet and its content, Data packet names would be useless for fetching specific content. In ICN, verification of a Data packet's name-to-content binding is achieved through cryptographic means either by (1) a cryptographic signature that explicitly binds an application-chosen name to a Data packet's content or by (2) relying on an implicit name (cryptographic hash of the Data packet with or without application-chosen name) that the data consumer obtained through other means.

• Any data consumer or network element can (in principle) validate the authenticity of a Data packet by verifying its cryptographic name-to-content binding. Note that data authenticity is distinct from data trustworthiness, though the two concepts are related. A packet is authentic if it has a valid name-to-content binding, but it may still be unwise to "trust" the content for any particular purpose.

• Data authenticity is distinct from data trustworthiness, though the two concepts are related. A packet is authentic if it has a valid name-to-content binding. A packet is trustworthy, i.e., it comes from a reputable or trusted origin, if this binding is valid in the context of a trust model. The trust model provides assurance that the name used for a given piece of content is appropriate for the value of the content. Section 6 discusses this further.

• An ICN network will be engineered for some packet size limit. As application-level data objects will often be considerably larger, objects must be segmented into multiple Data packets. The names for these Data packets can, for example, be constructed by choosing one application-level object name to which a different suffix is added for each segment. The same method can be used to handle different versions of an application-level object by including a version number in the name of the overall object.

• NDN and CCNx introduce Protocol Data Units (PDUs), which typically are larger than the maximum transmission unit of the underlying networking technology. We refer to PDUs as packets and the (potentially fragmented) packet parts that traverse MTU-bound Layer 2 interfaces as frames. Handling Layer 2 technologies that lead to fragmentation of ICN packets is done inside the ICN network and is not visible at the service interface.

• A node within an ICN network can fulfill the role of a data producer, a data consumer, and/or a forwarder for Interest and Data packets. When a forwarder has connectivity to neighbor nodes, it performs Interest and Data packet forwarding in real time. It can also behave as a store and forward node carrying an Interest or Data packet for some time before forwarding it to the next node. An ICN node may also run routing protocols to assist its Interest forwarding decisions.

• The canonical way of implementing packet forwarding in an ICN network relies on three data structures that capture a node's state: a Forwarding Interest Base (FIB), a Pending Interest Table (PIT), and a Content Store (CS). It also utilizes Interest forwarding strategies, which take input from both FIB and measurements to make Interest forwarding decisions. When a node receives an Interest packet, it checks its CS and PIT to find a matching entry; if no match is found, the node records the Interest in its PIT and forwards the Interest to the next hop(s) towards the requested content, based on the information in its FIB.

• A networking architecture that retrieves Data packets in response to Interest packets. Content-Centric Networking (CCNx 1.x) and Named Data Networking (NDN) are two realizations (designs) of an ICN architecture.

• After a Data packet is created, the cryptographic signature binding the name to the content ensures that if either the content or the name changes, that change will be detected and the packet discarded. If the content carried in a Data packet is intended to be mutable, versioning of the name should be used so that each version uniquely identifies an immutable instance of the content. This allows disambiguation of various versions of content such that coordination among the various instances in a distributed system can be achieved.

• A generalization of the network interface that can represent a physical network interface (ethernet, Wi-Fi, bluetooth adapter, etc.), an overlay inter-node channel (IP/UDP tunnel, etc.), or an intra-node inter-process communication (IPC) channel to an application (unix socket, shared memory, intents, etc.).

• • Common aliases include: face.

• An ICN entity that requests Data packets by generating and sending out Interest packets towards local (using intra-node interfaces) or remote (using inter-node interfaces) ICN Forwarders.

• • Common aliases include: consumer, information consumer, data consumer, consumer of the content.

• An ICN entity that creates Data packets and makes them available for retrieval.

• • Common aliases include: producer, publisher, information publisher, data publisher, data producer.

• An ICN entity that implements stateful forwarding.

• • Common aliases include: ICN router.

• An ICN entity that temporarily stores and potentially carries an Interest or Data packet before forwarding it to next ICN entity. Note that such ICN data nodes do not have all the properties of data nodes as employed in the Delay Tolerant Networking (DTN) [RFC 4838] specifications.

• A forwarding process that records incoming Interest packets in the PIT and uses the recorded information to forward the retrieved Data packets back to the consumer(s). The recorded information can also be used to measure data-plane performance, e.g., to adjust interest forwarding-strategy decisions.

• • Common aliases include: ICN Data plane, ICN Forwarding.

• A module of the ICN stateful forwarding (ICN data) plane that implements a decision on where/how to forward the incoming Interest packet. The forwarding strategy can take input from the Forwarding Information Base (FIB), measured data-plane performance parameters, and/or use other mechanisms to make the decision.

• • Common aliases include: Interest forwarding strategy.

• Forwarding packets in the direction of Interests (i.e., Interests are forwarded upstream): consumer, router, router, ..., producer.

• Forwarding packets in the opposite direction of Interest forwarding (i.e., Data and Interest Nacks are forwarded downstream): producer, router, ..., consumer(s).

• A process of forwarding Interest packets using the Names carried in the Interests. In case of stateful forwarding, this also involves creating an entry in the PIT. The forwarding decision is made by the Forwarding Strategy.

• A process of combining multiple Interest packets with the same Name and additional restrictions for the same Data into a single PIT entry.

• • Common aliases include: Interest collapsing.

• A process of forwarding the incoming Data packet to the interface(s) recorded in the corresponding PIT entry (entries) and removing the corresponding PIT entry (entries).

• An overall process of returning content that satisfies the constraints imposed by the Interest, most notably a match in the provided Name.

• A process of finding a FIB entry with the longest Name (in terms of Name components) that is a prefix of the specified Name. See Section 3.5 for terms related to name prefixes.

• A process of finding a PIT entry that stores the same Name as specified in the Interest (including Interest restrictions, if any).

• A process of finding (a set of) PIT entries that can be satisfied with the specified Data packet.

• A process of finding an entry in a router's Content Store that can satisfy the specified Interest.

• A database that records received and not-yet-satisfied Interests with the interfaces from where they were received. The PIT can also store interfaces to where Interests were forwarded, and information to assess data-plane performance. Interests for the same Data are aggregated into a single PIT entry.

• A database that contains a set of prefixes, each prefix associated with one or more faces that can be used to retrieve Data packets with Names under the corresponding prefix. The list of faces for each prefix can be ranked, and each face may be associated with additional information to facilitate forwarding-strategy decisions.

• A database in an ICN router that provides caching.

• An optional process of storing a Data packet within the network (opportunistic caches, dedicated on/off path caches, and managed in-network storage systems), so it can satisfy an incoming Interest for this Data packet. The in-network storages can optionally advertise the stored Data packets in the routing plane.

• A process of temporarily storing a forwarded Data packet in the router's memory (RAM or disk), so it can be used to satisfy future Interests for the same Data, if any.

• • Common aliases include: on-path in-network caching.

• The process of achieving the temporary, permanent, or scheduled storage of a selected (set of) Data packet(s).

• • Common aliases include: off-path in-network storage.

• An entity acting as an ICN publisher that implements managed caching.

• • Common aliases include: repository, repo.

• An ICN protocol or a set of ICN protocols to exchange information about Name space reachability.

• A database that contains a set of prefix-face mappings that are produced by running one or multiple routing protocols. The RIB is used to populate the FIB.

• A network-level packet that expresses the request for a Data packet using either an exact name or a name prefix. An Interest packet may optionally carry a set of additional restrictions (e.g., Interest selectors). An Interest may be associated with additional information to facilitate forwarding and can include Interest lifetime, hop limit, forwarding hints, labels, etc. In different ICN designs, the set of additional associated information may vary.

• • Common aliases include: Interest, Interest message, information request.

• A packet that contains the Interest packet and optional annotation, which is sent by the ICN router to the interface(s) the Interest was received from. An Interest Nack is used to inform downstream ICN nodes about the inability to forward the included Interest packet. The annotation can describe the reason.

• • Common aliases include: network NACK, Interest return.

• A network-level packet that carries payload, uniquely identified by a name, that is directly secured through cryptographic signature mechanisms.

• • Common aliases include: data, data object, content object, content object packet, data message, named data object, named data.

• A type of Data packet whose body contains the Name of another Data packet. This inner Name is often a Full Name, i.e., it specifies the Packet ID of the corresponding Data packet, but this is not a requirement.

• • Common aliases include: pointer.

• A type of Data packet that contains Full Name Links to one or more Data Packets. Manifests group collections of related Data packets under a single Name. Manifests allow both large Data objects to be conveniently split into individual Content Objects under one name, and to represent sets of related Content Objects as a form of "directory". Manifests have the additional benefit of amortizing the signature verification cost for each Data packet referenced by the inner Links. Manifests typically contain additional metadata, e.g., the size (in bytes) of each linked Data packet and the cryptographic hash digest of all Data contained in the linked Data packets.

• A Data packet identifier. An ICN name is hierarchical (a sequence of name components) and usually is semantically meaningful, making it expressive, flexible, and application-specific (akin to an HTTP URL). A Name may encode information about application context, semantics, locations (topological, geographical, hyperbolic, etc.), a service name, etc.

• • Common aliases include: data name, interest name, content name.

• A sequence of bytes and optionally a numeric type representing a single label in the hierarchical structured name.

• • Common aliases include: name segment (as in CCNx).

• A unique cryptographic identifier for a Data packet. Typically, this is a cryptographic hash digest of a Data packet (such as SHA256 [RFC 6234]), including its name, payload, meta information, and signature.

• • Common aliases include: implicit digest.

• A mechanism (condition) to select an individual Data packet from a collection of Data packets that match a given Interest that requests data using a prefix or exact Name.

• • Common aliases include: interest selector, restrictor, interest restrictor.

• A field of an Interest packet that transiently names an Interest instance (instance of Interest for a given name). Note: the specifications defining nonces in NDN do not necessarily satisfy all the properties of nonces as discussed in [RFC 4949].

• A Name that is encoded inside a Data packet and that typically uniquely identifies this Data packet.

• An exact Name with the Packet ID of the corresponding Data packet.

• A Name that includes a partial sequence of Name components (starting from the first one) of a Name encoded inside a Data packet.

• • Common aliases include: prefix.

• A convention, agreement, or specification for the Data packet naming. a Naming convention structures a namespace.

• • Common aliases include: Naming scheme, ICN naming scheme, namespace convention.

• The naming scheme that assigns and interprets a Name as a sequence of labels (Name components) with hierarchical structure without an assumption of a single administrative root. A structure provides useful context information for the Name.

• • Common aliases include: hierarchical naming, structured naming.

• The naming scheme that assigns and interprets a Name as a single label (Name component) without any internal structure. This can be considered a special (or degenerate) case of structured names.

• A process of splitting large application content into a set of uniquely named Data packets. When using hierarchically structured names, each created Data packet has a common prefix and an additional component representing the segment (chunk) number.

• • Common aliases include: chunking.

• A process of assigning a unique Name to the revision of the content carried in the Data packet. When using a hierarchically structured Name, the version of the Data packet can be carried in a dedicated Name component (e.g., prefix identifies data, unique version component identifies the revision of the data).

• A process of splitting PDUs into Frames so that they can be transmitted over a Layer 2 interface with a smaller MTU size.

• A security property associated with the Data packet, including data (Data-Centric) integrity, authenticity, and optionally confidentiality. These security properties stay with the Data packet regardless of where it is stored and how it is retrieved.

• • Common aliases include: directly securing Data packet.

• A cryptographic mechanism to ensure the consistency of the Data packet bits. The Data integrity property validates that the Data packet content has not been corrupted during transmission, e.g., over lossy or otherwise unreliable paths, or been subject to deliberate modification.

• A cryptographic mechanism to ensure trustworthiness of a Data packet based on a selected (e.g., by a consumer/producer) trust model. Typically, data authenticity is assured through the use of asymmetric cryptographic signatures (e.g., RSA, ECDSA) but can also be realized using symmetric signatures (e.g., Hashed Message Authentication Code (HMAC)) within trusted domains.

• A cryptographic mechanism to ensure secrecy of a Data packet. Data confidentiality includes separate mechanisms: Content confidentiality and Name confidentiality.

• A cryptographic mechanism to prevent an unauthorized party to get access to the plain-text payload of a Data packet. Can be realized through encryption (symmetric, asymmetric, hybrid) and proper distribution of the decryption keys to authorized parties.

• A cryptographic mechanism to prevent an observer of Interest-Data exchanges (e.g., intermediate router) from gaining detailed meta information about the Data packet. This mechanism can be realized using encryption (same as content confidentiality) or obfuscation mechanisms.

[CFN]

M. Krol, S. Mastorakis, D. Kutscher, and D. Oran, "Compute First Networking: Distributed Computing meets ICN", DOI 10.1145/3357150.3357395, September 2019,
<https://dl.acm.org/citation.cfm?id=3357395>.

[LESSONS-LEARNED]

K Nichols, "Lessons Learned Building a Secure Network Measurement Framework using Basic NDN", DOI 10.1145/3357150.3357397, September 2019,
<https://dl.acm.org/citation.cfm?id=3357397>.

[MOBILITY-FIRST]

D. Raychaudhuri, K. Nagaraja, and A. Venkataramani, "MobilityFirst: a robust and trustworthy mobility-centric architecture for the future internet", DOI 10.1145/2412096.2412098, July 2012,
<https://dl.acm.org/citation.cfm?id=2412098>.

[NDNTLV]

Named Data Networking, "NDN Packet Format Specification",
<https://named-data.net/doc/ndn-tlv/>.

[NETINF]

C. Dannewitz, D. Kutscher, B. Ohlman, S. Farrell, B. Ahlgren, and K. Holger, "Network of Information (NetInf) - An information-centric networking architecture", DOI 10.1016/j.comcom.2013.01.009, April 2013,
<https://dl.acm.org/citation.cfm?id=2459643>.

[PSIRP]

D. Trossen, J Tuononen, G. Xylomenos, M. Sarela, A. Zahemszky, P. Nikander, and T. Rinta-aho, "From Design for Tussle to Tussle Networking: PSIRP Vision and Use Cases", May 2008,
<http://www.psirp.org/files/Deliverables/PSIRP-TR08-0001_Vision.pdf>.

[RICE]

M. Krol, K. Habak, D. Kutscher, D. Oran, and I. Psaras, "RICE: remote method invocation in ICN", DOI 10.1145/3267955.3267956, September 2018,
<https://dx.doi.org/10.1145/3267955.3267956>.

[SCHEMATIZING-TRUST]

Y. Yu, A. Afanasyev, D. Clark, K. C. Claffy, V. Jacobson, and L. Zhang, "Schematizing Trust in Named Data Networking", DOI 0.1145/2810156.2810170, September 2015,
<https://dx.doi.org/10.1145/2810156.2810170>.

[NDN]

Named Data Networking, "Named Data Networking: Executive Summary", September 2010,
<https://named-data.net/project/execsummary/>.

[RFC4838]

V. Cerf, S. Burleigh, A. Hooke, L. Torgerson, R. Durst, K. Scott, K. Fall, and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, April 2007,
<https://www.rfc-editor.org/info/rfc4838>.

[RFC4949]

R. Shirey, "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.

[RFC6234]

D. Eastlake 3rd, and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.

[RFC8569]

M. Mosko, I. Solis, and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, July 2019,
<https://www.rfc-editor.org/info/rfc8569>.

[RFC8609]

M. Mosko, I. Solis, and C. Wood, "Content-Centric Networking (CCNx) Messages in TLV Format", RFC 8609, DOI 10.17487/RFC8609, July 2019,
<https://www.rfc-editor.org/info/rfc8609>.

Bastiaan Wissingh

Christopher A. Wood

Alex Afanasyev

Lixia Zhang

David Oran

Christian Tschudin