Home

RFC 8793: Information-Centric Networking (ICN): Content-Centric Networking (CCNx) and Named Data Networking (NDN) Terminology

B. Wissingh,
C. Wood,
A. Afanasyev,
L. Zhang,
D. Oran,
C. Tschudin

Informational

Abstract

Information-Centric Networking (ICN) is a novel paradigm where network communications are accomplished by requesting named content instead of sending packets to destination addresses. Named Data Networking (NDN) and Content-Centric Networking (CCNx) are two prominent ICN architectures. This document provides an overview of the terminology and definitions that have been used in describing concepts in these two implementations of ICN. While there are other ICN architectures, they are not part of the NDN and CCNx concepts and as such are out of scope for this document. This document is a product of the Information-Centric Networking Research Group (ICNRG).¶

Status of This Memo

This document is not an Internet Standards Track specification; it is published for informational purposes.¶

This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Information-Centric Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8793.¶

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

1. Introduction

Information-centric networking (ICN) is an architecture to evolve the Internet infrastructure from the existing host-centric design to a data-centric architecture, where accessing data by name becomes the essential network primitive. The goal is to let applications refer to data independently of their location or means of transportation, which enables native multicast delivery, ubiquitous in-network caching, and replication of data objects.¶

As the work on this topic continues to evolve, many new terms are emerging. The goal of this document is to collect the key terms with a corresponding definition as they are used in the CCNx and NDN projects. Among the important documents for these projects are [RFC8569], [RFC8609], and [NDNTLV]. Other ICN projects such as [NETINF], [PSIRP], or [MOBILITY-FIRST] are not covered and may be the subject of other documents.¶

In this document, to help provide context for the individual defined terms, we first sketch the bigger picture of an ICN network by introducing the basic concepts and identifying the major components of the architecture in Section 2; after which, in Section 3, ICN-related terms are listed by different categories. Readers should be aware that in this organization, some terms may be used in other definitions before they themselves are defined.¶

While this terminology document describes both confidentiality and integrity-related terms, it should be noted that ICN architectures like NDN and CCNx generally do not provide data confidentiality, which is treated in these architectures as an application-layer concern.¶

This document represents the consensus of the Information-Centric Networking Research Group (ICNRG). It has been reviewed extensively by the Research Group (RG) members active in the specific areas of work covered by the document. It is not an IETF product and is not intended for standardization in the IETF.¶

2. A Sketch of the Big Picture of ICN

In networking terms, an ICN is a delivery infrastructure for named data. For other complementing views, see Section 4.¶

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

Figure 1: Request-Reply Protocol of ICN Networking.

The following list describes the basic ICN concepts needed to discuss the implementation of this service abstraction.¶

Request-Reply Protocol (Interest and Data Packet):¶

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

Packet and Content Names:¶

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

Data Authenticity and Encryption:¶

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

Trust:¶

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

Segmenting and Versioning:¶

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

Packet and Frame:¶

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

ICN Node:¶

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

Forwarding Plane:¶

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

3. Terms by Category

3.1. Generic Terms

Information-Centric Networking (ICN):¶

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

Data Packet Immutability:¶

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

4. Semantics and Usage

The terminology described above is the manifestation of intended semantics of NDN and CCNx operations (What do we expect the network to do?). In this section, we summarize the most commonly proposed use cases and interpretations.¶

4.1. Data Transfer

The networking view of NDN and CCNx is that the request/reply protocol implements a basic, unreliable data transfer service for single, named packets.¶

4.2. Data Transport

Data transfer can be turned into a data transport service for application-level objects by additional logic. This transport logic must understand and construct the series of names needed to reassemble the segmented object. Various flavors of transport can be envisaged (reliable, streaming, mailbox, etc.).¶

4.3. Lookup Service

In a more distributed systems view of the basic request/reply protocol, NDN and CCNx provide a distributed lookup service: given a key value (=name), the service will return the corresponding value.¶

4.4. Database Access

A lookup service can be turned into a database access protocol by using the namespace structure to specify names as access keys into a database. Therefore, a name prefix stands for a collection or table of a database, while the rest of the name specifies the query expression to be executed.¶

