Architectural Considerations of Information-Centric Networking (ICN) Using a Name Resolution ServiceETRI218 Gajeong-roYuseung-GuDaejeon34129Republic of Koreajhong@etri.re.krETRI218 Gajeong-roYuseung-GuDaejeon34129Republic of Koreatwyou@etri.re.krNICT4-2-1 Nukui-KitamachiKoganeiTokyo184-8795Japankafle@nict.go.jpInformation-Centric NetworkingInformation-Centric NetworkingName Resolution ServiceName to location mapping
This document describes architectural considerations and implications
related to the use of a Name Resolution Service (NRS) in Information-Centric Networking (ICN).
It explains how the ICN architecture can change when an NRS is utilized
and how its use influences the ICN routing system. This document is a product
of the Information-Centric Networking Research Group (ICNRG).
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Research Task Force
(IRTF). The IRTF publishes the results of Internet-related
research and development activities. These results might not be
suitable for deployment. This RFC represents the consensus of the Information-Centric Networking
Research Group of the Internet Research Task Force (IRTF).
Documents approved for publication by the IRSG are not
candidates for any level of Internet Standard; see Section 2 of RFC
7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Table of Contents
. Introduction
. Terminology
. Background
. Implications of an NRS in ICN
. ICN Architectural Considerations for NRS
. Name Mapping Records Registration, Resolution, and Update
. Protocols and Semantics
. Routing System
. Conclusion
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgements
Authors' Addresses
Introduction
Information-Centric Networking (ICN) is an approach to evolving the
Internet infrastructure to provide direct access to Named Data
Objects (NDOs) by names. In two common ICN architectures, Named Data
Networking (NDN) and
Content-Centric Networking (CCNx) , the name of an NDO is used directly to route a
request to retrieve the data object. Such direct name-based routing
has inherent challenges in enabling a globally scalable routing
system, accommodating producer mobility, and supporting off-path
caching. These specific issues are discussed in detail in . In order to address these challenges, a Name
Resolution Service (NRS) has been utilized in the literature as well
as the proposals of several ICN projects .
This document describes the potential changes in the ICN
architecture caused by the introduction of an NRS and the
corresponding implication to the ICN routing system. It also
describes ICN architectural considerations for the integration of an
NRS. The scope of this document includes considerations from the
perspective of an ICN architecture and routing system when using an NRS
in ICN. A description of the NRS itself is provided in the companion
NRS design considerations document , which provides the NRS approaches, functions, and
design considerations.
This document represents the consensus of the Information-Centric
Networking Research Group (ICNRG). It has been reviewed extensively
by the Research Group (RG) members who are actively involved in the
research and development of the technology covered by this document.
It is not an IETF product and is not a standard.
Terminology
Name Resolution Service (NRS):
An NRS in ICN is defined as a service that provides the function
of translating a content name or a data object name into some other
information such as a routable prefix, a locator, an off-path-cache
pointer, or an alias name that is more amenable than the input name to
forwarding the object request toward the target destination storing
the NDO . An NRS is most
likely implemented through the use of a distributed mapping database
system. The Domain Name System (DNS) may be used as an NRS. However, in
this case, the requirements of frequent updates of NRS records due to
the creations of a lot of new NDOs and changes in their locations in
the network need to be considered.
NRS server:
An NRS comprises the distributed NRS servers storing the mapping
records in their databases. NRS servers store and maintain the
mapping records that keep the mappings of content or object name to
some other information that is used for forwarding the content request
or the content itself.
NRS resolver:
The client-side function of an NRS is called an NRS resolver. The
NRS resolver is responsible for initiating name resolution request
queries that ultimately lead to a name resolution of the target data
objects. NRS resolvers can be located in the consumer (or client)
nodes and/or ICN routers. An NRS resolver may also cache the mapping
records obtained through the name resolution for later usage.
Name registration:
In order to populate the NRS, the content names and their mapping
records must be registered in the NRS system by a publisher who has
access rights to at least one authoritative NRS server or by a producer
who generates named data objects. The records contain the mapping of
an object name to some information such as other alias names, routable
prefixes, and locators, which are used for forwarding the content
request. Thus, a publisher or producer of content creates an NRS
registration request and sends it to an NRS server. On registration,
the NRS server stores (or updates) the name mapping record in the
database and sends an acknowledgement back to the producer or
publisher that made the registration request.
Name resolution:
Name resolution is the main function of the NRS system. It is
performed by an NRS resolver, which can be deployed on a consumer node
or an ICN router. Resolvers are responsible for either returning a
cached mapping record (whose lifetime has not expired) or
alternatively sending a name resolution request toward an NRS server.
The NRS server searches for the content name in its mapping record
database and, if found, retrieves the mapping record and returns it in
a name resolution response message to the NRS resolver.
NRS node:
NRS servers are also referred to as NRS nodes that maintain the
name records. The terms are used interchangeably.
NRS client:
A node that uses the NRS is called an NRS client. Any node that
initiates a name registration, resolution, or update procedure is an
NRS client; that is, NRS resolvers, ICN client nodes, ICN routers, or
producers can be NRS clients.
Background
A pure name-based routing approach in ICN has inherent challenges in enabling
a globally scalable routing system, accommodating producer mobility, and
supporting off-path caching. In order to address these challenges, an NRS
has been utilized in proposals and literature of several ICN projects as follows:
Routing scalability:
In ICN, application names identifying content are intended to be
used directly for packet delivery, so ICN routers run a name-based
routing protocol to build name-based routing and forwarding tables.
Similar to the scalability challenge of IP routing, if
non-aggregatable name prefixes are injected into the Default Route
Free Zone (DFZ) of ICN routers, they would be driving the uncontrolled
growth of the DFZ routing table size. Thus, providing the level of
indirection enabled by an NRS in ICN can be an approach to keeping the
routing table size under control. The NRS system resolves name
prefixes that do not exist in the DFZ forwarding table into globally
routable prefixes such as the one proposed in NDN . Another approach dealing with routing scalability
is the Multi-level Distributed Hash Table (MDHT) used in NetInf . It provides name-based anycast
routing that can support a non-hierarchical namespace and can be
adopted on a global scale .
Producer mobility:
In ICN, if a producer moves into a different name domain that uses
a different name prefix, the request for a content produced by the
moving producer with the origin content name must be forwarded to the
moving producer's new location. Especially in a hierarchical naming
scheme, producer mobility support is much harder than in a flat naming
scheme since the routing tables in a broader area need to be updated
to track the producer movement. Therefore, various ICN architectures
such as NetInf and
MobilityFirst have adopted NRS
systems to tackle the issues of producers whose location changes.
Off-path caching:
In-network caching is a common feature of an ICN architecture.
Caching approaches can be categorized into on-path caching and
off-path caching, according to the location of caches in relation to
the forwarding path from the original content store to a consumer.
Off-path caching, sometimes also referred to as content replication or
content storing, aims to replicate a Named Data Object in various
locations within a network in order to increase the availability of
content, reduce access latency, or both. These caching locations may
not be lying along the content forwarding path. Thus, finding
off-path cached content requires more complex forwarding procedures
if a pure name-based routing is employed. In order to support access
to off-path caches, the locations of replicas are usually advertised
into a name-based routing system or into an NRS as described in .
This document discusses architectural considerations and implications
of ICN when an NRS is utilized to solve such challenges facing a name-based
routing in ICN.
Implications of an NRS in ICN
An NRS is not a mandatory part of an ICN architecture, as the majority
of ICN architectures uses name-based routing that avoids the need for
a name resolution procedure. Therefore, the utilization of an NRS in
an ICN architecture changes some architectural aspects at least with
respect to forwarding procedures, latency, and security, as discussed below:
Forwarding procedure:
When an NRS is included in an ICN architecture, the name
resolution procedure has to be included in the ICN overall routing and
forwarding architectural procedures. To integrate an NRS into an ICN
architecture, there are certain things that have to be decided and
specified such as where, when, and how the name resolution task is
performed.
Latency:
When an NRS is included in an ICN architecture, additional latency
introduced by the name resolution process is incurred by the routing
and forwarding system. Although the latency due to the name
resolution is added, the total latency of individual requests being
served could be lower if the nearest copies or off-path caches can be
located by the NRS lookup procedure. Additionally, there might be a
favorable trade-off between the name resolution latency and
inter-domain traffic reduction by finding the nearest off-path cached
copy of the content. Finding the nearest cache holding the content
might significantly reduce the content discovery as well as delivery
latency.
Security:
When any new component such as an NRS is introduced in the ICN
architecture, the attack surface may increase. Protection of the NRS
system itself against attacks such as Distributed Denial of Service
(DDoS) and spoofing or alteration of name mapping records and related
signaling messages may be challenging.
ICN Architectural Considerations for NRS
This section discusses the various items that can be considered from
the perspective of ICN architecture when employing an NRS system.
These items are related to the registration, resolution, and update of
name mapping records, protocols and messages, and integration with the
routing system.
Name Mapping Records Registration, Resolution, and Update
When an NRS is integrated in ICN architecture, the functions related to
the registration, resolution, and update of name mapping records have to
be considered. The NRS nodes maintain the name mapping records and may
exist as an overlay network over the ICN routers, that is, they communicate
to each other through ICN routers. shows the NRS nodes and NRS
clients connected through an underlying network. The NRS nodes should be
deployed in such a manner that an NRS node is always available at a short distance from
an NRS client so that communication latency for the name registration and
resolution requested by the NRS client remains very low. The name registration,
name resolution, and name record update procedures are briefly discussed below.
Name registration:
Name registration is performed by the producer (as an
NRS client) when it creates a new content. When a producer creates content
and assigns a name from its name prefix space to the content, the producer
performs the name registration in an NRS node. Name registration may be
performed by an ICN router when the ICN architecture supports off-path caching
or cooperative caching since involving an NRS may be a good idea for off-path
caching. The ICN routers with forwarder caches do not require name
registration for their cached content because they lie on the path toward an
upstream content store or producer. They will be hit when a future request is
forwarded to the content producer by an ICN router lying downstream toward the
ICN client node. However, ICN routers performing off-path caching of content
must invoke the name registration procedure so that other ICN routers can
depend on name resolutions to know about the off-path cache locations. If a
content gets cached in many off-path ICN routers, all of them may register the
same content names in the same NRS node, resulting in multiple registration
actions. In this case, the NRS node adds the new location of the content to
the name record together with the previous locations. In this way, each of the
name records stored in the NRS node may contain multiple locations of the
content. Assigning validity time or a lifetime of each mapping record may be
considered especially for the off-path caching content and managing mobility.
Name resolution:
Name resolution is performed by an NRS client to obtain the name record
from an NRS node by sending a name resolution request message and getting a
response containing the record. In the name-based ICN routing context, the
name resolution is needed by any ICN router whose forwarding information base
(FIB) does not contain the requested name prefix. Name resolution may also be
performed by the consumer (especially in the case where the consumer is
multihomed) to forward the content request in a better direction so that it
obtains the content from the nearest cache. If the consumer is single homed,
it may not bother to perform name resolution, instead depending on either
straightforward name-based routing or name resolution by an upstream ICN
router. In this case, the consumer creates the content request packet
containing the content name and forwards to the nearest ICN router. The ICN
router checks its FIB table to see where to forward the content request. If
the ICN router fails to identify whether the requested content is reachable,
it performs name resolution to obtain the name mapping record and adds this
information to its FIB. The ICN router may also perform name resolution even
before the arrival of a content request to use the name mapping record to
configure its FIB.
Name record update:
Name record update is carried out when a content name mapping record
changes, e.g., the content is not available in one or more of the previous
locations. The name record update includes the substitution and deletion of
the name mapping records. The name record update may take place explicitly by
the exchange of name record update messages or implicitly when a timeout
occurs and a name record is deemed to be invalid. The implicit update is
possible when each record is accompanied by a lifetime value. The lifetime
can be renewed only by the authoritative producer or node. The cached mapping
records get erased after the lifetime expires unless a lifetime extension
indication is obtained from the authoritative producer.
Protocols and Semantics
In order to develop an NRS system within a local ICN network domain or
global ICN network domain, new protocols and semantics must be designed
and implemented to manage and resolve names among different namespaces.
One way of implementing an NRS for CCNx is by extending the basic TLV
format and semantics .
For instance, name resolution and response messages can be implemented
by defining new type fields in the Interest and Content Object
messages . By leveraging the existing CCNx
Interest and Content Object packets for name resolution and registration,
the NRS system can be deployed with a few ICN protocol changes. However,
because of confining the changes to the basic ICN protocol and semantics,
the NRS system may not be able to exploit more flexible and scalable designs.
On the other hand, an NRS system can be designed independently with its
own protocol and semantics like the NRS system described in .
For instance, the NRS protocol and messages can be implemented by using
a RESTful API, and the NRS can be operated as an application protocol
independent of the rest of the ICN protocol.
Routing System
An NRS reduces the routing complexity of ICN architecture compared to pure
name-based routing. It does so by permitting the routing system to update
the routing table on demand with the help of name records obtained
from NRS. The routing system therefore needs to make name resolution
requests and process the information returned, such as a prefix, a locator, an
off-path-cache pointer, or an alias name, obtained from the name resolution.
No matter what kind of information is obtained from the name resolution,
as long as it is in the form of a name, the content request message in
the routing system may be reformatted with the obtained information.
In this case, the content name requested originally by a consumer needs
to be involved in the reformatted content request to check the integrity
of the binding between the name and the requested content. In other words,
the information obtained from the name resolution is used to forward
the content request, and the original content name requested by a consumer
is used to identify the content. Alternatively, the resolved information
may be used to build the routing table.
The information obtained from name resolution may not be in the form of
a name. For example, it may identify tunnel endpoints by IP address
and instead be used to construct an IP protocol tunnel through which
to forward the content request.
Conclusion
A Name Resolution Service (NRS) is not a mandatory part in an ICN architecture,
as the majority of ICN architectures use name-based routing that does not
employ a name resolution procedure. However, such name-based routing in ICN
has inherent challenges in enabling a globally scalable routing system,
accommodating producer mobility, and supporting off-path caching.
In order to address these challenges, an NRS system has been introduced in
several ICN projects. Therefore, this document describes how the ICN architecture
changes when an NRS is utilized and how this affects the ICN routing system.
The document defines a few terminologies related to an NRS and explains
some inherent challenges of pure name-based routing in ICN such as routing
scalability, producer mobility, and off-path caching. This document describes
how the ICN architecture would change with respect to procedures, latency,
and security when an NRS is utilized. According to the ICN architectural
changes, this document describes ICN architectural considerations for NRS
such as the functions related to the registration, resolution and update
of name mapping records, protocols and semantics to implement an NRS system,
and the routing system involving the name resolution.
IANA ConsiderationsThis document has no IANA actions.Security Considerations
When any new component such as an NRS is introduced in the ICN architecture,
the attack surface increases. The related security vulnerability issues
are discussed below:
Namespace security:
In order to deploy an NRS system in ICN architecture, ICN namespaces,
which may be assigned by authoritative entities, must be securely mapped to
the content publishers and securely managed by them. According to the ICN
research challenges , a new namespace can also provide an integrity verification function to authenticate its
publisher. The issues of namespace authentication and the mapping among
different namespaces require further investigation.
NRS system security:
An NRS requires the deployment of new entities (e.g., NRS servers) to
build distributed and scalable NRS systems. Thus, the entities, e.g., an NRS
server maintaining a mapping database, could be the focus of attacks by
receiving malicious requests from innumerable adversaries comprising of
Denial-of-Service or Distributed-Denial-of-Service attacks. In addition, NRS
clients in general must trust the NRS nodes in other network domains to some
degree, and communication among them must also be protected securely to prevent
malicious entities from participating in this communication. The history of
name resolution data requires to be stored and analyzed as in passive DNS to
uncover potential security incidents or discover malicious infrastructures.
NRS protocol and message security:
In an NRS system, the protocols to generate, transmit, and receive NRS
messages related to the name registration, resolution, and record update
should be protected by proper security mechanisms. Proper security measures
must be provided so that only legitimate nodes can initiate and read NRS
messages. These messages must be secured by integrity protection and
authentication mechanisms so that unauthorized parties cannot manipulate them
when being forwarded through the network. Security measures to encrypt these
messages should also be developed to thwart all threats to both security and
privacy. Numerous problems similar to the security issues of an IP network and
DNS can affect the overall ICN architecture. The DNS QNAME minimization type
of approach would be suitable for preserving privacy in the name resolution
process. Therefore, security mechanisms such as accessibility,
authentication, etc., for the NRS system should be considered to protect not only the NRS system but
also the ICN architecture overall.
ReferencesNormative ReferencesInformation-Centric Networking (ICN) Research ChallengesThis 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 the subject of ongoing 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).Content-Centric Networking (CCNx) SemanticsThis document describes the core concepts of the Content-Centric Networking (CCNx) architecture and presents a 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 Interest Return, 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.This document is a product of the Information-Centric Networking Research Group (ICNRG). The document received wide review among ICNRG participants. Two full implementations are in active use and have informed the technical maturity of the protocol specification.Content-Centric Networking (CCNx) Messages in TLV FormatContent-Centric Networking (CCNx) is a network protocol that uses a hierarchical name to forward requests and to match responses to requests. This document specifies the encoding of CCNx messages in a TLV packet format, including the TLV types used by each message element and the encoding of each value. The semantics of CCNx messages follow the encoding-independent CCNx Semantics specification.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.Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)This document provides the functionalities and design considerations for a Name Resolution Service (NRS) in Information-Centric Networking (ICN). The purpose of an NRS in ICN is to translate an object name into some other information such as a locator, another name, etc. in order to forward the object request. This document is a product of the Information-Centric Networking Research Group (ICNRG).Informative ReferencesSNAMP: Secure namespace mapping to scale NDN forwarding2015 IEEE Conference on Computer Communications
Workshops (INFOCOM WKSHPS)On Content Indexing for Off-Path Caching in Information-Centric NetworksACM ICNCicnCCNx Extension for Name Resolution ServiceETRIETRIETRI This document presents the CCNx extension for Name Resolution Service
(NRS). It describes TLV-based CCNx messages for NRS and modification
of CCNx forwarder where the messages for NRS are working.
Work in ProgressNetwork of Information (NetInf) - An information-centric networking architectureComputer Communications vol. 36, issue 7Hierarchical DHT-based name resolution for information-centric networksComputer Communications vol. 36, issue 7Demonstrating a Scalable Name Resolution System for Information-Centric NetworkingACM ICNMobilityFirstFuture Internet Architecture (FIA)Named Data NetworkingNDNForwarding Label support in CCN ProtocolHuawei TechnologiesHuawei TechnologiesHuawei Technologies The objective of this proposal is to enable application identifier
(AI) and network identifier (NI) split in the CCN protocol that has
several applications such as towards Interest routing optimization,
mobility, conversational session support, handling indirections in
manifests, and routing scalability. We enable this through the
notion of forwarding label object (FLO), which is an optional hop-by-
hop payload in the Interest message with a topological name which
identifies a network domain, router or a host. FLO can be inserted
by the end user applications or by the network. FLO is processed by
the network resulting in either terminating it or swapping it with a
new FLO based on the network service context. Furthermore, depending
on the application and trust context, a FLO can be subjected to
policy based actions by the forwarders such as invoking security
verification or enabling other FLO management actions.
Work in ProgressScalable and Adaptive Internet Solutions (SAIL)A Survey of Mobility Support in Named Data NetworkingNamed Data NetworkingWorkshop on Name-Oriented Mobility: Architecture,
Algorithms and Applications (NOM)Acknowledgements
The authors would like to thank (ICNRG Co-chair)
for very useful reviews and comments, which helped to
immeasurably improve this document.
Authors' AddressesETRI218 Gajeong-roYuseung-GuDaejeon34129Republic of Koreajhong@etri.re.krETRI218 Gajeong-roYuseung-GuDaejeon34129Republic of Koreatwyou@etri.re.krNICT4-2-1 Nukui-KitamachiKoganeiTokyo184-8795Japankafle@nict.go.jp