Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)ETRIYuseung-Gu218 Gajeong-roDaejeon34129Republic of Koreajhong@etri.re.krETRIYuseung-Gu218 Gajeong-roDaejeon34129Republic of Koreatwyou@etri.re.krFuturewei Technologies Inc.10180 Telesis CourtSan DiegoCA92121United States of Americalijun.dong@futurewei.comFuturewei Technologies Inc.2330 Central ExpresswaySanta ClaraCA95050United States of Americacedric.westphal@futurewei.comEricsson ResearchStockholm16480SwedenBorje.Ohlman@ericsson.com
ICNRG
Information-Centric Networking
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).
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) 2021 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
. Name Resolution Service in ICN
. Explicit Name Resolution Approach
. Name-Based Routing Approach
. Hybrid Approach
. Comparisons of Name Resolution Approaches
. Functionalities of NRS in ICN
. Support Heterogeneous Name Types
. Support Producer Mobility
. Support Scalable Routing System
. Support Off-Path Caching
. Support Nameless Object
. Support Manifest
. Support Metadata
. Design Considerations for NRS in ICN
. Resolution Response Time
. Response Accuracy
. Resolution Guarantee
. Resolution Fairness
. Scalability
. Manageability
. Deployed System
. Fault Tolerance
. Security and Privacy
. Confidentiality
. Authentication
. Integrity
. Resiliency and Availability
. Conclusion
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgements
Authors' Addresses
Introduction
The current Internet is based upon a host-centric networking paradigm, where hosts are
identified with IP addresses and communication is possible
between any pair of hosts. Thus, information in the current Internet
is identified by the name of the host (or server) where the information is stored.
In contrast to host-centric networking, the primary communication
objects in Information-Centric Networking (ICN) are the named data
objects (NDOs), and they are uniquely identified by location-independent
names. Thus, ICN aims for the efficient dissemination and retrieval of
NDOs at a global scale and has been identified and acknowledged as a
promising technology for a future Internet architecture to overcome
the limitations of the current Internet, such as scalability and
mobility .
ICN also has emerged as a candidate architecture in the Internet of Things (IoT) environment
since IoT focuses on data and information
.
Since naming data independently from its current location (where it is
stored) is a primary concept of ICN, how to find any NDO using a
location-independent name is one of the most important design challenges
in ICN. Such ICN routing may comprise three steps :
Name resolution: matches/translates a content name to the locator
of the content producer or source that can provide the content.
Content request routing: routes the content request towards
the content's location based either on its name or locator.
Content delivery: transfers the content to the requester.
Among the three steps of ICN routing, this document investigates only
the name resolution step, which translates a content name to the content locator.
In addition, this document covers various possible types of name
resolution in ICN such as one name to another name, name to locator,
name to manifest, name to metadata, etc.
The focus of this document is a Name Resolution Service (NRS) itself
as a service or a system in ICN, and it provides the functionalities and
the design considerations for an NRS in ICN as well as the overview of
the NRS approaches in ICN. On the other hand, its companion document
describes considerations from the perspective
of the ICN architecture and routing system when using an NRS in ICN.
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.
Name Resolution Service in ICN
A Name Resolution Service (NRS) in ICN is defined as the service that
provides the name resolution function for translating an object name
into some other information such as a locator, another name, metadata,
next-hop info, etc. that is used for forwarding the object request.
In other words, an NRS is a service that can be provided by the ICN
infrastructure to help a consumer reach a specific piece of information
(or named data object). The consumer provides an NRS with a persistent
name, and the NRS returns a name or locator (or potentially multiple
names and locators) that can reach a current instance of the
requested object.
The name resolution is a necessary process in ICN routing, although the
name resolution either can be separated from the content request routing
as an explicit process or can be integrated with the content request
routing as an implicit process. The former is referred to as an "explicit name
resolution approach", and the latter is referred to as a "name-based routing approach"
in this document.
Explicit Name Resolution Approach
An NRS could take the explicit name resolution approach to return the
locators of the content to the client, which will be used by the underlying
network as the identifier to route the client's request to one of the
producers or to a copy of the content. There are several ICN projects
that use the explicit name resolution approach, such as Data-Oriented Network Architecture (DONA) , PURSUIT ,
Network of Information (NetInf) , MobilityFirst ,
IDNet , etc. In addition, the explicit name
resolution approach has been allowed for 5G control planes .
Name-Based Routing ApproachAn NRS could take the name-based routing approach, which integrates
name resolution with content request message routing as in
Named Data Networking / Content-Centric Networking (NDN/CCNx) .
In cases where the content request also specifies the reverse path,
as in NDN/CCNx, the name resolution mechanism also derives the routing
path for the data. This adds a requirement to the name resolution
service to propagate the request in a way that is consistent with the
subsequent data forwarding. Namely, the request must select a path
for the data based upon finding a copy of the content but also
properly delivering the data.
Hybrid Approach
An NRS could also take hybrid approach. For instance, it can attempt
the name-based routing approach first. If this fails at a certain
router, the router can go back to the explicit name resolution approach.
The hybrid NRS approach also works the other way around: first by performing
explicit name resolution to find the locators of routers, then by routing the client's request using the name-based routing approach.
A hybrid approach would combine name resolution over a subset of
routers on the path with some tunneling in between (say, across an
administrative domain) so that only a few of the nodes in the ICN
network perform name resolution in the name-based routing approach.
Comparisons of Name Resolution Approaches
The following compares the explicit name resolution and the name-based
routing approaches in several aspects:
Overhead due to the maintenance of the content location:
The content reachability is dynamic and includes new
content being cached or content being expired from a cache,
content producer mobility, etc. Maintaining a consistent
view of the content location across the network requires
some overhead that differs for the name resolution approaches.
The name-based routing approach may require flooding
parts of the network for update propagation. In the worst
case, the name-based routing approach may flood the whole network
(but mitigating techniques may be used to scope the flooding).
However, the explicit name resolution approach only requires
updating propagation in part of the name resolution system
(which could be an overlay with a limited number of nodes).
Resolution capability: The explicit name resolution approach, if designed and deployed with sufficient robustness, can offer at least weak guarantees that resolution will succeed for any content name in the network if it is registered to the name resolution overlay.
In the name-based routing approach, content resolution depends on the flooding scope of the content names (i.e., content publishing message and the resulting name-based routing tables).
For example, when content is cached, the router may only notify its direct neighbors of this information. Thus, only those neighboring
routers can build a name-based entry for this cached content.
But if the neighboring routers continue to propagate this information, the other nodes are able to direct to this cached copy as well.
Node failure impact: Nodes involved in the explicit name resolution approach are the name resolution overlay servers (e.g., resolution handlers in DONA),
while the nodes involved in the name-based routing approach are routers that route messages based on the name-based routing tables (e.g., NDN routers).
Node failures in the explicit name resolution approach may cause some content request routing to fail even though the content is available.
This problem does not exist in the name-based routing approach because other alternative paths can be discovered to bypass the failed ICN routers, given the assumption that the network is still connected.
Maintained databases: The storage usage for the explicit name resolution approach is different from that of the name-based routing approach.
The explicit name resolution approach typically needs to maintain two databases: name-to-locator mapping in the name resolution overlay and routing tables in the routers on the data forwarding plane.
The name-based routing approach needs to maintain only the name-based routing tables.
Additionally, some other intermediary step may be included in the name resolution -- namely, the mapping of one name to other names -- in order to facilitate the retrieval of named content by way of a manifest .
The manifest is resolved using one of the two above approaches, and it may include further mapping of names to content and location.
The steps for name resolution then become the following: first, translate the manifest name into a location of a copy of the manifest, which includes further names of the content components and potentially locations for the content, then retrieve the content by using these names and/or location, potentially resulting in additional name resolutions. Thus, no matter which approach is taken by an NRS in ICN, the name resolution is the essential function that shall be provided by the ICN infrastructure. Functionalities of NRS in ICNThis section presents the functionalities of an NRS in ICN. Support Heterogeneous Name Types
In ICN, a name is used to identify the data object and is bound to it .
ICN requires uniqueness and persistency of the name of the data object to ensure the
reachability of the object within a certain scope. There are
heterogeneous approaches to designing ICN naming schemes .
Ideally, a name can include any form of identifier, which can be
flat or hierarchical, human readable or non-readable.
Although there are diverse types of naming schemes proposed in the literature,
they all need to provide basic functions for identifying a data object,
supporting named data lookup, and routing. An NRS may combine the better
aspects of different schemes. Basically, an NRS should be able to support
a generic naming schema so that it can resolve any type of content name,
irrespective of whether it is flat, hierarchical, attribute based, or
anything else.
In PURSUIT , names are flat, and the rendezvous
functions are defined for an NRS, which is implemented by a set of rendezvous
nodes (RNs), known as the rendezvous network (RENE). Thus, a name consists of a
sequence of scope IDs, and a single rendezvous ID is routed by the RNs in RENE.
Thus, PURSUIT decouples name resolution and data routing, where the NRS
is performed by the RENE.
In MobilityFirst , a name known as a "Global
Unique Identifier (GUID)", derived from a human-readable name via a global
naming service, is a flat typed 160-bit string with self-certifying
properties. Thus, MobilityFirst defines a Global Name Resolution Service
(GNRS), which resolves GUIDs to network addresses and decouples name
resolution and data routing similarly to PURSUIT.
In NetInf , information objects are named using Named Information (NI) names , which consist of an authority part and digest part (content hash).
The NI names can be flat as the authority part is optional. Thus, the NetInf architecture also includes a Name Resolution System (NRS), which can be used to resolve NI names to addresses in an underlying routable network layer.
In NDN and CCNx ,
names are hierarchical and may be similar to URLs. Each name component
can be anything, including a human-readable string or a hash value.
NDN/CCNx adopts the name-based routing approach. The NDN router forwards
the request by doing the longest-match lookup in the Forwarding
Information Base (FIB) based on the content name, and the request is
stored in the Pending Interest Table (PIT).
Support Producer Mobility
ICN inherently supports mobility by consumers. Namely, consumer or client
mobility is handled by re-requesting the content in case the mobility
event (say, handover) occurred before receiving the corresponding
content from the network. Since ICN can ensure that content reception
continues without any disruption in ICN applications, seamless mobility
from the consumer's point of view can be easily supported.
However, producer mobility does not emerge naturally from the ICN
forwarding model as does consumer mobility. If a producer moves into
a different network location or a different name domain, which is
assigned by another authoritative publisher, it would be difficult for
the mobility management to update Routing Information Base (RIB) and FIB entries in ICN routers
with the new forwarding path in a very short time. Therefore, various
ICN architectures in the literature have proposed adopting an NRS to
achieve the producer or publisher mobility, where the NRS can be
implemented in different ways such as rendezvous points and/or overlay mapping systems.
In NDN , for producer mobility support, rendezvous mechanisms have been proposed to build interest rendezvous
(RV) with data generated by a mobile producer (MP). This can be
classified into two approaches: chase mobile producer and rendezvous data.
Regarding MP chasing, rendezvous acts as a mapping service that provides
the mapping from the name of the data produced by the MP to the name
of the MP's current point of attachment (PoA).
Alternatively, the RV
serves as a home agent as in IP mobility support, so the RV enables
the consumer's Interest message to tunnel towards the MP at the PoA.
Regarding rendezvous data, the solution involves moving the data produced
by the MP to a data depot instead of forwarding Interest messages.
Thus,
a consumer's Interest message can be forwarded to stationary place called a "data rendezvous", so it would either return the data or fetch it
using another mapping solution. Therefore, RV or other mapping functions
are in the role of an NRS in NDN.
In , the forwarding label (FL) object is
used to enable identifier (ID) and locator (LID) namespaces to be
split in ICN. Generally, IDs are managed by applications, while locators
are managed by a network administrator so that IDs are mapped to
heterogeneous name schemes and LIDs are mapped to the network domains or
to specific network elements. Thus, the proposed FL object acts as a locator
(LID) and provides the flexibility to forward Interest messages through
a mapping service between IDs and LIDs. Therefore, the mapping service in
control plane infrastructure can be considered as an NRS in this draft.
In MobilityFirst , both consumer and publisher
mobility can be primarily handled by the global name resolution service
(GNRS), which resolves GUIDs to network addresses. Thus, the GNRS must
be updated for mobility support when a network-attached object changes
its point of attachment, which differs from NDN/CCNx.
In NetInf , mobility is handled by
an NRS in a very similar way to MobilityFirst.
Besides the consumer and producer mobility, ICN also faces
challenges to support the other dynamic features such as multi-homing,
migration, and replication of named resources such as content, devices,
and services. Therefore, an NRS can help to support these dynamic features.
Support Scalable Routing System
In ICN, the name of data objects is used for routing by either a name
resolution step or a routing table lookup. Thus, routing information
for each data object should be maintained in the routing base, such
as RIB and FIB.
Since the number of data objects would be very large, the size of
information bases would be significantly larger as well .
The hierarchical namespace used in CCNx
and NDN architectures reduces the size of
these tables through name aggregation and improves the scalability of
the routing system. A flat naming scheme, on the other hand, would
aggravate the scalability problem of the routing system.
The non-aggregated name prefixes injected into the Default Route Free
Zone (DFZ) of ICN would create a more serious scalability problem when
compared to the scalability issues of the IP routing system.
Thus, an NRS may play an important role in the reduction of the routing
scalability problem regardless of the types of namespaces.
In , in order to address the routing
scalability problem in NDN's DFZ, a well-known concept called "map-and-encap" is applied to provide a simple and secure namespace mapping solution.
In the proposed map-and-encap design, data whose name prefixes do not
exist in the DFZ forwarding table can be retrieved by a distributed
mapping system called NDNS, which maintains and looks up the mapping
information from a name to its globally routed prefixes, where NDNS is
a kind of an NRS.
Support Off-Path Caching
Caching in-network is considered to be a basic architectural component
of an ICN architecture. It may be used to provide a level of quality-of-service (QoS)
experience to users to reduce the overall network traffic, to prevent network
congestion and denial-of-service (DoS) attacks, and to increase availability.
Caching approaches can be categorized into off-path caching and on-path
caching based on the location of caches in relation to the forwarding
path from the original server to the consumer. Off-path caching, also
referred to as "content replication" or "content storing", aims to replicate
content within a network in order to increase availability, regardless of
the relationship of the location to the forwarding path. Thus, finding
off-path cached objects is not trivial in name-based routing of ICN.
In order to support off-path caches, replicas are usually advertised
into a name-based routing system or into an NRS.
In , an NRS is used to find off-path copies
in the network, which may not be accessible via name-based routing mechanisms.
Such a capability can be helpful for an Autonomous System (AS) to avoid
the costly inter-AS traffic for external content more, to yield higher
bandwidth efficiency for intra-AS traffic, and to decrease the data
access latency for a pleasant user experience.
Support Nameless Object
In CCNx 1.0 , the concept of a "Nameless
Object", which is a Content Object without a name, is introduced to
provide a means to move content between storage replicas without having
to rename or re-sign the Content Objects for the new name. Nameless
Objects can be addressed by the ContentObjectHash, which is to restrict
Content Object matching by using a SHA-256 hash.
An Interest message would still carry a name and a ContentObjectHash,
where a name is used for routing, while a ContentObjectHash is used
for matching. However, on the reverse path, if the Content Object's
name is missing, it is a "Nameless Object" and only matches against the
ContentObjectHash. Therefore, a consumer needs to resolve the proper name
and hashes through an outside system, which can be considered as an NRS.
Support Manifest
For collections of data objects that are organized as large and file-like contents , manifests are used as data
structures to transport this information. Thus, manifests may contain
hash digests of signed Content Objects or other manifests so that large
Content Objects that represent a large piece of application data can be
collected by using such a manifest.
In order to request Content Objects, a consumer needs to know a manifest
root name to acquire the manifest. In the case of File-Like ICN Collections (FLIC), a manifest name
can be represented by a nameless root manifest so that an outside system
such as an NRS may be involved to give this information to the consumer.
Support Metadata
When resolving the name of a Content Object, NRS could return a rich
set of metadata in addition to returning a locator. The metadata
could include alternative object locations, supported object transfer
protocol(s), caching policy, security parameters, data format, hash
of object data, etc. The consumer could use this metadata for the selection
of object transfer protocol, security mechanism, egress interface, etc.
An example of how metadata can be used in this way is provided by the
Networked Object (NEO) ICN architecture .
Design Considerations for NRS in ICN
This section presents the design considerations for NRS in ICN.
Resolution Response Time
The name resolution process should provide a response within a reasonable amount of time. The response should be either a proper mapping of the name to a copy of the content or an error message stating that no such object exists. If the name resolution does not map to a location, the system may not issue any response, and the client should set a timer when sending a request so as to consider the resolution incomplete when the timer expires.
The acceptable response delay could be of the order of a round-trip
time between the client issuing the request and the NRS servers that provide the response. While this RTT may vary greatly depending on the proximity between the two end points, some upper bound needs to be used.
Especially in some delay-sensitive scenarios such as industrial Internet and telemedicine, the upper bound of the response delay must be guaranteed.
The response time includes all the steps of the resolution, including potentially a hop-by-hop resolution or a hierarchical forwarding of the resolution request.
Response Accuracy
An NRS must provide an accurate response -- namely, a proper binding of the requested name (or prefix) with a location. The response can be either a (prefix, location) pair or the actual forwarding of a request to a node holding the content, which is then transmitted in return.
An NRS must provide an up-to-date response -- namely, an NRS should be updated within a reasonable time when new copies of the content are being stored in the network. While every transient cache addition/eviction should not trigger an NRS update, some origin servers may move and require the NRS to be updated.
An NRS must provide mechanisms to update the mapping of the content with its location. Namely, an NRS must provide a mechanism for a content provider to add new content, revoke old/dated/obsolete content, and modify existing content. Any content update should then be propagated through
the NRS system within reasonable delay.
Content that is highly mobile may require specifying some type of anchor that is kept at the NRS instead of the content location.
Resolution Guarantee
An NRS must ensure that the name resolution is successful
with high probability if the name-matching content exists in the network,
regardless of its popularity and the number of cached copies existing in the network.
Per , some resolutions may not occur in a timely manner.
However, the probability of such an event should be minimized.
The NRS system may provide a probability (five 9s or
five sigmas, for instance) that a resolution will be satisfied.
Resolution Fairness
An NRS could provide this service for all content in a fair manner, independently of the specific content properties
(content producer, content popularity, availability of copies, content format, etc.).
Fairness may be defined as a per-request delay to complete the NRS steps that is agnostic to the properties of the content itself.
Fairness may be defined as well as the number of requests answered per unit of time.
However, it is notable that content (or their associated producer) may request a different level of QoS from the network (see , for instance),
and this may include the NRS as well, in which case considerations of fairness may be restricted to content within the same class of service.
Scalability
The NRS system must scale up to support a very large user population (including human users as well as machine-to-machine communications).
As an idea of the scale, it is expected that 50 billion devices will be connected in 2025 (per ITU projections).
The system must be able to respond to a very large number of requests per unit of time.
Message forwarding and processing, routing table buildup, and name record propagation must be efficient and scalable.
The NRS system must scale up with the number of pieces of content (content names) and should be able to support a content catalog that is extremely large.
Internet traffic is of the order of zettabytes per year (1021 bytes). Since NRS is associated with actual traffic,
the number of pieces of content should scale with the amount of traffic. Content size may vary from a few bytes to several GB,
so the NRS should be expected scale up to a catalog of the size of 1021 in the near future, and larger beyond.
The NRS system must be able to scale up -- namely, to add NRS servers to the NRS system in a way that is transparent to the users.
The addition of a new server should have a limited negative impact on the other NRS servers
(or should have a negative impact on only a small subset of the NRS servers).
The impact of adding new servers may induce some overhead at the other servers to rebuild a hierarchy or to exchange messages to include the new server within the service.
Further, data may be shared among the new servers for load balancing or tolerance to failure.
These steps should not disrupt the service provided by the NRS and should improve the quality of the service in the long run.
The NRS system may support access from a heterogeneity of connection methods and devices.
In particular, the NRS system may support access from constrained devices, and interactions with the NRS system would not be too costly.
An IoT node, for instance, should be able to access the NRS system as well as a more powerful node.
The NRS system should scale up in its responsiveness to the increased request rate that is expected from applications such as IoT or machine-to-machine (M2M),
where data is being frequently generated and/or requested.
Manageability
The NRS system must be manageable since some parts of the system may grow or shrink dynamically and an NRS system node may be added or deleted frequently.
The NRS system may support an NRS management layer that allows for adding or subtracting NRS nodes. In order to infer the circumstance, the management layer can measure the network status.
Deployed System
The NRS system must be deployable since deployability is important for a real-world system. The NRS system must be deployable in network edges and cores so that the consumers as well as ICN routers can perform name resolution in a very low latency.
Fault Tolerance
The NRS system must ensure resiliency in the event of NRS server failures.
The failure of a small subset of nodes should not impact the NRS performance significantly.
After an NRS server fails, the NRS system must be able to recover and/or restore the name records stored in the NRS server.
Security and Privacy
On utilizing an NRS in ICN, there are some security considerations for the
NRS servers/nodes and name mapping records stored in the NRS system.
This subsection describes them.
Confidentiality
The name mapping records in the NRS system must be assigned with
proper access rights such that the information contained in the name
mapping records would not be revealed to unauthorized users.
The NRS system may support access control for certain name mapping
records. Access control can be implemented with a reference monitor
that uses client authentication, so only users with appropriate
credentials can access these records, and they are not shared with
unauthorized users. Access control can also be implemented by
encryption-based techniques using control of keys to control the
propagations of the mappings.
The NRS system may support obfuscation and/or encryption
mechanisms so that the content of a resolution request
may not be accessible by third parties outside of the NRS system.
The NRS system must keep confidentiality to prevent
sensitive name mapping records from being reached by
unauthorized data requesters. This is more required
in IoT environments where a lot of sensitive data is produced.
The NRS system must also keep confidentiality of metadata
as well as NRS usage to protect the privacy of the users.
For instance, a specific user's NRS requests should
not be shared outside the NRS system (with the exception
of legal intercept).
Authentication
NRS server authentication: Authentication of the new NRS
servers/nodes that want to be registered with the NRS system
must be required so that only authenticated entities can
store and update name mapping records. The NRS system should
detect an attacker attempting to act as a fake NRS server
to cause service disruption or manipulate name mapping records.
Producer authentication: The NRS system must support
authentication of the content producers to ensure that
update/addition/removal of name mapping records requested
by content producers are actually valid and that content
producers are authorized to modify (or revoke) these records
or add new records.
Mapping record authentication: The NRS should verify new
mapping records that are being registered so that it cannot
be polluted with falsified information or invalid records.
Integrity
The NRS system must be protected from malicious users
attempting to hijack or corrupt the name mapping records.
Resiliency and Availability
The NRS system should be resilient against denial-of-service attacks
and other common attacks to isolate the impact of the attacks and
prevent collateral damage to the entire system. Therefore, if a
part of the NRS system fails, the failure should only affect a local
domain. And fast recovery mechanisms need to be in place to bring
the service back to normal.
Conclusion
ICN routing may comprise three steps: name resolution, content request routing,
and content delivery. This document investigates the name resolution step,
which is the first and most important to be achieved for ICN routing to be
successful. A Name Resolution Service (NRS) in ICN is defined as the service
that provides such a function of name resolution for translating an object
name into some other information such as a locator, another name, metadata,
next-hop info, etc. that is used for forwarding the object request.
This document classifies and analyzes the NRS approaches according to whether
the name resolution step is separated from the content request routing as an
explicit process or not. This document also explains the NRS functions used
to support heterogeneous name types, producer mobility, scalable routing system,
off-path caching, nameless object, manifest, and metadata. Finally, this document
presents design considerations for NRS in ICN, which include resolution response
time and accuracy, resolution guarantee, resolution fairness, scalability,
manageability, deployed system, and fault tolerance.
IANA ConsiderationsThis document has no IANA actions.Security Considerations
A discussion of security guidelines is provided in .
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).Informative ReferencesSNAMP: Secure Namespace Mapping to Scale NDN Forwarding2015 IEEE Conference on Computer Communications Workshops A Survey of Information-Centric NetworkingIEEE Communications Magazine, Vol. 50, Issue 7Named data networking for IoT: An architectural perspectiveEuropean Conference on Networks and Communications (EuCNC)Information-centric networking for the internet of things: challenges and opportunitiesIEEE Network, Vol. 30, No. 2Information Centric Networking in the IoT: Experiments with NDN in the WildACM-ICN 2014A Survey of Naming and Routing in Information-Centric NetworksIEEE Communications Magazine, Vol. 50, No. 12, pp. 44-53On Content Indexing for Off-Path Caching in Information-Centric NetworksACM-ICN 2016CICNNetwork of Information (NetInf) - An information-centric networking architectureComputer Communications, Vol. 36, Issue 7File-Like ICN Collections (FLIC)University of BaselCloudflarePARC, Inc.Network Systems Research & Design This document describes a simple "index table" data structure and its
associated ICN data objects for organizing a set of primitive ICN
data objects into a large, File-Like ICN Collection (FLIC). At the
core of this collection is a _manifest_ which acts as the
collection's root node. The manifest contains an index table with
pointers, each pointer being a hash value pointing to either a final
data block or another index table node.
Work in ProgressDesign Considerations for Applying ICN to IoTHuawei TechnologiesWINLAB, Rutgers UniversityPolitecnico di Bari (DEI)RISE SICSUCLA REMAPRISE SICSHuawei Technologies The Internet of Things (IoT) promises to connect billions of objects
to the Internet. After deploying many stand-alone IoT systems in
different domains, the current trend is to develop a common, "thin
waist" of protocols to enable a horizontally unified IoT
architecture. The objective of such an architecture is to make
resource objects securely accessible to applications across
organizations and domains. Towards this goal, quite a few proposals
have been made to build an application-layer based unified IoT
platform on top of today's host-centric Internet. However, there is
a fundamental mismatch between the host-centric nature of today's
Internet and the mostly information-centric nature of the IoT domain.
To address this mismatch, the common set of protocols and network
services offered by an information-centric networking (ICN)
architecture can be leveraged to realize an ICN-based IoT (or ICN-
IoT) architecture that can take advantage of the salient features of
ICN such as naming, security, mobility, compute and efficient content
and service delivery support offered by it.
In this draft, we summarize the general IoT demands, and ICN features
that support these requirements, and then discuss the challenges to
realize an ICN-based IoT framework. Beyond this, the goal of this
draft is not to offer any specific ICN-IoT architectural proposal.
Work in ProgressIDNet: Beyond All-IP NetworkETRI Journal, Vol. 37, Issue 5A Data-Oriented (and Beyond) Network ArchitectureACM SIGCOMM 2007, pp. 181-192 MobilityFirst Future Internet Architecture Project OverviewNameless ObjectsIRTF ICNRGNamed Data NetworkingA DNS-based information-centric network architecture open to multiple protocols for transfer of data objects21st Conference on Innovation in Clouds, Internet and Networks and Workshops (ICIN), pp. 1-8Architectural Considerations of ICN using Name Resolution ServiceETRIETRINICT 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).
Work in ProgressFP7 PURSUITA case for ICN usage in IoT environmentsIEEE GLOBECOMForwarding 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 ProgressNaming Things with HashesThis document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols.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.Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking ProtocolsThis is a position paper. It documents the author's personal views on how Quality of Service (QoS) capabilities ought to be accommodated in Information-Centric Networking (ICN) protocols like Content-Centric Networking (CCNx) or Named Data Networking (NDN), which employ flow-balanced Interest/Data exchanges and hop-by-hop forwarding state as their fundamental machinery. It argues that such protocols demand a substantially different approach to QoS from that taken in TCP/IP and proposes specific design patterns to achieve both classification and differentiated QoS treatment on both a flow and aggregate basis. It also considers the effect of caches in addition to memory, CPU, and link bandwidth as resources that should be subject to explicitly unfair resource allocation. The proposed methods are intended to operate purely at the network layer, providing the primitives needed to achieve transport- and higher-layer QoS objectives. It explicitly excludes any discussion of Quality of Experience (QoE), which can only be assessed and controlled at the application layer or above. This document is not a product of the IRTF Information-Centric Networking Research Group (ICNRG) but has been through formal Last Call and has the support of the participants in the research group for publication as an individual submission.New WID: 5GS Enhanced support of Vertical and LAN Services3GPPTSG SA Meeting #SP-82Scalable and Adaptive Internet Solutions (SAIL)An IP-Based Manifest Architecture for ICNACM-ICN 2015A Survey of Information-Centric Networking ResearchIEEE Communications Surveys and Tutorials, Vol. 16, Issue 2A Survey of Mobility Support in Named Data NetworkingIEEE Conference on Computer Communications WorkshopsAcknowledgements
The authors would like to thank , , , , , , ,
and for very useful reviews, comments, and improvements
to the document.
Authors' AddressesETRIYuseung-Gu218 Gajeong-roDaejeon34129Republic of Koreajhong@etri.re.krETRIYuseung-Gu218 Gajeong-roDaejeon34129Republic of Koreatwyou@etri.re.krFuturewei Technologies Inc.10180 Telesis CourtSan DiegoCA92121United States of Americalijun.dong@futurewei.comFuturewei Technologies Inc.2330 Central ExpresswaySanta ClaraCA95050United States of Americacedric.westphal@futurewei.comEricsson ResearchStockholm16480SwedenBorje.Ohlman@ericsson.com