4.5. Remote Procedure Call

The names as defined in this document for Interests and Data can refer to Remote Procedure call functions, their input arguments, and their results. For a comprehensive view of how to construct RPC or other remote invocation systems, see the Association for Computing Machinery (ACM) ICN paper on [RICE]. These capabilities can be further extended into a full distributed computing infrastructure such as that proposed in the ACM ICN paper [CFN].¶

5. IANA Considerations

This document has no IANA actions.¶

6. Security Considerations

While the terms defined in this specification do not in and of themselves present new security considerations, the architectures that utilize the terms most certainly do. Readers should look at those specifications (e.g., [RFC8569] and [NDN]) where various security considerations are addressed in detail.¶

Some of the terms in this document use the words "trust", "trustworthy", or "trust model". We intend that these have their colloquial meanings; however, much work on trust, and specifically on trust schemas for ICN architectures, has been published in the last few years. For example, it is useful to look at [SCHEMATIZING-TRUST] for more information on the approaches taken to formalize notions of trust for current NDN and CCNx systems.¶

7. References

7.1. Normative References

[CFN]: Krol, M., Mastorakis, S., Kutscher, D., and D. Oran, "Compute First Networking: Distributed Computing meets ICN", ACM ICN , DOI 10.1145/3357150.3357395, September 2019, <https://dl.acm.org/citation.cfm?id=3357395>.
[LESSONS-LEARNED]: Nichols, K., "Lessons Learned Building a Secure Network Measurement Framework using Basic NDN", ACM ICN , DOI 10.1145/3357150.3357397, September 2019, <https://dl.acm.org/citation.cfm?id=3357397>.
[MOBILITY-FIRST]: Raychaudhuri, D., Nagaraja, K., and A. Venkataramani, "MobilityFirst: a robust and trustworthy mobility-centric architecture for the future internet", ACM SIGMOBILE , Volume 16, Issue 3 , 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]: Dannewitz, C., Kutscher, D., Ohlman, B., Farrell, S., Ahlgren, B., and K. Holger, "Network of Information (NetInf) - An information-centric networking architecture", Computer Communications , Volume 36, Issue 7 , DOI 10.1016/j.comcom.2013.01.009, April 2013, <https://dl.acm.org/citation.cfm?id=2459643>.
[PSIRP]: Trossen, D., Tuononen, J., Xylomenos, G., Sarela, M., Zahemszky, A., Nikander, P., 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]: Krol, M., Habak, K., Kutscher, D., Oran, D., and I. Psaras, "RICE: remote method invocation in ICN", ACM ICN , DOI 10.1145/3267955.3267956, September 2018, <https://dx.doi.org/10.1145/3267955.3267956>.
[SCHEMATIZING-TRUST]: Yu, Y., Afanasyev, A., Clark, D., Claffy, K. C., Jacobson, V., and L. Zhang, "Schematizing Trust in Named Data Networking", ACM ICN , DOI 0.1145/2810156.2810170, September 2015, <https://dx.doi.org/10.1145/2810156.2810170>.

7.2. Informative References

[NDN]: Named Data Networking, "Named Data Networking: Executive Summary", September 2010, <https://named-data.net/project/execsummary/>.
[RFC4838]: Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, April 2007, <https://www.rfc-editor.org/info/rfc4838>.
[RFC4949]: Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <https://www.rfc-editor.org/info/rfc4949>.
[RFC6234]: Eastlake 3rd, D. 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]: Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, July 2019, <https://www.rfc-editor.org/info/rfc8569>.
[RFC8609]: Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Messages in TLV Format", RFC 8609, DOI 10.17487/RFC8609, July 2019, <https://www.rfc-editor.org/info/rfc8609>.

Acknowledgments

Marc Mosko provided much guidance and helpful precision in getting these terms carefully formed and the definitions precise. Marie-Jose Montpetit did a thorough IRSG review, which helped a lot to improve the text. Further comments during the IRSG Poll from Stephen Farrell, Ari Keraenen, Spencer Dawkins, Carsten Bormann, and Brian Trammell further improved the document. Additional helpful comments were received as part of the IESG conflict review from Mirja Kuehlewind and Benjamin Kaduk.¶