rfc8793xml2.original.xml   rfc8793.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC4838 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference
.RFC.4838.xml">
<!ENTITY RFC4949 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference
.RFC.4949.xml">
<!ENTITY RFC6234 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference
.RFC.6234.xml">
<!ENTITY RFC7476 PUBLIC '' '../bib/reference.RFC.7476.xml'>
<!ENTITY RFC7927 PUBLIC '' '../bib/reference.RFC.7927.xml'>
<!ENTITY RFC7945 PUBLIC '' '../bib/reference.RFC.7945.xml'>
<!ENTITY RFC7933 PUBLIC '' '../bib/reference.RFC.7933.xml'>
<!ENTITY RFC8569 PUBLIC '' '../bib/reference.RFC.8569.xml'>
<!ENTITY RFC8609 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8609.xml">
<!ENTITY I-D.irtf-icnrg-disaster PUBLIC '' '../bib/reference.I-D.irtf-icnrg-disa
ster.xml'>
]>
<?rfc rfcedstyle="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="-o*+"?>
<rfc category="info" docName="draft-irtf-icnrg-terminology-08">
<front>
<title abbrev="ICN Terminology">Information-Centric Networking (ICN): CCNx a
nd NDN Terminology</title>
<author fullname="Bastiaan Wissingh" initials="B.F." surname="Wissingh"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="info
" consensus="true" docName="draft-irtf-icnrg-terminology-08" number="8793" obsol
etes="" updates="" submissionType="IRTF" xml:lang="en" tocInclude="true" sortRef
s="true" symRefs="true" version="3">
<front>
<title abbrev="ICN Terminology">Information-Centric Networking (ICN):
Content-Centric Networking (CCNx) and Named Data Networking (NDN)
Terminology</title>
<seriesInfo name="RFC" value="8793"/>
<author fullname="Bastiaan Wissingh" initials="B." surname="Wissingh">
<organization>TNO</organization> <organization>TNO</organization>
<address> <address>
<email>bastiaan.wissingh@tno.nl</email> <email>bastiaan.wissingh@tno.nl</email>
</address> </address>
</author> </author>
<author fullname="Christopher A. Wood" initials="C." surname="Wood"> <author fullname="Christopher A. Wood" initials="C." surname="Wood">
<organization>University of California Irvine</organization> <organization>University of California Irvine</organization>
<address> <address>
<email>woodc1@uci.edu</email> <email>caw@heapingbits.net</email>
</address> </address>
</author> </author>
<author fullname="Alex Afanasyev" initials="A." surname="Afanasyev"> <author fullname="Alex Afanasyev" initials="A." surname="Afanasyev">
<organization>Florida International University</organization> <organization>Florida International University</organization>
<address> <address>
<email>aa@cs.fiu.edu</email> <email>aa@cs.fiu.edu</email>
</address> </address>
</author> </author>
<author fullname="Lixia Zhang" initials="L." surname="Zhang"> <author fullname="Lixia Zhang" initials="L." surname="Zhang">
<organization>UCLA</organization> <organization>UCLA</organization>
<address> <address>
<email>lixia@cs.ucla.edu</email> <email>lixia@cs.ucla.edu</email>
</address> </address>
</author> </author>
<author fullname="David Oran" initials="D." surname="Oran"> <author fullname="David Oran" initials="D." surname="Oran">
<organization>Network Systems Research &amp; Design</organization> <organization>Network Systems Research &amp; Design</organization>
<address> <address>
<email>daveoran@orandom.net</email> <email>daveoran@orandom.net</email>
</address> </address>
</author> </author>
<author fullname="Christian Tschudin" initials="C." surname="Tschudin"> <author fullname="Christian Tschudin" initials="C." surname="Tschudin">
<organization>University of Basel</organization> <organization>University of Basel</organization>
<address> <address>
<email>christian.tschudin@unibas.ch</email> <email>christian.tschudin@unibas.ch</email>
</address> </address>
</author> </author>
<date month="June" year="2020"/>
<date month="January" year="2020"/>
<area>IRTF</area> <area>IRTF</area>
<workgroup>ICNRG</workgroup> <workgroup>Information-Centric Networking</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>content routing</keyword>
<keyword>content caching</keyword>
<keyword>content distribution networks</keyword>
<keyword>data-centric security</keyword>
<abstract> <abstract>
<t>Information Centric Networking (ICN) is a novel paradigm where <t>Information-Centric Networking (ICN) is a novel paradigm where network
network communications are accomplished by requesting named content, instead of communications are accomplished by requesting named content instead of sending p
sending packets to destination addresses. Named Data Networking (NDN) and Conte ackets to destination addresses. Named Data Networking (NDN) and Content-Centric
nt-Centric Networking (CCNx) are two prominent ICN architectures. This document Networking (CCNx) are two prominent ICN architectures. This document provides a
provides an overview of the terminology and definitions that have been used in d n overview of the terminology and definitions that have been used in describing
escribing concepts in these two implementations of ICN. While there are other IC concepts in these two implementations of ICN. While there are other ICN architec
N architectures, they are not part of the NDN and CCNx concepts and as such are tures, they are not part of the NDN and CCNx concepts and as such are out of sco
out of scope for this document. This document is a product of the Information-Ce pe for this document. This document is a product of the Information-Centric Netw
ntric Networking Research Group (ICNRG). orking Research Group (ICNRG).
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction" anchor="introduction"> <section anchor="introduction" numbered="true" toc="default">
<t>Information-centric networking (ICN) is an architecture to evolve the <name>Introduction</name>
Internet infrastructure from the existing host-centric design to a data-centric <t>Information-centric networking (ICN) is an architecture to evolve the
architecture, where accessing data by name becomes the essential network primiti Internet infrastructure from the existing host-centric design to a
ve. The goal is to let applications refer to data independently of their locatio data-centric architecture, where accessing data by name becomes the
n or means of transportation, which enables native multicast delivery, ubiquitou essential network primitive. The goal is to let applications refer to
s in-network caching and replication of data objects. </t> data independently of their location or means of transportation, which
enables native multicast delivery, ubiquitous in-network caching, and
<t>As the work on this topic continues to evolve, many new terms are emer replication of data objects. </t>
ging. The goal of this document is to collect the key terms with a corresponding <t>As the work on this topic continues to evolve, many new terms are
definition as they are used in the CCNx and NDN projects. Other ICN projects su emerging. The goal of this document is to collect the key terms with a
ch as <xref target="Netinf"/>, <xref target="PSIRP"/>, or <xref target="Mobility corresponding definition as they are used in the CCNx and NDN
First"/> are not covered and may be the subject of other documents.</t> projects. Among the important documents for these projects are <xref
target="RFC8569"/>, <xref target="RFC8609"/>, and <xref
<t>To help provide context for the individual defined terms, in this docu target="NDNTLV"/>. Other ICN projects such as <xref target="NETINF"
ment we first sketch the bigger picture of an ICN network by introducing the bas format="default"/>, <xref target="PSIRP" format="default"/>, or <xref
ic concepts and identifying the major components of the architecture in <xref ta target="MOBILITY-FIRST" format="default"/> are not covered and may be
rget="a-sketch-of-the-big-picture-of-icn"/>, after which, in <xref target="terms the subject of other documents.</t>
-by-category"/>, ICN related terms are listed by different categories. Readers s <t>In this document, to help provide context for the individual defined te
hould be aware that in this organization some terms may be used in other definit rms, we first sketch the bigger picture of an ICN network by
ions before they themselves are defined.</t> introducing the basic concepts and identifying the major components of
the architecture in <xref target="a-sketch-of-the-big-picture-of-icn"
<t>While this terminology document describes both confidentiality and int format="default"/>; after which, in <xref target="terms-by-category"
egrity-related terms, it should be noted that ICN architectures like NDN and CCN format="default"/>, ICN-related terms are listed by different
x generally do not provide data confidentiality, which is treated in these archi categories. Readers should be aware that in this organization, some terms
tectures as an application layer concern.</t> may be used in other definitions before they themselves are defined.</t>
<t>While this terminology document describes both confidentiality and
<t>This document represents the consensus of the Information-Centric Netw integrity-related terms, it should be noted that ICN architectures like
orking Research Group (ICNRG). It has been reviewed extensively by the Research NDN and CCNx generally do not provide data confidentiality, which is
Group (RG) members active in the specific areas of work covered by the document. treated in these architectures as an application-layer concern.</t>
It is not an IETF product and is not intended for standardization in the IETF.< <t>This document represents the consensus of the Information-Centric
/t> Networking Research Group (ICNRG). It has been reviewed extensively by
</section> 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
<section title="A Sketch of the Big Picture of ICN" anchor="a-sketch-of-the-big- for standardization in the IETF.</t>
picture-of-icn"> </section>
<t>In networking terms, an ICN is a delivery infrastructure for named data. Fo <section anchor="a-sketch-of-the-big-picture-of-icn" numbered="true" toc="de
r other complementing views see <xref target="semantics-and-usage"/>.</t> fault">
<name>A Sketch of the Big Picture of ICN</name>
<figure anchor="fig:i-d-protocol" align="center" title="Request-Reply Protocol <t>In networking terms, an ICN is a delivery infrastructure for named
of ICN networking. Legend: n=name, c=content, s=signature."> data. For other complementing views, see <xref
<artwork align="center"> target="semantics-and-usage" format="default"/>.</t>
<figure anchor="fig_i-d-protocol">
<name>Request-Reply Protocol of ICN Networking.</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
requestor zero or more data sources or requestor zero or more data sources or
(node) forwarding nodes replica nodes (node) forwarding nodes replica nodes
| | ... | |...| | | ... | |...|
| Interest(n) | | Interest(n) | | | Interest(n) | | Interest(n) | |
| --------------&gt; | | ---------------&gt; | | | --------------> | | ---------------> | |
| | | -------------------&gt; | | | | -------------------> |
| | | | | | | | | |
| | | Data([n],c,[s]) | | | | | Data([n],c,[s]) | |
| | | &lt;--------------- | | | | | <--------------- | |
| | | &lt;------------------- | | | | <------------------- |
| Data([n],c,[s]) | | | | | Data([n],c,[s]) | | | |
| &lt;-------------- | | | | | <-------------- | | | |
</artwork>
</figure>
<t>The following list describes the basic ICN concepts needed to discuss the i
mplementation of this service abstraction.</t>
<t><spanx style="strong">Request-Reply Protocol (Interest and Data Packet)</sp
anx>:</t>
<t><list style="empty">
<t>An ICN’s lookup service is implemented by defining two types o
f network packet formats: Interest packets that request content by name, and Dat
a 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 t
he request is ambiguous and several Data packets would satisfy the request, the
ICN network returns only one matching Data packet (thus achieving flow balance b
etween Interest and Data packets over individual layer 2 interfaces).</t>
</list></t>
<t><spanx style="strong">Packet and Content Names</spanx>:</t>
<t><list style="empty">
<t>Without a strong cryptographic binding between the name of a D
ata packet and its content, Data packet names would be useless for fetching spec
ific content. In ICN, verification of a Data packet’s name-to-content binding is
achieved through cryptographic means, either by (1) a cryptographic signature t
hat explicitly binds an application-chosen name to a Data packet’s content, or (
2) relying on an implicit name (cryptographic hash of the Data packet with or wi
thout application-chosen name) that the data consumer obtained through other mea
ns.</t>
</list></t>
<t><spanx style="strong">Data Authenticity and Encryption</spanx>:</t>
<t><list style="empty">
<t>Any data consumer or network element can (in principle) valida
te the authenticity of a Data packet by verifying its cryptographic name-to-cont
ent 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 na
me-to-content binding, but it may still be unwise to "trust" the content for any
particular purpose.</t>
</list></t>
<t><spanx style="strong">Trust</spanx>:</t>
<t><list style="empty">
<t>Data authenticity is distinct from data trustworthiness, thoug
h 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 tru
sted 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 app
ropriate for the value of the content. <xref target="security-considerations"/>
discusses this further.</t>
</list></t>
<t><spanx style="strong">Segmenting and Versioning</spanx>:</t>
<t><list style="empty">
<t>An ICN network will be engineered for some packet size limit.
As application-level data objects will often be considerably larger, objects mus
t 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 wh
ich 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.</t>
</list></t>
<t><spanx style="strong">Packet and Frame</spanx>:</t>
<t><list style="empty">
<t>NDN and CCNx introduce Protocol Data Units (PDUs) which typica
lly are larger than the maximum transmission unit of the underlying networking t
echnology. We refer to PDUs as packets and the (potentially fragmented) packet p
arts that traverse MTU-bound layer 2 interfaces as frames. Handling layer 2 tech
nologies which lead to fragmentation of ICN packets is done inside the ICN netwo
rk and is not visible at the service interface.</t>
</list></t>
<t><spanx style="strong">ICN Node</spanx>:</t>
<t><list style="empty">
<t>A node within an ICN network can fulfill the role of a data pr
oducer, 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 pa
cket forwarding in real time. It can also behave as a store and forward node, ca
rrying an Interest or Data packet for some time before forwarding it to next nod
e. An ICN node may also run routing protocols to assist its Interest forwarding
decisions.</t>
</list></t>
<t><spanx style="strong">Forwarding Plane</spanx>:</t>
<t><list style="empty">
<t>The canonical way of implementing packet forwarding in an ICN
network relies on three data structures that capture a node’s state: a Forwardin
g Interest Table (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.</t>
</list></t>
</section>
<section title="Terms by category" anchor="terms-by-category">
<section title="Generic terms" anchor="generic-terms">
<t><spanx style="strong">Information-Centric Networking (ICN)</sp
anx>:</t>
<t><list style="empty">
<t>A networking architecture that retrieves Data packets
as response to Interest packets. Content-Centric Networking (CCNx 1.x) and Named
Data Networking (NDN) are two realizations (designs) of an ICN architecture.</t
>
</list></t>
<t><spanx style="strong">Data packet Immutability</spanx>:</t>
<t><list style="empty">
<t>After a data packet is created, the cryptographic sign
ature 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 cont
ent carried in a data packet is intended to be mutable, versioning of the name s
hould be used, so that each version uniquely identifies an immutable instance of
the content. This allows disambiguation of various versions of content such tha
t coordination among the various instances in a distributed system can be achiev
ed.</t>
</list></t>
</section>
<section title="Terms related to ICN Nodes" anchor="terms-related-to-icn-
nodes">
<t><spanx style="strong">ICN Interface</spanx>:</t>
<t><list style="empty">
<t>A generalization of the network interface that can represent a
physical network interface (ethernet, wifi, bluetooth adapter, etc.), an overla
y inter-node channel (IP/UDP tunnel, etc.), or an intra-node inter-process commu
nication (IPC) channel to an application (unix socket, shared memory, intents, e
tc.).</t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>Common aliases include: face.</t>
</list></t>
</list></t>
<t><spanx style="strong">ICN Consumer</spanx>:</t>
<t><list style="empty">
<t>An ICN entity that requests Data packets by generating and sen
ding out Interest packets towards local (using intra-node interfaces) or remote
(using inter-node interfaces) ICN Forwarders.</t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>Common aliases include: consumer, information consumer
, data consumer, consumer of the content.</t>
</list></t>
</list></t>
<t><spanx style="strong">ICN Producer</spanx>:</t>
<t><list style="empty">
<t>An ICN entity that creates Data packets and makes them availab
le for retrieval.</t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>Common aliases include: producer, publisher, informati
on publisher, data publisher, data producer.</t>
</list></t>
</list></t>
<t><spanx style="strong">ICN Forwarder</spanx>:</t>
<t><list style="empty">
<t>An ICN entity that implements stateful forwarding.</t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>Common aliases include: ICN router.</t>
</list></t>
</list></t>
<t><spanx style="strong">ICN Data Mule</spanx>:</t>
<t><list style="empty">
<t>An ICN entity that temporarily stores and potentially carries
an Interest or Data packet before forwarding it to next ICN entity. Note that su
ch ICN data mules do not have all the properties of data mules as employed in th
e Delay Tolerant Networking <xref target="RFC4838">(DTN)</xref> specifications.<
/t>
</list></t>
</section>
<section title="Terms related to the Forwarding plane" anchor="terms-rela
ted-to-the-forwarding-plane">
<t><spanx style="strong">Stateful forwarding</spanx>:</t>
<t><list style="empty">
<t>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 d
ata plane performance, e.g., to adjust interest forwarding strategy decisions.</
t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>Common aliases include: ICN Data plane, ICN Forwarding
.</t>
</list></t>
</list></t>
<t><spanx style="strong">Forwarding strategy</spanx>:</t>
<t><list style="empty">
<t>A module of the ICN stateful forwarding (ICN data) pla
ne that implements a decision on where/how to forward the incoming Interest pack
et. The forwarding strategy can take input from the Forwarding Information Base
(FIB), measured data plane performance parameters, and/or use other mechanisms t
o make the decision.</t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>Common aliases include: Interest forwarding st
rategy.</t>
</list></t>
</list></t>
<t><spanx style="strong">Upstream (forwarding)</spanx>:</t>
<t><list style="empty">
<t>Forwarding packets in the direction of Interests (i.e.
, Interests are forwarded upstream): consumer, router, router, …, producer.</t>
</list></t>
<t><spanx style="strong">Downstream (forwarding)</spanx>:</t>
<t><list style="empty">
<t>Forwarding packets in the opposite direction of Intere
st forwarding (i.e., Data and Interest Nacks are forwarded downstream): producer
, router, …, consumer(s).</t>
</list></t>
<t><spanx style="strong">Interest forwarding</spanx>:</t>
<t><list style="empty">
<t>A process of forwarding Interest packets using the Nam
es 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.</t>
</list></t>
<t><spanx style="strong">Interest aggregation</spanx>:</t>
<t><list style="empty">
<t>A process of combining multiple Interest packets with
the same Name and additional restrictions for the same Data into a single PIT en
try.</t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>Common aliases include: Interest collapsing.</
t>
</list></t>
</list></t>
<t><spanx style="strong">Data forwarding</spanx>:</t>
<t><list style="empty">
<t>A process of forwarding the incoming Data packet to th
e interface(s) recorded in the corresponding PIT entry (entries) and removing th
e corresponding PIT entry (entries).</t>
</list></t>
<t><spanx style="strong">Satisfying an Interest</spanx>:</t>
<t><list style="empty">
<t>An overall process of returning content that satisfies
the constraints imposed by the Interest, most notably a match in the provided N
ame.</t>
</list></t>
<t><spanx style="strong">Interest match in FIB (longest prefix match)</sp
anx>:</t>
<t><list style="empty">
<t>A process of finding a FIB entry with the longest Name (in ter
ms of Name components) that is a prefix of the specified Name. See <xref target=
"terms-related-to-name-types"/> for terms related to name prefixes</t>
</list></t>
<t><spanx style="strong">Interest match in PIT (exact match)</spa
nx>:</t>
<t><list style="empty">
<t>A process of finding a PIT entry that stores the same
Name as specified in the Interest (including Interest restrictions, if any).</t>
</list></t>
<t><spanx style="strong">Data match in PIT (all match)</spanx>:</
t>
<t><list style="empty">
<t>A process of finding (a set of) PIT entries that can b
e satisfied with the specified Data packet.</t>
</list></t>
<t><spanx style="strong">Interest match in CS (any match)</spanx>
:</t>
<t><list style="empty">
<t>A process of finding an entry in router’s Content Stor
e that can satisfy the specified Interest.</t>
</list></t>
<t><spanx style="strong">Pending Interest Table (PIT)</spanx>:</t
>
<t><list style="empty">
<t>A database that records received and not yet satisfied
Interests with the interfaces from where they were received. The PIT can also s
tore interfaces to where Interests were forwarded, and information to assess dat
a plane performance. Interests for the same Data are aggregated into a single PI
T entry.</t>
</list></t>
<t><spanx style="strong">Forwarding Information Base (FIB)</spanx
>:</t>
<t><list style="empty">
<t>A database that contains a set of prefixes, each prefi
x associated with one or more faces that can be used to retrieve Data packets wi
th Names under the corresponding prefix. The list of faces for each prefix can b
e ranked, and each face may be associated with additional information to facilit
ate forwarding strategy decisions.</t>
</list></t>
<t><spanx style="strong">Content Store (CS)</spanx>:</t>
<t><list style="empty">
<t>A database in an ICN router that provides caching.</t>
</list></t>
<t><spanx style="strong">In-network storage</spanx>:</t>
<t><list style="empty">
<t>An optional process of storing a Data packet within th
e network (opportunistic caches, dedicated on/off path caches, and managed in-ne
twork storage systems), so it can satisfy an incoming Interest for this Data pac
ket. The in-network storages can optionally advertise the stored Data packets in
the routing plane.</t>
</list></t>
<t><spanx style="strong">Opportunistic caching</spanx>:</t>
<t><list style="empty">
<t>A process of temporarily storing a forwarded Data pack
et in the router’s memory (RAM or disk), so it can be used to satisfy future Int
erests for the same Data, if any.</t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>Common aliases include: on-path in-network cac
hing</t>
</list></t>
</list></t>
<t><spanx style="strong">Managed caching</spanx>:</t>
<t><list style="empty">
<t>A process of temporarily, permanently, or scheduled st
oring of a selected (set of) Data packet(s).</t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>Common aliases include: off-path in-network st
orage</t>
</list></t>
</list></t>
<t><spanx style="strong">Managed in-network storage</spanx>:</t>
<t><list style="empty">
<t>An entity acting as an ICN publisher that implements m
anaged caching.</t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>Common aliases include: repository, repo</t>
</list></t>
</list></t>
<t><spanx style="strong">ICN Routing plane</spanx>:</t>
<t><list style="empty">
<t>An ICN protocol or a set of ICN protocols to exchange
information about Name space reachability.</t>
</list></t>
<t><spanx style="strong">ICN Routing Information Base (RIB)</span
x>:</t>
<t><list style="empty">
<t>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.</t>
</list></t>
</section>
<section title="Terms related to Packet Types" anchor="terms-related-to-p
acket-types">
<t><spanx style="strong">Interest packet</spanx>:</t>
<t><list style="empty">
<t>A network-level packet that expresses the request for
a data packet using either an exact name or a name prefix. An Interest packet ma
y optionally carry a set of additional restrictions (e.g., Interest selectors).
An Interest may be associated with additional information to facilitate forwardi
ng and can include Interest lifetime, hop limit, forwarding hints, labels, etc.
In different ICN designs, the set of additional associated information may vary.
</t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>Common aliases include: Interest, Interest mes
sage, information request</t>
</list></t>
</list></t>
<t><spanx style="strong">Interest Nack</spanx>:</t>
<t><list style="empty">
<t>A packet that contains the Interest packet and optiona
l annotation, which is sent by the ICN Router to the interface(s) the Interest w
as received from. Interest Nack is used to inform downstream ICN nodes about ina
bility to forward the included Interest packet. The annotation can describe the
reason.</t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>Common aliases include: network NACK, Interest
return.</t>
</list></t>
</list></t>
<t><spanx style="strong">Data packet</spanx>:</t>
<t><list style="empty">
<t>A network-level packet that carries payload, uniquely
identified by a name, and is directly secured through cryptographic signature me
chanisms.</t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>Common aliases include: data, data object, con
tent object, content object packet, data message, named data object, named data.
</t>
</list></t>
</list></t>
<t><spanx style="strong">Link</spanx>:</t>
<t><list style="empty">
<t>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 th
e Packet ID of the corresponding Data packet, but this is not a requirement.</t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>Common aliases include: pointer.</t>
</list></t>
</list></t>
<t><spanx style="strong">Manifest</spanx>:</t>
<t><list style="empty">
<t>A type of Data packet that contains Full Name Links to
one or more Data Packets. Manifests group collections of related Data packets u
nder a single Name. Manifests allow both large Data objects to be conveniently s
plit into individual Content Objects under one name, and to represent sets of re
lated Content Objects as a form of “directory”. Manifests have the additional be
nefit of amortizing the signature verification cost for each Data packet referen
ced by the inner Links. Manifests typically contain additional metadata, e.g., t
he size (in bytes) of each linked Data packet and the cryptographic hash digest
of all Data contained in the linked Data packets.</t>
</list></t>
</section>
<section title="Terms related to Name Types" anchor="terms-related-to-nam
e-types">
<t><spanx style="strong">Name</spanx>:</t>
<t><list style="empty">
<t>A Data packet identifier. An ICN name is hierarchical (a seque
nce of name components) and usually is semantically meaningful, making it expres
sive, flexible and application-specific (akin to a HTTP URL). A Name may encode
information about application context, semantics, locations (topological, geogra
phical, hyperbolic, etc.), a service name, etc.</t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>Common aliases include: data name, interest na
me, content name.</t>
</list></t>
</list></t>
<t><spanx style="strong">Name component</spanx>:</t>
<t><list style="empty">
<t>A sequence of bytes and optionally a numeric type repr
esenting a single label in the hierarchical structured name.</t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>Common aliases include: name segment (as in CC
Nx).</t>
</list></t>
</list></t>
<t><spanx style="strong">Packet ID</spanx>:</t>
<t><list style="empty">
<t>A unique cryptographic identifier for a Data packet. T
ypically, this is a cryptographic hash digest of a data packet (such as <xref ta
rget="RFC6234">SHA256</xref>), including its name, payload, meta information, an
d signature.</t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>Common aliases include: implicit digest.</t>
</list></t>
</list></t>
<t><spanx style="strong">Selector</spanx>:</t>
<t><list style="empty">
<t>A mechanism (condition) to select an individual Data p
acket from a collection of Data packets that match a given Interest that request
s data using a prefix or exact Name.</t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>Common aliases include: interest selector, res
trictor, interest restrictor.</t>
</list></t>
</list></t>
<t><spanx style="strong">Nonce</spanx>:</t>
<t><list style="empty">
<t>A field of an Interest packet that transiently names a
n Interest instance (instance of Interest for a given name). Note: the specifica
tions defining nonces in NDN do not necessarily satisfy all the properties of no
nces as discussed in <xref target="RFC4949"/>.</t>
</list></t>
<t><spanx style="strong">Exact Name</spanx>:</t>
<t><list style="empty">
<t>A name that is encoded inside a Data packet and which
typically uniquely identifies this Data packet.</t>
</list></t>
<t><spanx style="strong">Full Name</spanx>:</t>
<t><list style="empty">
<t>An exact Name with the Packet ID of the corresponding
Data packet.</t>
</list></t>
<t><spanx style="strong">Prefix Name</spanx>:</t>
<t><list style="empty">
<t>A Name that includes a partial sequence of Name compon
ents (starting from the first one) of a Name encoded inside a Data packet.</t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>Common aliases include: prefix.</t>
</list></t>
</list></t>
</section>
<section title="Terms related to Name Usage" anchor="terms-related-to-nam
e-usage">
<t><spanx style="strong">Naming conventions</spanx>:</t>
<t><list style="empty">
<t>A convention, agreement, or specification for the Data
packet naming. a Naming convention structures a namespace.</t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>Common aliases include: Naming scheme, ICN nam
ing scheme, namespace convention.</t>
</list></t>
</list></t>
<t><spanx style="strong">Hierarchically structured naming</spanx>
:</t>
<t><list style="empty">
<t>The naming scheme that assigns and interprets a Name a
s 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.</t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>Common aliases include: hierarchical naming, s
tructured naming.</t>
</list></t>
</list></t>
<t><spanx style="strong">Flat naming</spanx>:</t>
<t><list style="empty">
<t>The naming scheme that assigns and interprets a Name a
s a single label (Name component) without any internal structure. This can be co
nsidered a special (or degenerate) case of structured names.</t>
</list></t>
<t><spanx style="strong">Segmentation</spanx>:</t>
<t><list style="empty">
<t>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 repre
senting the segment (chunk) number.</t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>Common aliases include: chunking.</t>
</list></t>
</list></t>
<t><spanx style="strong">Versioning</spanx>:</t>
<t><list style="empty">
<t>A process of assigning a unique Name to the revision o
f 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 compone
nt (e.g., prefix identifies data, unique version component identifies the revisi
on of the data).</t>
</list></t>
<t><spanx style="strong">Fragmentation</spanx>:</t>
<t><list style="empty">
<t>A process of splitting PDUs into Frames so that they c
an be transmitted over a layer 2 interface with a smaller MTU size.</t>
</list></t>
</section>
<section title="Terms related to Data-Centric Security" anchor="terms-rel
ated-to-data-centric-security">
<t><spanx style="strong">Data-Centric Security</spanx>:</t>
<t><list style="empty">
<t>A security property associated with the Data packet, including
data (Data-Centric) integrity, authenticity, and optionally confidentiality. Th
ese security properties stay with the data packet regardless where it is stored
and how it is retrieved.</t>
</list></t>
<t><list style="empty">
<t><list style="empty">
<t>Common aliases include: directly securing data packet<
/t>
</list></t>
</list></t>
<t><spanx style="strong">Data Integrity</spanx></t> Legend: n=name, c=content, s=signature]]></artwork>
<t><list style="empty"> </figure>
<t>A cryptographic mechanism to ensure the consistency of the Dat <t>The following list describes the basic ICN concepts needed to discuss
a packet bits. The Data integrity property validates that the Data packet conten the implementation of this service abstraction.</t>
t has not been corrupted during transmission, e.g., over lossy or otherwise unre <t><strong>Request-Reply Protocol (Interest and Data
liable paths, or been subject to deliberate modification.</t> Packet):</strong></t>
</list></t> <ul empty="true" spacing="normal">
<li>An ICN's lookup service is implemented by defining two types of
network packet formats: <xref target="interest_packet"
format="none">Interest packets</xref> that request content by name and
<xref target="data_packet" format="none">Data packets</xref> 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).</li>
</ul>
<t><strong>Packet and Content Names:</strong></t>
<ul empty="true" spacing="normal">
<li>Without a strong cryptographic binding between the name of a <xref
target="data_packet" format="none">Data packet</xref> and its content, D
ata
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.</li>
</ul>
<t><spanx style="strong">Data Authenticity</spanx></t> <t><strong>Data Authenticity and Encryption:</strong></t>
<t><list style="empty"> <ul empty="true" spacing="normal">
<t>A cryptographic mechanism to ensure trustworthiness of a Data <li>Any data consumer or network element can (in principle) validate
packet, based on a selected (e.g., by a consumer/producer) trust model. Typicall the authenticity of a <xref target="data_packet" format="none">Data
y, data authenticity is assured through the use of asymmetric cryptographic sign packet</xref> by verifying its cryptographic name-to-content
atures (e.g., RSA, ECDSA), but can also be realized using symmetric signatures ( binding. Note that data authenticity is distinct from data
e.g., HMAC) within trusted domains.</t> trustworthiness, though the two concepts are related. A packet is
</list></t> authentic if it has a valid name-to-content binding, but it may still
be unwise to "trust" the content for any particular purpose.</li>
</ul>
<t><strong>Trust:</strong></t>
<ul empty="true" spacing="normal">
<li>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. <xref target="security-considerations" format="default"/>
discusses this further.</li>
</ul>
<t><strong>Segmenting and Versioning:</strong></t>
<ul empty="true" spacing="normal">
<li>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 <xref target="data_packet"
format="none">Data packets</xref>. 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.</li>
</ul>
<t><strong>Packet and Frame:</strong></t>
<ul empty="true" spacing="normal">
<li>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.</li>
</ul>
<t><strong>ICN Node:</strong></t>
<ul empty="true" spacing="normal">
<li>A node within an ICN network can fulfill the role of a data
producer, a data consumer, and/or a forwarder for <xref
target="interest_packet" format="none">Interest</xref> and <xref
target="data_packet" format="none">Data packets</xref>. 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.</li>
</ul>
<t><strong>Forwarding Plane:</strong></t>
<ul empty="true" spacing="normal">
<li>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
<xref target="content_store" format="none">Content Store</xref>
(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 <xref target="interest_packet"
format="none">Interest packet</xref>, 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.</li>
</ul>
<t><spanx style="strong">Data Confidentiality</spanx></t> </section>
<t><list style="empty"> <section anchor="terms-by-category" numbered="true" toc="default">
<t>A cryptographic mechanism to ensure secrecy of a Data <name>Terms by Category</name>
packet. Data confidentiality includes separate mechanisms: content confidentiali <section anchor="generic-terms" numbered="true" toc="default">
ty and Name confidentiality</t> <name>Generic Terms</name>
</list></t> <t><strong>Information-Centric Networking (ICN):</strong></t>
<ul empty="true" spacing="normal">
<li>A networking architecture that retrieves <xref
target="data_packet" format="none">Data packets</xref> in
response to <xref target="interest_packet" format="none">Interest pack
ets</xref>. Content-Centric Networking (CCNx 1.x)
and Named Data Networking (NDN) are two realizations (designs) of an
ICN architecture.</li>
</ul>
<t><strong>Data Packet Immutability:</strong></t>
<ul empty="true" spacing="normal">
<li>After a <xref target="data_packet" format="none">Data
packet</xref> 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.</li>
</ul>
</section>
<section anchor="terms-related-to-icn-nodes" numbered="true" toc="default"
>
<name>Terms Related to ICN Nodes</name>
<t><strong>ICN Interface:</strong></t>
<ul empty="true" spacing="normal">
<li>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.).</li>
</ul>
<t><spanx style="strong">Content Confidentiality</spanx></t> <ul empty="true" spacing="normal">
<t><list style="empty"> <li>
<t>A cryptographic mechanism to prevent an unauthorized p <ul empty="true" spacing="normal">
arty to get access to the plain-text payload of a Data packet. Can be realized t <li>Common aliases include: face.</li>
hrough encryption (symmetric, asymmetric, hybrid) and proper distribution of the </ul>
decryption keys to authorized parties.</t> </li>
</list></t> </ul>
<t><strong>ICN Consumer:</strong></t>
<ul empty="true" spacing="normal">
<li>An ICN entity that requests <xref target="data_packet"
format="none">Data packets</xref> by generating and sending out
<xref target="interest_packet" format="none">Interest packets</xref>
towards local (using intra-node interfaces) or remote (using
inter-node interfaces) ICN Forwarders.</li>
</ul>
<ul empty="true" spacing="normal">
<li>
<ul empty="true" spacing="normal">
<li>Common aliases include: consumer, information consumer, data c
onsumer, consumer of the content.</li>
</ul>
</li>
</ul>
<t><strong>ICN Producer:</strong></t>
<ul empty="true" spacing="normal">
<li>An ICN entity that creates <xref target="data_packet"
format="none">Data packets</xref> and makes them available for
retrieval.</li>
</ul>
<ul empty="true" spacing="normal">
<li>
<ul empty="true" spacing="normal">
<li>Common aliases include: producer, publisher, information publi
sher, data publisher, data producer.</li>
</ul>
</li>
</ul>
<t><strong>ICN Forwarder:</strong></t>
<ul empty="true" spacing="normal">
<li>An ICN entity that implements stateful forwarding.</li>
</ul>
<ul empty="true" spacing="normal">
<li>
<ul empty="true" spacing="normal">
<li>Common aliases include: ICN router.</li>
</ul>
</li>
</ul>
<t><strong>ICN Data Node:</strong></t>
<ul empty="true" spacing="normal">
<li>An ICN entity that temporarily stores and potentially carries an
Interest or <xref target="data_packet" format="none">Data
packet</xref> 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) <xref
target="RFC4838" format="default"></xref> specifications.</li>
</ul>
</section>
<t><spanx style="strong">Name Confidentiality</spanx></t> <section anchor="terms-related-to-the-forwarding-plane" numbered="true" to
<t><list style="empty"> c="default">
<t>A cryptographic mechanism to prevent an observer of In <name>Terms Related to the Forwarding Plane</name>
terest-Data exchanges (e.g., intermediate router) from gaining detailed meta inf <t><strong>Stateful Forwarding:</strong></t>
ormation about the Data packet. This mechanism can be realized using encryption <ul empty="true" spacing="normal">
(same as content confidentiality) or obfuscation mechanisms.</t> <li>A forwarding process that records incoming <xref
</list></t> target="interest_packet" format="none">Interest packets</xref> in
</section> the PIT and uses the recorded information to forward the retrieved
</section> <xref target="data_packet" format="none">Data packets</xref> 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.</li>
</ul>
<ul empty="true" spacing="normal">
<li>
<ul empty="true" spacing="normal">
<li>Common aliases include: ICN Data plane, ICN Forwarding.</li>
</ul>
</li>
</ul>
<t anchor="forwarding_strategy"><strong>Forwarding Strategy:</strong></t
>
<ul empty="true" spacing="normal">
<li>A module of the ICN stateful forwarding (ICN data) plane that
implements a decision on where/how to forward the incoming <xref
target="interest_packet" format="none">Interest packet</xref>. The for
warding strategy
can take input from the Forwarding Information Base (FIB), measured
data-plane performance parameters, and/or use other mechanisms to
make the decision.</li>
</ul>
<ul empty="true" spacing="normal">
<li>
<ul empty="true" spacing="normal">
<li>Common aliases include: Interest forwarding strategy.</li>
</ul>
</li>
</ul>
<section title="Semantics and Usage" anchor="semantics-and-usage"> <t><strong>Upstream (forwarding):</strong></t>
<ul empty="true" spacing="normal">
<li>Forwarding packets in the direction of Interests (i.e., Interests
are forwarded upstream): consumer, router, router, ..., producer.</li>
</ul>
<t><strong>Downstream (forwarding):</strong></t>
<ul empty="true" spacing="normal">
<li>Forwarding packets in the opposite direction of Interest
forwarding (i.e., Data and <xref target="interest_nack"
format="none">Interest Nacks</xref> are forwarded downstream):
producer, router, ..., consumer(s).</li>
</ul>
<t><strong>Interest Forwarding:</strong></t>
<ul empty="true" spacing="normal">
<li>A process of forwarding <xref target="interest_packet"
format="none">Interest packets</xref> using the <xref target="name"
format="none">Names</xref> 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 <xref
target="forwarding_strategy" format="none">Forwarding
Strategy</xref>.</li>
</ul>
<t><strong>Interest Aggregation:</strong></t>
<ul empty="true" spacing="normal">
<li>A process of combining multiple <xref target="interest_packet"
format="none">Interest packets</xref> with the same <xref
target="name" format="none">Name</xref> and additional restrictions
for the same Data into a single PIT entry.</li>
</ul>
<ul empty="true" spacing="normal">
<li>
<ul empty="true" spacing="normal">
<li>Common aliases include: Interest collapsing.</li>
</ul>
</li>
</ul>
<t><strong>Data Forwarding:</strong></t>
<ul empty="true" spacing="normal">
<li>A process of forwarding the incoming <xref target="data_packet" fo
rmat="none">Data packet</xref> to the
interface(s) recorded in the corresponding PIT entry (entries) and
removing the corresponding PIT entry (entries).</li>
</ul>
<t><strong>Satisfying an Interest:</strong></t>
<ul empty="true" spacing="normal">
<li>An overall process of returning content that satisfies the
constraints imposed by the Interest, most notably a match in the
provided <xref target="name" format="none">Name</xref>.</li>
</ul>
<t><strong>Interest Match in FIB (longest prefix match):</strong></t>
<ul empty="true" spacing="normal">
<li>A process of finding a FIB entry with the longest <xref
target="name" format="none">Name</xref> (in terms
of <xref target="name_component" format="none">Name components</xref>)
that is a prefix of the specified Name. See
<xref target="terms-related-to-name-types" format="default"/> for
terms related to name prefixes.</li>
</ul>
<t><strong>Interest Match in PIT (exact match):</strong></t>
<ul empty="true" spacing="normal">
<li>A process of finding a PIT entry that stores the same <xref
target="name" format="none">Name</xref> as
specified in the Interest (including Interest restrictions, if
any).</li>
</ul>
<t><strong>Data Match in PIT (all match):</strong></t>
<ul empty="true" spacing="normal">
<li>A process of finding (a set of) PIT entries that can be
satisfied with the specified <xref target="data_packet" format="none">D
ata packet</xref>.</li>
</ul>
<t><strong>Interest Match in CS (any match):</strong></t>
<ul empty="true" spacing="normal">
<li>A process of finding an entry in a router's <xref
target="content_store" format="none">Content Store</xref> that
can satisfy the specified Interest.</li>
</ul>
<t><strong>Pending Interest Table (PIT):</strong></t>
<ul empty="true" spacing="normal">
<li>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.</li>
</ul>
<t><strong>Forwarding Information Base (FIB):</strong></t>
<ul empty="true" spacing="normal">
<li>A database that contains a set of prefixes, each prefix
associated with one or more faces that can be used to retrieve <xref
target="data_packet" format="none">Data packets</xref> with <xref targ
et="name"
format="none">Names</xref> 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.</li>
</ul>
<t anchor="content_store"><strong>Content Store (CS):</strong></t>
<ul empty="true" spacing="normal">
<li>A database in an ICN router that provides caching.</li>
</ul>
<t><strong>In-Network Storage:</strong></t>
<ul empty="true" spacing="normal">
<li>An optional process of storing a <xref target="data_packet"
format="none">Data packet</xref> 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.</li>
</ul>
<t><strong>Opportunistic Caching:</strong></t>
<ul empty="true" spacing="normal">
<li>A process of temporarily storing a forwarded <xref
target="data_packet" format="none">Data packet</xref> in the
router's memory (RAM or disk), so it can be used to satisfy future
Interests for the same Data, if any.</li>
</ul>
<ul empty="true" spacing="normal">
<li>
<ul empty="true" spacing="normal">
<li>Common aliases include: on-path in-network caching.</li>
</ul>
</li>
</ul>
<t><strong>Managed Caching:</strong></t>
<ul empty="true" spacing="normal">
<t>The terminology described above is the manifestation of intended seman <li>The process of achieving the temporary, permanent, or scheduled
tics of NDN and CCNx operations (what do we expect the network to do?). In this storage of a selected (set of) <xref target="data_packet" format="none">Da
section we summarize the most commonly proposed use cases and interpretations.</ ta packet(s)</xref>.</li>
t> </ul>
<ul empty="true" spacing="normal">
<li>
<ul empty="true" spacing="normal">
<li>Common aliases include: off-path in-network storage.</li>
</ul>
</li>
</ul>
<t><strong>Managed In-Network Storage:</strong></t>
<ul empty="true" spacing="normal">
<li>An entity acting as an ICN publisher that implements managed cachi
ng.</li>
</ul>
<ul empty="true" spacing="normal">
<li>
<ul empty="true" spacing="normal">
<li>Common aliases include: repository, repo.</li>
</ul>
</li>
</ul>
<t><strong>ICN Routing Plane:</strong></t>
<ul empty="true" spacing="normal">
<li>An ICN protocol or a set of ICN protocols to exchange
information about <xref target="name" format="none">Name</xref> space
reachability.</li>
</ul>
<t><strong>ICN Routing Information Base (RIB):</strong></t>
<ul empty="true" spacing="normal">
<li>A database that contains a set of prefix-face mappings that are pr
oduced by running one or multiple routing protocols. The RIB is used to populate
the FIB.</li>
</ul>
</section>
<section anchor="terms-related-to-packet-types" numbered="true" toc="defau
lt">
<name>Terms Related to Packet Types</name>
<t anchor="interest_packet"><strong>Interest Packet:</strong></t>
<ul empty="true" spacing="normal">
<li>A network-level packet that expresses the request for a <xref
target="data_packet" format="none">Data packet</xref> 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.</li>
</ul>
<ul empty="true" spacing="normal">
<li>
<ul empty="true" spacing="normal">
<li>Common aliases include: Interest, Interest message, informatio
n request.</li>
</ul>
</li>
</ul>
<t anchor="interest_nack"><strong>Interest Nack:</strong></t>
<ul empty="true" spacing="normal">
<li>A packet that contains the <xref target="interest_packet"
format="none">Interest packet</xref> 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.</li>
</ul>
<ul empty="true" spacing="normal">
<li>
<ul empty="true" spacing="normal">
<li>Common aliases include: network NACK, Interest return.</li>
</ul>
</li>
</ul>
<t anchor="data_packet"><strong>Data Packet:</strong></t>
<ul empty="true" spacing="normal">
<li>A network-level packet that carries payload, uniquely identified
by a name, that is directly secured through cryptographic signature
mechanisms.</li>
</ul>
<ul empty="true" spacing="normal">
<li>
<ul empty="true" spacing="normal">
<li>Common aliases include: data, data object, content object, con
tent object packet, data message, named data object, named data.</li>
</ul>
</li>
</ul>
<t anchor="link"><strong>Link:</strong></t>
<ul empty="true" spacing="normal">
<li>A type of <xref target="data_packet" format="none">Data
packet</xref> whose body contains the <xref target="name"
format="none">Name</xref> of another Data packet. This inner Name is
often a <xref target="full_name" format="none">Full Name</xref>,
i.e., it specifies the Packet ID of the corresponding Data packet,
but this is not a requirement.</li>
</ul>
<ul empty="true" spacing="normal">
<li>
<ul empty="true" spacing="normal">
<li>Common aliases include: pointer.</li>
</ul>
</li>
</ul>
<t><strong>Manifest:</strong></t>
<ul empty="true" spacing="normal">
<li>A type of <xref target="data_packet" format="none">Data packet</xr
ef> that contains <xref target="full_name" format="none">Full Name</xref> <xref
target="link" format="none">Links</xref> 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 <xref target="link" format="none">Links</xref>. Manifests typica
lly 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.</li>
</ul>
</section>
<section anchor="terms-related-to-name-types" numbered="true" toc="default
">
<name>Terms Related to Name Types</name>
<t anchor="name"><strong>Name:</strong></t>
<ul empty="true" spacing="normal">
<li>A <xref target="data_packet" format="none">Data packet</xref>
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.</li>
</ul>
<ul empty="true" spacing="normal">
<li>
<ul empty="true" spacing="normal">
<li>Common aliases include: data name, interest name, content name
.</li>
</ul>
</li>
</ul>
<t anchor="name_component"><strong>Name component:</strong></t>
<ul empty="true" spacing="normal">
<li>A sequence of bytes and optionally a numeric type representing a s
ingle label in the hierarchical structured name.</li>
</ul>
<ul empty="true" spacing="normal">
<li>
<ul empty="true" spacing="normal">
<li>Common aliases include: name segment (as in CCNx).</li>
</ul>
</li>
</ul>
<t><strong>Packet ID:</strong></t>
<ul empty="true" spacing="normal">
<li>A unique cryptographic identifier for a <xref
target="data_packet" format="none">Data packet</xref>. Typically,
this is a cryptographic hash digest of a Data packet (such as SHA256
<xref target="RFC6234" format="default"></xref>), including
its name, payload, meta information, and signature.
</li>
</ul>
<ul empty="true" spacing="normal">
<li>
<ul empty="true" spacing="normal">
<li>Common aliases include: implicit digest.</li>
</ul>
</li>
</ul>
<t><strong>Selector:</strong></t>
<ul empty="true" spacing="normal">
<li>A mechanism (condition) to select an individual <xref
target="data_packet" format="none">Data packet</xref> from
a collection of Data packets that match a given Interest that
requests data using a prefix or exact <xref target="name" format="none"
>Name.</xref></li>
</ul>
<ul empty="true" spacing="normal">
<li>
<ul empty="true" spacing="normal">
<li>Common aliases include: interest selector, restrictor, interes
t restrictor.</li>
</ul>
</li>
</ul>
<t><strong>Nonce:</strong></t>
<ul empty="true" spacing="normal">
<li>A field of an <xref target="interest_packet"
format="none">Interest packet</xref> 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 <xref target="RFC4949"
format="default"/>.</li>
</ul>
<t><strong>Exact Name:</strong></t>
<ul empty="true" spacing="normal">
<li>A <xref target="name" format="none">Name</xref> that is encoded in
side a <xref target="data_packet"
format="none">Data packet</xref> and that typically uniquely
identifies this Data packet.</li>
</ul>
<t anchor="full_name"><strong>Full Name:</strong></t>
<ul empty="true" spacing="normal">
<li>An exact <xref target="name" format="none">Name</xref> with the Pa
cket ID of the corresponding <xref
target="data_packet" format="none">Data packet</xref>.</li>
</ul>
<t><strong>Prefix Name:</strong></t>
<ul empty="true" spacing="normal">
<li>A <xref target="name" format="none">Name</xref> that includes a pa
rtial sequence of Name components
(starting from the first one) of a Name encoded inside a <xref
target="data_packet" format="none">Data packet</xref>.</li>
</ul>
<ul empty="true" spacing="normal">
<li>
<ul empty="true" spacing="normal">
<li>Common aliases include: prefix.</li>
</ul>
</li>
</ul>
</section>
<section anchor="terms-related-to-name-usage" numbered="true" toc="default
">
<name>Terms Related to Name Usage</name>
<t><strong>Naming conventions:</strong></t>
<ul empty="true" spacing="normal">
<li>A convention, agreement, or specification for the <xref
target="data_packet" format="none">Data packet</xref> naming. a Naming
convention structures a namespace.</li>
</ul>
<ul empty="true" spacing="normal">
<li>
<ul empty="true" spacing="normal">
<li>Common aliases include: Naming scheme, ICN naming scheme, name
space convention.</li>
</ul>
</li>
</ul>
<t><strong>Hierarchically structured naming:</strong></t>
<ul empty="true" spacing="normal">
<li>The naming scheme that assigns and interprets a <xref
target="name" format="none">Name</xref> as a sequence of labels (Name c
omponents) with hierarchical structure without an assumption of a single adminis
trative root. A structure provides useful context information for the Name.</li>
</ul>
<ul empty="true" spacing="normal">
<li>
<ul empty="true" spacing="normal">
<li>Common aliases include: hierarchical naming, structured naming
.</li>
</ul>
</li>
</ul>
<t><strong>Flat naming:</strong></t>
<ul empty="true" spacing="normal">
<li>The naming scheme that assigns and interprets a <xref
target="name" format="none">Name</xref> as a single label (Name compone
nt) without any internal structure. This can be considered a special (or degener
ate) case of structured names.</li>
</ul>
<t><strong>Segmentation:</strong></t>
<ul empty="true" spacing="normal">
<li>A process of splitting large application content into a set of
uniquely named <xref target="data_packet" format="none">Data packets</
xref>. When using hierarchically structured
names, each created Data packet has a common prefix and an
additional component representing the segment (chunk) number.</li>
</ul>
<ul empty="true" spacing="normal">
<li>
<ul empty="true" spacing="normal">
<li>Common aliases include: chunking.</li>
</ul>
</li>
</ul>
<t><strong>Versioning:</strong></t>
<ul empty="true" spacing="normal">
<li>A process of assigning a unique <xref target="name"
format="none">Name</xref> to the revision of the content carried in
the <xref target="data_packet" format="none">Data
packet</xref>. 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).</li>
</ul>
<t><strong>Fragmentation:</strong></t>
<ul empty="true" spacing="normal">
<li>A process of splitting PDUs into Frames so that they can be transm
itted over a Layer 2 interface with a smaller MTU size.</li>
</ul>
</section>
<section anchor="terms-related-to-data-centric-security" numbered="true" t
oc="default">
<name>Terms Related to Data-Centric Security</name>
<t><strong>Data-Centric Security:</strong></t>
<ul empty="true" spacing="normal">
<li>A security property associated with the <xref
target="data_packet" format="none">Data packet</xref>, 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.</li>
</ul>
<ul empty="true" spacing="normal">
<li>
<ul empty="true" spacing="normal">
<li>Common aliases include: directly securing Data packet.</li>
</ul>
<section title="Data Transfer" anchor="data-transfer"> </li>
<t>The networking view of NDN and CCNx is that the request/reply protocol </ul>
implements a basic, unreliable data transfer service for single, named packets. <t><strong>Data Integrity</strong></t>
</t> <ul empty="true" spacing="normal">
<li>A cryptographic mechanism to ensure the consistency of the <xref
target="data_packet" format="none">Data
packet</xref> bits. The Data integrity property validates that the Dat
a
packet content has not been corrupted during transmission, e.g.,
over lossy or otherwise unreliable paths, or been subject to
deliberate modification.</li>
</ul>
<t><strong>Data Authenticity</strong></t>
<ul empty="true" spacing="normal">
<li>A cryptographic mechanism to ensure trustworthiness of a <xref
target="data_packet" format="none">Data
packet</xref> 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.</li>
</ul>
<t><strong>Data Confidentiality</strong></t>
<ul empty="true" spacing="normal">
<li>A cryptographic mechanism to ensure secrecy of a <xref
target="data_packet" format="none" >Data packet</xref>. Data
confidentiality includes separate mechanisms: <xref
target="content_confidentiality" format="none">Content
confidentiality</xref> and <xref target="name_confidentiality"
format="none">Name confidentiality</xref>.</li>
</ul>
<t anchor="content_confidentiality"><strong>Content Confidentiality</str
ong></t>
<ul empty="true" spacing="normal">
<li>A cryptographic mechanism to prevent an unauthorized party to
get access to the plain-text payload of a <xref target="data_packet"
format="none">Data packet</xref>. Can be
realized through encryption (symmetric, asymmetric, hybrid) and
proper distribution of the decryption keys to authorized
parties.</li>
</ul>
<t anchor="name_confidentiality"><strong>Name Confidentiality</strong></
t>
<ul empty="true" spacing="normal">
<li>A cryptographic mechanism to prevent an observer of
Interest-Data exchanges (e.g., intermediate router) from gaining
detailed meta information about the <xref target="data_packet" format=
"none">Data packet</xref>. This mechanism can
be realized using encryption (same as content confidentiality) or
obfuscation mechanisms.</li>
</ul>
</section>
</section> </section>
<section anchor="semantics-and-usage" numbered="true" toc="default">
<name>Semantics and Usage</name>
<t>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.</t>
<section anchor="data-transfer" numbered="true" toc="default">
<name>Data Transfer</name>
<t>The networking view of NDN and CCNx is that the request/reply
protocol implements a basic, unreliable data transfer service for
single, named packets.</t>
</section>
<section anchor="data-transport" numbered="true" toc="default">
<name>Data Transport</name>
<t>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.).</t>
</section>
<section anchor="lookup-service" numbered="true" toc="default">
<name>Lookup Service</name>
<t>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.</t>
</section>
<section anchor="database-access" numbered="true" toc="default">
<name>Database Access</name>
<t>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.</t>
</section>
<section anchor="remote-procedure-call" numbered="true" toc="default">
<name>Remote Procedure Call</name>
<t>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 <xref
target="RICE" format="default"/>. These capabilities can be further
extended into a full distributed computing infrastructure such as
that proposed in the ACM ICN paper <xref target="CFN"
format="default"/>.</t>
<section title="Data Transport" anchor="data-transport">
<t>Data transfer can be turned into a data transport service for applicat
ion-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).</t>
</section> </section>
<section anchor="publish-subscribe" numbered="true" toc="default">
<section title="Lookup Service" anchor="lookup-service"> <name>Publish/Subscribe</name>
<t>In a more distributed systems view of the basic request/reply protoco <t>The names as defined in this document for Interests and Data can
l, NDN and CCNx provide a distributed lookup service: given a key value (=name), refer to data collections to be subscribed and individual data objects
the service will return the corresponding value.</t> 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 <xref target="LESSONS-LEARNED"
format="default"/>.</t>
</section>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="default">
<section title="Database Access" anchor="database-access"> <name>IANA Considerations</name>
<t>A lookup service can be turned into a database access protocol by usin <t>This document has no IANA actions.</t>
g the namespace structure to specify names as access keys into a database. A nam
e prefix therefore stands for a collection or table of a database, while the res
t of the name specifies the query expression to be executed.</t>
</section> </section>
<section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name>
<t>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., <xref target="RFC8569" format="default"/> and <xref
target="NDN" format="default"/>) where various security considerations
are addressed in detail.</t>
<t>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 <xref
target="SCHEMATIZING-TRUST" format="default"/> for more information on
the approaches taken to formalize notions of trust for current NDN and
CCNx systems.</t>
</section>
</middle>
<back>
<section title="Remote Procedure Call" anchor="remote-procedure-call"> <references>
<t>The names as defined in this document for Interests and Data can refer <name>References</name>
to Remote Procedure call functions, their input arguments, and their results. F
or a comprehensive view of how to construct RPC or other remote invocation syste
ms, see the ACM ICN paper on <xref target="RICE"/>. These capabilities can be fu
rther extended into a full distributed computing infrastructure, such as that pr
oposed in the ACM ICN paper <xref target="CFN"/>.</t>
<!-->
<t><spanx style="strong">Interest match in FIB (longest prefix match)</sp
anx>:</t> <t><list style="empty">
<t>A process of finding a FIB entry with the longest Name (in ter
ms of Name components) that is a prefix of the specified Name.</t>
</list></t>
<t><spanx style="strong">Interest match in PIT (exact match)</spanx>:</t> <references>
<t><list style="empty"> <name>Normative References</name>
<t>A process of finding a PIT entry that stores the same Name as
specified in the Interest (including Interest restrictions, if any).</t>
</list></t>
<t><spanx style="strong">Data match in PIT (all match)</spanx>:</t> <reference anchor="NETINF" target="https://dl.acm.org/citation.cfm?id=24
<t><list style="empty"> 59643">
<t>A process of finding (a set of) PIT entries that can be satisf <front>
ied with the specified Data packet.</t> <title>Network of Information (NetInf) - An information-centric netw
</list></t> orking architecture</title>
<seriesInfo name="DOI" value="10.1016/j.comcom.2013.01.009"/>
<author surname="Dannewitz" initials="C."/>
<author surname="Kutscher" initials="D."/>
<author surname="Ohlman" initials="B."/>
<author surname="Farrell" initials="S."/>
<author surname="Ahlgren" initials="B."/>
<author surname="Holger" initials="K."/>
<date year="2013" month="April"/>
</front>
<refcontent>Computer Communications
</refcontent>
<refcontent>Volume 36, Issue 7
</refcontent>
</reference>
<t><spanx style="strong">Interest match in CS (any match)</spanx>:</t> <reference anchor="NDNTLV" target="https://named-data.net/doc/ndn-tlv/">
<t><list style="empty"> <front>
<t>A process of finding an entry in router’s Content Store that c <title>NDN Packet Format Specification</title>
an satisfy the specified Interest.</t> <author>
</list></t> <organization>Named Data Networking
</section> </organization>
<section title="Publish/Subscribe" anchor="publish-subscribe"> </author>
<t>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 publishe
d in a Publish-Subscribe application architecture. For a fully-worked example o
f how to construct such an ICN-based system, see the ACM ICN paper <xref target=
"LessonsLearned"/>.</t>
</section>
</section>
<section title="IANA Considerations" anchor="iana-considerations"> </front>
<t>There are no IANA considerations related to this document.</t> </reference>
</section>
<section title="Security Considerations" anchor="security-considerations"> <reference anchor="PSIRP" target="http://www.psirp.org/files/Deliverables/
<t>While the terms defined in this specification do not in and of themsel PSIRP-TR08-0001_Vision.pdf">
ves present new security considerations, the architectures which utilize the ter <front>
ms most certainly do. Readers should look at those specifications (e.g. <xref ta <title>From Design for Tussle to Tussle Networking: PSIRP Vision and
rget="RFC8569"/>, <xref target="NDN"/>) where various security considerations ar Use Cases</title>
e addressed in detail.</t> <author surname="Trossen" initials="D."/>
<author surname="Tuononen" initials="J"/>
<author surname="Xylomenos" initials="G."/>
<author surname="Sarela" initials="M."/>
<author surname="Zahemszky" initials="A."/>
<author surname="Nikander" initials="P."/>
<author surname="Rinta-aho" initials="T."/>
<date month="May" year="2008"/>
</front>
</reference>
<t>Some of the terms in this document use the words "trust", "trustworthy <reference anchor="MOBILITY-FIRST" target="https://dl.acm.org/citation.c
", or "trust model". We intend that these have their colloquial meanings, howeve fm?id=2412098">
r much work on trust, and specifically on trust schemas for ICN architectures ha <front>
s been published in the last few years. For example, it is useful to look at <xr <title>MobilityFirst: a robust and trustworthy mobility-centric arch
ef target="SchematizingTrust"/> for more information on the approachs taken to f itecture for the future internet</title>
ormalize notions of trust for current NDN and CCNx systems.</t> <seriesInfo name="DOI" value="10.1145/2412096.2412098"/>
</section> <author surname="Raychaudhuri" initials="D."/>
<author surname="Nagaraja" initials="K."/>
<author surname="Venkataramani" initials="A."/>
<date year="2012" month="July"/>
</front>
<refcontent>ACM SIGMOBILE
</refcontent>
<refcontent>Volume 16, Issue 3
</refcontent>
</reference>
</middle> <reference anchor="SCHEMATIZING-TRUST" target="https://dx.doi.org/10.114
<back> 5/2810156.2810170">
<references title="Informational References"> <front>
&RFC4838; <title>Schematizing Trust in Named Data Networking</title>
&RFC4949; <seriesInfo name="DOI" value="0.1145/2810156.2810170"/>
&RFC6234; <author surname="Yu" initials="Y."/>
<!-- &RFC8569; <author surname="Afanasyev" initials="A."/>
&RFC8609; --> <author surname="Clark" initials="D."/>
<author surname="Claffy" initials="K. C."/>
<author surname="Jacobson" initials="V."/>
<author surname="Zhang" initials="L."/>
<date month="September" year="2015"/>
</front>
<refcontent>ACM ICN
</refcontent>
</reference>
<reference anchor="RFC8569" target="https://www.rfc-editor.org/info/rfc8569"> <reference anchor="RICE" target="https://dx.doi.org/10.1145/3267955.3267
<front> 956">
<title>Content-Centric Networking (CCNx) Semantics</title> <front>
<author initials="M." surname="Mosko" fullname="M. Mosko"> <title>RICE: remote method invocation in ICN</title>
<organization/> <seriesInfo name="DOI" value="10.1145/3267955.3267956"/>
</author> <author surname="Krol" initials="M."/>
<author initials="I." surname="Solis" fullname="I. Solis"> <author surname="Habak" initials="K."/>
<organization/> <author surname="Kutscher" initials="D."/>
</author> <author surname="Oran" initials="D."/>
<author initials="C." surname="Wood" fullname="C. Wood"> <author surname="Psaras" initials="I."/>
<organization/> <date month="September" year="2018"/>
</author> </front>
<date year="2019" month="July"/> <refcontent>ACM ICN
<abstract> </refcontent>
<t> </reference>
This document describes the core concepts of the Content-Centric Networking (CCN
x) architecture and presents a network protocol based on two messages: Interests
and Content Objects. It specifies the set of mandatory and optional fields with
in those messages and describes their behavior and interpretation. This architec
ture and protocol specification is independent of a specific wire encoding.
</t>
<t>
The protocol also uses a control message called an Interest Return, whereby one
system can return an Interest message to the previous hop due to an error condit
ion. This indicates to the previous hop that the current system will not respond
to the Interest.
</t>
<t>
This document is a product of the Information-Centric Networking Research Group
(ICNRG). The document received wide review among ICNRG participants. Two full im
plementations are in active use and have informed the technical maturity of the
protocol specification.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8569"/>
<seriesInfo name="DOI" value="10.17487/RFC8569"/>
</reference>
<reference anchor="RFC8609" target="https://www.rfc-editor.org/info/rfc8609">
<front>
<title>
Content-Centric Networking (CCNx) Messages in TLV Format
</title>
<author initials="M." surname="Mosko" fullname="M. Mosko">
<organization/>
</author>
<author initials="I." surname="Solis" fullname="I. Solis">
<organization/>
</author>
<author initials="C." surname="Wood" fullname="C. Wood">
<organization/>
</author>
<date year="2019" month="July"/>
<abstract>
<t>
Content-Centric Networking (CCNx) is a network protocol that uses a hierarchical
name to forward requests and to match responses to requests. This document spec
ifies the encoding of CCNx messages in a TLV packet format, including the TLV ty
pes used by each message element and the encoding of each value. The semantics o
f CCNx messages follow the encoding-independent CCNx Semantics specification.
</t>
<t>
This document is a product of the Information Centric Networking research group
(ICNRG). The document received wide review among ICNRG participants and has two
full implementations currently in active use, which have informed the technical
maturity of the protocol specification.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8609"/>
<seriesInfo name="DOI" value="10.17487/RFC8609"/>
</reference>
<reference anchor="NDN" target="https://named-data.net/project/ex <reference anchor="CFN" target="https://dl.acm.org/citation.cfm?id=33573
ecsummary/"> 95">
<front> <front>
<title>Named Data Networking</title> <title>Compute First Networking: Distributed Computing meets ICN</ti
<author surname="NDN team"/> tle>
<date year="various"/> <seriesInfo name="DOI" value="10.1145/3357150.3357395"/>
</front> <author surname="Krol" initials="M."/>
</reference> <author surname="Mastorakis" initials="S."/>
<author surname="Kutscher" initials="D."/>
<author surname="Oran" initials="D."/>
<date month="September" year="2019"/>
</front>
<refcontent>ACM ICN
</refcontent>
</reference>
</references> <reference anchor="LESSONS-LEARNED" target="https://dl.acm.org/citation.
cfm?id=3357397">
<front>
<title>Lessons Learned Building a Secure Network Measurement Framewo
rk using Basic NDN</title>
<seriesInfo name="DOI" value="10.1145/3357150.3357397"/>
<author surname="Nichols" initials="K"/>
<date month="September" year="2019"/>
</front>
<refcontent>ACM ICN
</refcontent>
</reference>
</references>
<references title="Bibliography"> <references>
&RFC7476; <name>Informative References</name>
&RFC7927; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC7945; FC.4838.xml"/>
&RFC7933; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&I-D.irtf-icnrg-disaster; FC.4949.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6234.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8569.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8609.xml"/>
<reference anchor="NDNTLV" target="http://named-data.net/doc/ndn- <reference anchor="NDN" target="https://named-data.net/project/execsummar
tlv/"> y/">
<front> <front>
<title>NDN Packet Format Specification</title> <title>Named Data Networking: Executive Summary</title>
<author surname="NDN Project Team"/> <author>
<date year="2016"/> <organization>Named Data Networking
</front> </organization>
</reference> </author>
<date month="September" year="2010"/>
</front>
</reference>
</references>
<reference anchor="Netinf" target="https://dl.acm.org/citation.cfm?id=245 </references>
9643">
<front>
<title>Network of Information (NetInf) - An information-c
entric networking architecture, in Computer Communications, Volume 36, Issue 7</
title>
<author surname="Dannewitz" initials="C."/>
<author surname="Kutscher" initials="D."/>
<author surname="Ohlman" initials="B."/>
<author surname="Farrell" initials="S."/>
<author surname="Ahlgren" initials="B."/>
<author surname="Holger" initials="K."/>
<date year="2013" month="April"/>
</front>
<seriesInfo name="DOI" value="10.1016/j.comcom.2013.01.009"/>
</reference>
<reference anchor="PSIRP" target="http://www.psirp.org/files/Deli <section anchor="acknowledgements" numbered="false" toc="default">
verables/PSIRP-TR08-0001_Vision.pdf"> <name>Acknowledgments</name>
<front> <t><contact fullname="Marc Mosko"/> provided much guidance and helpful
<title>From Design for Tussle to Tussle Networkin precision in getting these terms carefully formed and the definitions
g: PSIRP Vision and Use Cases</title> precise. <contact fullname="Marie-Jose Montpetit"/> did a thorough IRSG re
<author surname="Trossen" initials="D."/> view, which helped a
<author surname="Tuononen" initials="J"/> lot to improve the text. Further comments during the IRSG Poll from
<author surname="Xylomenos" initials="G."/> <contact fullname="Stephen Farrell"/>, <contact fullname="Ari
<author surname="Sarela" initials="M."/> Keraenen"/>, <contact fullname="Spencer Dawkins"/>, <contact fullname="Car
<author surname="Zahemszky" initials="A."/> sten Bormann"/>, and
<author surname="Nikander" initials="P."/> <contact fullname="Brian Trammell"/> further improved the document. Additi
<author surname="Rinta-aho" initials="T."/> onal helpful
<date year="2008"/> comments were received as part of the IESG conflict review from <contact f
</front> ullname="Mirja
</reference> Kuehlewind"/> and <contact fullname="Benjamin Kaduk"/>.</t>
</section>
<reference anchor="MobilityFirst" target="https://dl.acm.org/cita <!-- [rfced] FYI: The following references are not used and have been removed
tion.cfm?id=2412098"> from this document. Please let us know if these should be included throughout
<front> the document.
<title>MobilityFirst: a robust and trustworthy mo
bility-centric architecture for the future internet, in ACM SIGMOBILE, Volume 16
, Issue 3</title>
<author surname="Raychaudhuri" initials="D."/>
<author surname="Nagaraja" initials="K."/>
<author surname="Venkataramani" initials="V."/>
<date year="2012" month="July"/>
</front>
<seriesInfo name="DOI" value="10.1145/2412096.2412098"/>
</reference>
<reference anchor="SchematizingTrust" target="http://dx.doi.org/10.1145/2 [ICNRG-DISASTER]
810156.2810170"> [NDNTLV]
<front> [RFC7476]
<title>Schematizing Trust in Named Data Networking, in AC [RFC7927]
M ICN'15</title> [RFC7933]
<author surname="Yu" initials="Y."/> [RFC7945]
<author surname="Afanasyev" initials="A."/> [RFC8609]
<author surname="Clark" initials="D."/>
<author surname="Claffy" initials="kc."/>
<author surname="Jacobson" initials="V."/>
<author surname="Zhang" initials="L."/>
<date year="2015"/>
</front>
<seriesInfo name="DOI" value="0.1145/2810156.2810170"/>
</reference>
<reference anchor="RICE" target="http://dx.doi.org/10.1145/3267955.326795 How about in Intro:
6">
<front>
<title>RICE: remote method invocation in ICN, in ACM ICN'
18</title>
<author surname="Krol" initials="m."/>
<author surname="Habak" initials="K."/>
<author surname="Kutscher" initials="D."/>
<author surname="Oran" initials="D."/>
<date year="2018"/>
</front>
<seriesInfo name="DOI" value="10.1145/3267955.3267956"/>
</reference>
<reference anchor="CFN" target="https://dl.acm.org/citation.cfm?id=335739 The goal of this document is to collect the key terms with a corresponding
5"> definition as they are used in the CCNx [8609] and NDN [NDNTLV] projects.
<front>
<title>Compute First Networking: Distributed Computing me
ets ICN, in ACM ICN'19</title>
<author surname="Krol" initials="m."/>
<author surname="Mastorakis" initials="S."/>
<author surname="Kutscher" initials="D."/>
<author surname="Oran" initials="D."/>
<date year="2019"/>
</front>
<seriesInfo name="DOI" value="10.1145/3357150.3357395"/>
</reference>
<reference anchor="LessonsLearned" target="https://dl.acm.org/citation.cf -->
m?id=3357397">
<front>
<title>Lessons Learned Building a Secure Network
Measurement Framework using Basic NDN, in ACM ICN'19</title>
<author surname="Nichols" initials="K"/>
<date year="2019"/>
</front>
<seriesInfo name="DOI" value="10.1145/3357150.3357397"/>
</reference>
</references> </back>
<section anchor="acknowledgements" title="Acknowledgments">
<t>Marc Mosko provided much guidance and helpful precision in getting thes
e terms carefully formed and the definitions precise. Marie-José Montpetit did a
thorough IRSG review, which helped a lot to improve the text. Further comments
during the IRSG Poll from Stephen Farrell, Ari Keränen, Spencer Dawkins, Carsten
Bormann, and Brian Trammell further improved the document. Additional helpful c
omments were received as part of IESG conflict review from Mirja Kuehlewind and
Benjamin Kaduk.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 51 change blocks. 
1052 lines changed or deleted 1058 lines changed or added

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