Information-Centric Networking (ICN): TerminologyTNObastiaan.wissingh@tno.nlUniversity of California Irvinewoodc1@uci.eduUCLAaa@cs.ucla.eduUCLAlixia@cs.ucla.eduNetwork Systems Research & Designdaveoran@orandom.netUniversity of Baselchristian.tschudin@unibas.ch
General
icnrgInternet-DraftInformation Centric Networking (ICN) is a new 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 (CCN) 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 projects.
While there are other ICN architectures, they are not part of the NDN and CCN
vision and as such are out of scope for this document.Information-centric networking (ICN) is an approach 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 --for immutable data items-- 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 over time. The goal of this document is to provide a thorough
collection of these terms with a corresponding definition as they are
used in the CCNx and NDN projects. Other, historic ICN projects like NetInf, XIA or Mobility First
are not covered and will be the subject of other documents.To help provide context for the individual terms to be defined, in this
draft 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.In networking terms, an ICN is a delivery infrastructure for
named data. For other, complementing views see
.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 ambigious and several data packets
would satisfy the request, the ICN network will typically
return only one matching data packet.Packet and Content Names:Without an irrefutable binding between a
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 explicitely binds an
application-chosen name to a data packet's content, or (2) relying on an
implicit name (cryptographic hash of the data packet) that the data
consumer obtained through other means.Data Authenticity and Encryption:Any data consumer and network element can validate the authenticity of
a data packet by verifying its cryptographic name-to-content binding.
In contrast, whether a data packet's content (payload) itself
is encrypted or not is irrelevant to the ICN network: The use
and management of content encryption keys is an application-layer
concern.
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 only valid
in the context of a trust model. For example, if a corresponding trust infrastructure
(e.g., PKI) is in place, a packet's signature even enables to assess
authenticity with relation to to real world identities which can be trusted
or not.
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 into the name of the overall object.
Packet and Frame:NDN and CCN 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 links as 'frames'. Handling link-layer
technologies which 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 like a packet mule, that is it may carry an interest or data packet for some
time before forwarding it to 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 like NDN and CCN
relies on three data structures that capture a node's state: a Forwarding Interest
Table (FIB), a Pending Interest Table (PIT), and a Content Store (CS). It also utilizes
interest forwarding strategies which takes input from both FIB and measurements to make
interest forwarding decisions. When a node receives an ICN interest packet, it checks
its CS and PIT to find a matching name; 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. There exist alternative approaches which
aim at reducing the amount of state that a nodes must keep, up to fully PIT-less designs
using packets for keeping state but without changing the overall service model.Information-Centric Networking (ICN): a networking architecture that retrieves data packets as response to interest packets.
Content-Centric Networking (CCN) and Named Data Networking (NDN) are two types of ICN architectures.
Data packet: a network-level packet that carries payload, uniquely identified by a name, and is directly secured.
Common aliases include: data, data object, content object, content object packet, data message, named data object, named data.Interest packet: 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 requestData packet immutability: after a data packet is created, it cannot change. If the content carried in the data packet is mutable, versioning should be used, so that each version uniquely identifies an immutable instance of the content. This allows disambiguation of coordination in distributed systems.Name: a data packet identifier. An ICN name is expressive, flexible
and can be application-specific (akin to a HTTP URL). A Name may encode information about application context, semantics,
locations (topological, geographical, hyperbolic, etc.), a service name, etc. A Name is a sequence of non-empty name components (see below).
The components of a name are said to be complete if they uniquely identify a single data packet. A Name is exact if its
components are complete.
Common aliases include: data name, interest name, content name.Name component: a sequence of octets and optionally a numeric type representing a single label in the hierarchical structured name.
Common aliases include: name segment (as in CCN).Packet ID: a unique cryptographic identifier for a data packet. Typically, this is the cryptographic hash digest of a data packet, including its name, payload, meta information, and signature.Full Name: An exact Name with the Packet ID of the corresponding data packet.Prefix Name: A Name with incomplete components.
Common aliases include: prefix.Selector: Depending on the implementation, some restrictors show up as name components or as explicit fields of an interest. Selectors are not
'names' in a proper sense although they are able to "name content." Examples include selectors used to reference nameless objects, specify publisher restriction, etc.
In that sense, a single data packet will have multiple 'name-like properties' through which it can be referenced, interest packets are able to express them.
Common aliases include: restrictor.Nonce: Field of an interest packet that transiently 'names' an interest instance.Naming scheme (ICN naming scheme): a convention/agreement/specification for the data packet naming. Structures a name space.Hierarchically structured naming: the naming scheme that assigns and interprets name as a sequence of labels (name components)
with hierarchical structure. 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 name as a single label (name component) without any internal structure. This can be considered a special (or degenerated) case of structured names. Segmentation: a process of splitting large application content into a set of uniquely named data packets.
When using hierarchically structured name, each created data packet has a common prefix and additional
component representing the segment (chunk) number.
Common aliases include: chunking (as in CCN).Versioning: 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).
Fragmentation: a process of splitting data packets into frames so that they can be
transmitted over the link with a smaller MTU size.Directly secured data packet: a data packet with inherent security properties (authenticity and optionally
confidentiality), i.e., the security properties stay with the data packet regardless where it is
stored and how it is retrieved.Data authenticator: a set of parameters carried in the data packet that is used to verify integrity and authenticity of the data packet.
The Data authenticator can include a cryptographic signature (RSA, ECDSA, HMAC, etc.),
meta information about the signature (e.g., validity period), and additional information to facilitate signature verification
(e.g., key locator, key ID, HMAC tag identifier, etc.)
Common aliases include: content authenticator.Data confidentiality credentials: a set of parameters carried in the data packet that identify the needed algorithm
and key identifiers to decrypt the confidential data.Key owner (same as Identity): an entity (user, device, program, program instance, module in the program instance, etc.) that
owns private key(s) and the corresponding public key(s).Certificate: a data packet that carries a public key as payload with optional additional meta information regarding the key (e.g., validity period, signature time, etc.).
Ownership of the public key is made implicitly through the name of the packet or explicitly through meta information.Key locator: Parameter(s) that identify the ICN key. A key
locatore can be the ICN key's name, its prefix, the ICN key ID,
etc.Key ID: Unique identifier (e.g., hash digest) for a public or secret key.Trust model: a model or framework that defines trust relationships, i.e., which entity (represented by an ICN
key) is authorized to sign which data packets.Trust schema: a formal description of a trust model, e.g., in the form of a set of name-based relationships between
data and key names and a set of the trust anchors.Trust anchor: an ICN key that is assumed to be trusted within the context of a specific trust model.ICN key chain: a chain of ICN keys (certificates) wherein each key (certificate) is signed by its predecessor
and the head of the chain is a trust anchor, i.e., its authenticity is assumed.
Common aliases include: certificate chain.ICN Interface: a generalization of the network interface that can represent a physical network
interface (ethernet, wifi, bluetooth adapter, etc.), an overlay inter-node channel (IP/UDP tunnel, etc.), or
an intra-node IPC channel to an application (unix socket, shared memory, intents, etc.).
Common aliases include: face.ICN Consumer: 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.ICN Producer: an ICN entity that creates data 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.Data Mule: an ICN entity that temporarily stores and
potentially carries an interest or data packet before
forwarding it to next ICN entity.Stateful forwarding: 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.Name-based routing: a process of forwarding interest packets using the names
in interests to guide the forwarding processICN 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.ICN Routing plane: an ICN protocol or a set of ICN protocols to exchange information about name space reachability.Reverse path forwarding: a process of forwarding the incoming data packet to the incoming interface(s) recorded in the corresponding PIT entry (entries) and removing the PIT entry (entries).Interest forwarding strategy: 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 ICN Forwarding Information Base (FIB), measured data plane
performance parameters, and/or use other mechanisms to make the decision.
Common aliases include: forwarding strategy.Satisfying an interest: overall process of returning content
that satisfies the constraints imposed by the Interest, most notably
a match in the provided name. Four different flavors of "matching" are
used in an ICN network, as described below.Interest match in FIB (longest prefix match): a process of finding a FIB entry with the longest name (in terms of name components) that is a prefix of the specified name.Interest match in PIT (exact match): a process of finding a PIT entry that stores the same as specified 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 specified data packet.Interest match in CS (any match): a process of finding an entry in router’s content store that can satisfy the specified interest.Interest aggregation: a process of combining multiple
interest packets for the same data into a single PIT entry.
Common aliases include: interest suppression, interest collapsing.ICN Forwarding Information Base (FIB): a database that, for a set of prefixes, records a list of interfaces that can be used to retrieve data packets with names under the corresponding prefixes. The list of interfaces for each prefix can be ranked, and prefix/interfaces mapping , and interfaces can be associated with the additional information to facilitate forwarding strategy decisions.ICN Routing Information Base (RIB): a database that records a set of prefix-interface mappings that represent a candidate interface through which a data packet with the specified prefix can be retrieved. RIB can be used to populate FIB.Interest Nack: a packet that contains the interest packet and optional annotation,
which is sent by the router to the interface(s) the Interest was received from. Interest Nack is used to inform downstream
ICN nodes about inability to forward the included interest packet. The annotation can describe the reason.
Common aliases include: network NACK, interest return.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 direction opposite of interest forwarding (i.e., data and interest nacks are forwarded downstream): producer, router, …, consumer(s).In-network storage: a process of storing a data packet within the network (in routers opportunistic on-path caches, in 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 (or on-path in-network caching or just caching): 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.Managed caching (or off-path in-network storage): a process of temporarily, permanently, or scheduled storing of a selected (set of) data packet(s).Content Store (CS): a database on an ICN router that provides opportunistic caching.Managed in-network storage (repository, repo): an entity acting as an ICN producer that implements managed caching.Route-By-Name Routing (RBNR)Lookup-By-Name Routing (LBNR)Bread-crumbs routingReplication-by-nameRouting Locator SigningContent basedICN APIInformation Centric Delay Tolerant NetworkLocated-Named-DataSessionlessThe terminology described above is the manifestation of
intended semantics of NDN and CCN operations (what do we expect
the network to do?). In this section we summarize the most
commonly proposed use cases and interpretations.The networking view of NDN and CCN is that the request/reply
protocol implements a basic, unreliable data transfer service
for single, named packets.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)A more distributed systems view of the basic request/reply protocol
is that NDN and CCN provide a distributed lookup service:
Given a key value (=name), the service will return the corresponding
value.The lookup service turns into a database access protocol by
... namespace design ... prefix standing for a collection ... The
DB query expression must be encoded as a name.More generally, ... parameters in the interest ... used e.g.
as command channel for remote control of neighbor routers.Information-Centric Networking: Baseline ScenariosThis document aims at establishing a common understanding about
a set of scenarios that can be used as a base for the evaluation
of different information-centric networking (ICN) approaches so
that they can be tested and compared against each other while
showcasing their own advantages. Towards this end, we review the
ICN literature and document scenarios which have been considered
in previous performance evaluation studies. We discuss a variety
of aspects that an ICN solution can address. This includes general
aspects, such as, network efficiency, reduced complexity,
increased scalability and reliability, mobility support, multicast
and caching performance, real-time communication efficiency,
energy consumption frugality, and disruption and delay tolerance.
We detail ICN-specific aspects as well, such as information
security and trust, persistence, availability, provenance, and
location independence.This document is a product of the IRTF Information-Centric
Networking Research Group (ICNRG).ICN Research Challenges
This memo describes research challenges for Information-Centric Networking (ICN), an approach to evolve the Internet infrastructure to directly support information distribution by introducing uniquely named data as a core Internet principle. Data becomes independent from location, application, storage, and means of transportation, enabling or enhancing a number of desirable features, such as security, user-mobility, multicast and in-network caching. Mechanisms for realizing these benefits is subject of on-going research in the IRTF and elsewhere. This document describes current research challenges in ICN, including naming, security, routing, system scalability, mobility management, wireless networking, transport services, in-network caching, and network management. This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).
Information-centric Networking: Evaluation and Security Considerations
This document presents a number of considerations regarding evaluating Information-centric Networking (ICN) and sheds some light on the impact of ICN on network security. It also surveys the evaluation tools currently available to researchers in the ICN area and provides suggestions regarding methodology and metrics.
Adaptive Video Streaming over ICN
This document considers the consequences of moving the underlying network architecture from the current Internet to an Information- Centric Network (ICN) architecture on video distribution. As most of the traffic in future networks is expected to be video, we consider how to modify the existing video streaming mechanisms. Several important topics related to video distribution over ICN are presented, covering a wide range of scenarios: we look at how to evolve DASH to work over ICN, and leverage the recent ISO/IEC Moving Picture Experts Group (MPEG) Dynamic Adaptive Streaming over HTTP (DASH) standard; we consider layered encoding over ICN; Peer-to-Peer (P2P) mechanisms introduce distinct requirements for video and we look at how to adapt PPSP for ICN; Internet Protocol Television (IPTV) adds delay constraints, and this will create more stringent requirements over ICN as well. As part of the discussion on video, we discuss Digital Rights Management (DRM) in ICN. Finally, in addition to considering how existing mechanisms would be impacted by ICN, this document lists some research issues to design ICN specific video streaming mechanisms.
CCNx Messages in TLV Format
This document specifies the encoding of CCNx messages using a TLV Packet specification. CCNx messages follow the CCNx Semantics specification. This document defines the TLV types used by each message element and the encoding of each value.
CCNx Semantics
This document describes the core concepts of the CCNx architecture and presents a minimum network protocol based on two messages: Interests and Content Objects. It specifies the set of mandatory and optional fields within those messages and describes their behavior and interpretation. This architecture and protocol specification is independent of a specific wire encoding. The protocol also uses a Control message called an InterestReturn, whereby one system can return an Interest message to the previous hop due to an error condition. This indicates to the previous hop that the current system will not respond to the Interest.
Using ICN in disaster scenarios
Information Centric Networking (ICN) is a new paradigm where the network provides users with named content, instead of communication channels between hosts. This document outlines some research directions for Information Centric Networking with respect to applying ICN approaches for coping with natural or human-generated, large-scale disasters.
Mark Mosco, ...