Movatterモバイル変換


[0]ホーム

URL:


RFC 8793ICN TerminologyJune 2020
Wissingh, et al.Informational[Page]
Stream:
Internet Research Task Force (IRTF)
RFC:
8793
Category:
Informational
Published:
ISSN:
2070-1721
Authors:
B. Wissingh
TNO
C. Wood
University of California Irvine
A. Afanasyev
Florida International University
L. Zhang
UCLA
D. Oran
Network Systems Research & Design
C. Tschudin
University of Basel

RFC 8793

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

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 athttps://www.rfc-editor.org/info/rfc8793.

Copyright Notice

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.

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.

Table of Contents

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 inSection 2; after which, inSection 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, seeSection 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):

Packet and Content Names:

Data Authenticity and Encryption:

Trust:

Segmenting and Versioning:

Packet and Frame:

ICN Node:

Forwarding Plane:

3.Terms by Category

3.1.Generic Terms

Information-Centric Networking (ICN):

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

Data Packet Immutability:

  • After aData 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.

3.2.Terms Related to ICN Nodes

ICN Interface:

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

ICN Consumer:

  • An ICN entity that requestsData packets by generating and sending outInterest 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.

ICN Producer:

  • An ICN entity that createsData packets and makes them available for retrieval.
    • Common aliases include: producer, publisher, information publisher, data publisher, data producer.

ICN Forwarder:

  • An ICN entity that implements stateful forwarding.
    • Common aliases include: ICN router.

ICN Data Node:

  • An ICN entity that temporarily stores and potentially carries an Interest orData 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)[RFC4838] specifications.

3.3.Terms Related to the Forwarding Plane

Stateful Forwarding:

  • A forwarding process that records incomingInterest packets in the PIT and uses the recorded information to forward the retrievedData 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.

Forwarding Strategy:

  • A module of the ICN stateful forwarding (ICN data) plane that implements a decision on where/how to forward the incomingInterest 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.

Upstream (forwarding):

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

Downstream (forwarding):

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

Interest Forwarding:

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

Interest Aggregation:

  • A process of combining multipleInterest packets with the sameName and additional restrictions for the same Data into a single PIT entry.
    • Common aliases include: Interest collapsing.

Data Forwarding:

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

Satisfying an Interest:

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

Interest Match in FIB (longest prefix match):

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

Interest Match in PIT (exact match):

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

Data Match in PIT (all match):

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

Interest Match in CS (any match):

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

Pending Interest Table (PIT):

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

Forwarding Information Base (FIB):

  • A database that contains a set of prefixes, each prefix associated with one or more faces that can be used to retrieveData packets withNames 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.

Content Store (CS):

  • A database in an ICN router that provides caching.

In-Network Storage:

  • An optional process of storing aData 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.

Opportunistic Caching:

  • A process of temporarily storing a forwardedData 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.

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

Managed In-Network Storage:

  • An entity acting as an ICN publisher that implements managed caching.
    • Common aliases include: repository, repo.

ICN Routing Plane:

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

ICN Routing Information Base (RIB):

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

3.4.Terms Related to Packet Types

Interest Packet:

  • A network-level packet that expresses the request for aData 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.

Interest Nack:

  • A packet that contains theInterest 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.

Data Packet:

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

Link:

  • A type ofData packet whose body contains theName of another Data packet. This inner Name is often aFull Name, i.e., it specifies the Packet ID of the corresponding Data packet, but this is not a requirement.
    • Common aliases include: pointer.

Manifest:

  • A type ofData packet that containsFull NameLinks 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 innerLinks. 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.

3.5.Terms Related to Name Types

Name:

  • AData 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.

Name component:

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

Packet ID:

  • A unique cryptographic identifier for aData packet. Typically, this is a cryptographic hash digest of a Data packet (such as SHA256[RFC6234]), including its name, payload, meta information, and signature.
    • Common aliases include: implicit digest.

Selector:

  • A mechanism (condition) to select an individualData packet from a collection of Data packets that match a given Interest that requests data using a prefix or exactName.
    • Common aliases include: interest selector, restrictor, interest restrictor.

Nonce:

  • A field of anInterest 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[RFC4949].

Exact Name:

  • AName that is encoded inside aData packet and that typically uniquely identifies this Data packet.

Full Name:

Prefix Name:

  • AName that includes a partial sequence of Name components (starting from the first one) of a Name encoded inside aData packet.
    • Common aliases include: prefix.

3.6.Terms Related to Name Usage

Naming conventions:

  • A convention, agreement, or specification for theData packet naming. a Naming convention structures a namespace.
    • Common aliases include: Naming scheme, ICN naming scheme, namespace convention.

Hierarchically structured naming:

  • The naming scheme that assigns and interprets aName 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.

Flat naming:

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

Segmentation:

  • A process of splitting large application content into a set of uniquely namedData 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.

Versioning:

  • A process of assigning a uniqueName to the revision of the content carried in theData 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).

Fragmentation:

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

3.7.Terms Related to Data-Centric Security

Data-Centric Security:

  • A security property associated with theData 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.

Data Integrity

  • A cryptographic mechanism to ensure the consistency of theData 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.

Data Authenticity

  • A cryptographic mechanism to ensure trustworthiness of aData 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.

Data Confidentiality

Content Confidentiality

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

Name Confidentiality

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

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

4.6.Publish/Subscribe

The names as defined in this document for Interests and Data can refer to data collections to be subscribed and individual data objects to be published in a Publish-Subscribe application architecture. For a fully worked example of how to construct such an ICN-based system, see the ACM ICN paper[LESSONS-LEARNED].

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,,<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,,<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,,<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,,<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",,<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,,<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,,<https://dx.doi.org/10.1145/2810156.2810170>.

7.2.Informative References

[NDN]
Named Data Networking,"Named Data Networking: Executive Summary",,<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,,<https://www.rfc-editor.org/info/rfc4838>.
[RFC4949]
Shirey, R.,"Internet Security Glossary, Version 2",FYI 36,RFC 4949,DOI 10.17487/RFC4949,,<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,,<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,,<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,,<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 fromStephen Farrell,Ari Keraenen,Spencer Dawkins,Carsten Bormann, andBrian Trammell further improved the document. Additional helpful comments were received as part of the IESG conflict review fromMirja Kuehlewind andBenjamin Kaduk.

Authors' Addresses

Bastiaan Wissingh
TNO
Email:bastiaan.wissingh@tno.nl
Christopher A. Wood
University of California Irvine
Email:caw@heapingbits.net
Alex Afanasyev
Florida International University
Email:aa@cs.fiu.edu
Lixia Zhang
UCLA
Email:lixia@cs.ucla.edu
David Oran
Network Systems Research & Design
Email:daveoran@orandom.net
Christian Tschudin
University of Basel
Email:christian.tschudin@unibas.ch

[8]ページ先頭

©2009-2025 Movatter.jp