ICN Research Group J. Hong
Internet-Draft T. You
Intended status: Informational ETRI
Expires: September 10, 2020 V. Kafle
NICT
March 09, 2020
Architectural Considerations of ICN using Name Resolution Service
draft-irtf-icnrg-nrsarch-considerations-04
Abstract
This document discusses architectural considerations and implications
of Information-Centric Networking (ICN) related to the usage of the
Name Resolution Service (NRS). It describes how ICN architectures
may change and what implications are introduced within the ICN
routing system when NRS is integrated into an ICN architecture.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Hong, et al. Expires September 10, 2020 [Page 1]
Internet-Draft Arch Considerations of ICN using NRS March 2020
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Implications of NRS in ICN . . . . . . . . . . . . . . . . . 5
5. ICN Architectural Considerations for NRS . . . . . . . . . . 5
5.1. Name mapping records registration, resolution, and update 5
5.2. Protocols and Semantics . . . . . . . . . . . . . . . . . 7
5.3. Routing System . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Information-Centric Networking (ICN) is an approach to evolve the
Internet infrastructure to directly access Named Data Objects (NDOs)
by its name, i.e., the name of NDO is directly used to route the
request to the data object. Such name-based routing in ICN has
inherent challenges in supporting globally scalable routing system,
producer mobility, and off-path caching. In order to address these
challenges, the Name Resolution Service (NRS) has been integrated
into several ICN project's proposals and literature [Afanasyev]
[Zhang2] [Ravindran] [SAIL] [MF] [Bayhan].
This document describes how ICN architectures may change and what
implications are introduced within the ICN routing system when NRS is
integrated into an ICN architecture. It also discusses ICN
architectural considerations for an NRS. In other words, the scope
of this document includes considerations in the view of the ICN
architecture and routing system when NRS is integrated into ICN. The
discussion of NRS itself is provided in the NRS design guidelines
[NRSguidelines] document.
2. Terminology
o Name Resolution Service (NRS): 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, a
off-path-cache pointer, or an alias name for forwarding the object
Hong, et al. Expires September 10, 2020 [Page 2]
Internet-Draft Arch Considerations of ICN using NRS March 2020
request [NRSguidelines]. The NRS is a service maintained by a
distributed mapping database system.
o NRS server: The NRS consists of the distributed NRS servers
storing the mapping records in database. NRS servers store and
maintain the mapping records that keep the mappings of name to
some other information that is used for forwarding content
request.
o NRS resolver: The client side of the NRS is called an NRS
resolver. The resolver is responsible for initiating the 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 ICN routers. NRS
resolver may also cache the mapping records obtained through the
name resolution for later usage.
o Name registration: In order to create the NRS, the content names
and their mapping records must be registered in the NRS system by
a publisher who has an access to at least one authoritative NRS
server or by a producer who generates named data objects. The
mapping information is the mapping of a name to some information
such as another names and locators, which are used for forwarding
the content request. Thus, a publisher or producer creates an NRS
registration request and send to an NRS server. On registration,
the NRS server stores the mapping record in the database and sends
an ACK back to the producer or publisher.
o Name resolution: Name resolution is the main process of the NRS.
It is performed by an NRS resolver which can be deployed on a
consumer node or an ICN router. When the required valid name
mapping record (whose lifetime has not expired yet) has not been
stored in the cache of an NRS resolver, it sends a name resolution
request toward the NRS server. The NRS server searches the
content name in its mapping record database, retrieves and sends
the mapping record in the name resolution response message to the
NRS resolver.
o NRS node: In ICN architecture, NRS servers are also referred to as
NRS nodes that maintain the name records.
o NRS client: A node that uses the NRS is called NRS client. The
nodes that initiate the name registration, resolution, or update
procedure are NRS clients. That is, NRS resolver, ICN client
nodes, ICN routers, or producers are NRS clients.
Hong, et al. Expires September 10, 2020 [Page 3]
Internet-Draft Arch Considerations of ICN using NRS March 2020
3. Background
The name-based routing in ICN has inherent challenges in supporting a
globally scalable routing system, producer mobility, and off-path
caching. In order to address these challenges, an NRS has been
integrated into several ICN project's proposals and literature as
follows:
o Routing scalability : In ICN, application names identifying
contents are 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, they would be driving the
growth of the DFZ routing table size. Thus, integrating an NRS
with ICN can be an approach to keep the routing table size under
control, where the NRS resolves name prefixes which do not exist
in the DFZ forwarding table into globally routable prefixes such
as one proposed in NDN [Afanasyev]. Another approach dealing with
routing scalability is the Multi-level Distributed Hash
Table (MDHT) used in NetInf [Dannewitz]. It provides name-based
anycast routing that can support a non-hierarchical namespace and
can be adopted on a global scale [Dannewitz2].
o 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 name would
be hardly forwarded to the moving producer's new location.
Especially, in a hierarchical name scheme, producer mobility
support is much harder than in a flat name scheme since the
routing tables in broader area need to be updated according to the
producer movement. Therefore, various ICN architectures such as
NetInf [Dannewitz] and MobilityFirst [MF] have adopted NRS to
tackle the issues of producer's location change.
o Off-path caching : In-network caching is an inherent 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, also referred as
content replication or content storing, aims at replicating
content in various locations within a network in order to increase
the availability of contents, where the caching locations may not
be lying along the content forwarding path. Thus, finding off-
path cached contents is not trivial in name-based routing of ICN.
In order to support off-path caches, the locations of replicas are
usually advertised into a name-based routing system or into NRS as
described in [Bayhan].
Hong, et al. Expires September 10, 2020 [Page 4]
Internet-Draft Arch Considerations of ICN using NRS March 2020
This document discusses architectural considerations and implications
of ICN when the NRS is integrated into ICN to solve such challenges
of the name-based routing in ICN.
4. Implications of NRS in ICN
The majority of ICN projects use the name-based routing which omits
the name resolution. So, NRS would not be mandatory part in an ICN
architecture. The integration of NRS would change the ICN
architecture at least with respect to procedures, latency, and
security, as discussed below:
o Procedure : When the NRS is adopted into an ICN architecture, the
procedure of the name resolution has to be integrated into ICN
overall procedures. For NRS integration, there are certain things
that have to be decided such as where and how the name resolution
task is performed.
o Latency : When the NRS is adopted into an ICN architecture, the
additional latency of the name resolution obviously occurs in the
routing and forwarding system. Although the latency of the name
resolution is added, the total latency could be minimized if the
nearest copies or off-path caches can be located by the NRS lookup
procedure. Additionally, there might be a trade-off between the
name resolution latency and inter-domain traffic reduction.
Finding a nearest cache holding the content would reduce the
content discovery as well as delivery latency.
o Security : When the NRS is adopted into an ICN architecture,
security threats may increase. Protection of the NRS system
against attacks such as Distributed Denial of Service (DDoS) and
authentication of name mapping records and related signaling
messages would be challenging.
5. ICN Architectural Considerations for NRS
This section discusses the various items that have to be considered
from the point of view of ICN architecture when ICN integrates the
NRS system in its architecture. These items are related with the
name mapping records registration, resolution, and update, protocols
and messages, and integration with the routing system.
5.1. Name mapping records registration, resolution, and update
When the NRS is integrated in an ICN architecture, the functions
related with the registration, resolution and update of name mapping
records have to be considered. The NRS nodes maintain the name
mapping records and may exist in an overlay network over the ICN
Hong, et al. Expires September 10, 2020 [Page 5]
Internet-Draft Arch Considerations of ICN using NRS March 2020
routers, that is, they communicate to each other through ICN routers.
Figure 1 shows the NRS nodes and NRS clients connected through an
underlying network. The NRS nodes exist in a distributed manner so
that an NRS node is always available closer to an NRS client and
communication latency for the name registration and resolution
performed by the NRS client remains very low. The name registration,
name resolution and name record update procedures are briefly
discussed below.
+------------+ +------------+
| NRS Node | | NRS Node |
+------------+ +------------+
| |
| |
+------------+ | | +------------+
| NRS Client |--------------------------------------| NRS Client |
+------------+ underlying network +------------+
Figure 1: NRS nodes and NRS clients connected through an underlying
network
o Name registration: Name registration is performed by the producer
(as an NRS client) when it creates a new content. When a producer
creates a 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 it
does 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 to invoke NRS registration
procedure because they lie on the path to the content store or
producer. They will be hit when a future request is forwarded to
the content producer by an ICN router lying toward the ICN client
node. However, the ICN routers performing off-path caching of the
content require to invoke the name registration procedure so that
other ICN routers can know about the off-path cache locations
through the name resolution. As a content gets cached in many
off-path ICN routers, all of them may register the same content
names in the same NRS node multiple times. 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.
o Name resolution: Name resolution is performed by NRS client to
obtain the name record from an NRS node by sending a name
resolution request message and getting the response containing the
Hong, et al. Expires September 10, 2020 [Page 6]
Internet-Draft Arch Considerations of ICN using NRS March 2020
record. Regarding the name-based ICN routing context, the name
resolution will be mostly performed by an ICN router that does not
contain the name in its FIB table. The name resolution may also
be performed by the consumer (in case the consumer is multihomed)
to make decision 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 perform the name
resolution. It 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 know the requested content
reachable, it performs name resolution to obtain the name mapping
record and adds to FIB table. The ICN router may also perform
name resolution even before the arrival of the content request
time to use the name mapping record to configure the FIB table.
o 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 previous locations. The name record
update may take place explicitly by the exchange of name record
update message or implicitly when a timeout occurs and a name
record is deemed to be invalid. The explicit update is possible
when each record is accompanied by its lifetime value.
5.2. 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 should be
designed to manage and resolve names among different name spaces.
One way of implementing an NRS is by extending the basic ICN TLV
format and semantics [RFC8609] [RFC8569]. For instance, name
resolution and response messages can be implemented by defining new
type fields in the Interest and Content Object messages [CCNxNRS].
By leveraging the existing ICN Interest and Content Object packets
for name resolution and registration, the NRS system can be deployed
with a minimum implication of ICN architecture changes. However,
because of confining to the basic ICN protocol and semantics, the NRS
system may not be able to support more flexible and scalable designs.
On the other hand, an NRS system can be designed newly with its own
protocol and semantics like an independent NRS system described in
[Hong]. 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 independently from a basic ICN architecture.
Hong, et al. Expires September 10, 2020 [Page 7]
Internet-Draft Arch Considerations of ICN using NRS March 2020
5.3. Routing System
The NRS helps in reducing the routing complexity of ICN architecture
than the pure name-based routing by helping the routing system to
update the routing table on demand through the help of name records
obtained from the NRS. The routing system has to be considered to
make name resolution requests and process the information such as a
locator, a off-path-cache pointer, or an alias name, obtained from
the name resolution.
No matter what kind of infomation 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 requested content. In
other words, the infomation 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. Otherwise,
the resolve information is used to build the routing table.
The infomation obtained from the name resolution may not be in the
form of a name. For example, it may identify the tunnel endpoints by
IP address and is used to construct a tunnel to forward the content
request.
6. IANA Considerations
There are no IANA considerations related to this document.
7. Security Considerations
When NRS is integrated into an ICN architecture, security threats may
increase in various aspects as discussed below:
o Name Space Management: In order to deploy an NRS in ICN
architecture, ICN name spaces, which may be assigned by
authoritative entities, should be securely mapped to the content
publishers and securely managed by them. According to the ICN
research challenges [RFC7927], a new name space can also provide
an integrity verification function to authenticate its publisher.
The verification for mapping among different name spaces should be
securely required.
o NRS System: NRS enables the deployment of new entities (e.g. NRS
servers) to build distributed and scalable NRS systems. Thus, the
entities, e.g., NRS server maintaining a mapping database, could
be a single point of failure receiving malicious requests from
Hong, et al. Expires September 10, 2020 [Page 8]
Internet-Draft Arch Considerations of ICN using NRS March 2020
innumerable adversaries like Denial of Service or Distributed
Denial of service attacks. In addition, the NRS clients should
also trust on the NRS nodes in other network domains and
communication between them should be protected securely to prevent
the malicious entities from participating in this communication.
o NRS Protocols and Messages: In an NRS system, additional messages
related to the name registration, name resolution, and name record
update can spill over to unauthorized networks, increaing the
number of more security threats. An adversary can also manipulate
these messages by hijacking them to create false messages. A lot
of problems similar to the security issues of an IP network can
affect the overall ICN architecture. Therefore, security
mechanisms such as accessibility, authentication, etc.,
[NRSguidelines] for the NRS system should be considered to protect
not only the NRS system, but also the ICN architecture.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I.,
Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
"Information-Centric Networking (ICN) Research
Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,
<https://www.rfc-editor.org/info/rfc7927>.
8.2. Informative References
[Afanasyev]
Afanasyev, A. et al., "SNAMP: Secure Namespace Mapping to
Scale NDN Forwarding", IEEE Global Internet Symposium ,
April 2015.
[Zhang2] Zhang, Y., "A Survey of Mobility Support in Named Data
Networking", NAMED-ORIENTED MOBILITY: ARCHITECTURES,
ALGORITHMS, AND APPLICATIONS(NOM) , 2016.
[Ravindran]
Ravindran, R. et al., "Forwarding-Label support in CCN
Protocol", draft-ravi-icnrg-ccn-forwarding-label-01 , July
2017.
Hong, et al. Expires September 10, 2020 [Page 9]
Internet-Draft Arch Considerations of ICN using NRS March 2020
[SAIL] "FP7 SAIL project.", http://www.sail-project.eu/ .
[MF] "NSF Mobility First project.",
http://mobilityfirst.winlab.rutgers.edu/ .
[Bayhan] Bayhan, S. et al., "On Content Indexing for Off-Path
Caching in Information-Centric Networks", ACM ICN ,
September 2016.
[RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric
Networking (CCNx) Semantics",
https://www.rfc-editor.org/info/rfc8569 , July 2019.
[RFC8609] Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV
Format", https://www.rfc-editor.org/info/rfc8609 , July
2019.
[CCNxNRS] Hong, J. et al., "CCNx Extension for Name Resolution
Service", draft-hong-icnrg-ccnx-nrs-02 , July 2018.
[Hong] Hong, J., Chun, W., and H. Jung, "Demonstrating a Scalable
Name Resolution System for Information-Centric
Networking", ACM ICN , September 2015.
[NRSguidelines]
Hong, J. et al., "Design Guidelines for Name Resolution
Service in ICN", draft-irtf-icnrg-nrs-requirements-03 ,
November 2019.
[Dannewitz]
Dannewitz, C. et al., "Network of Information (NetInf)-An
information centric networking architecture", Computer
Communications vol. 36, no. 7, April 2013.
[Dannewitz2]
Dannewitz, C., DAmbrosio, M., and V. Vercellone,
"Hierarchical DHT-based name resolution for Information-
Centric Networks", Computer Communications vol. 36, no. 7,
April 2013.
Authors' Addresses
Hong, et al. Expires September 10, 2020 [Page 10]
Internet-Draft Arch Considerations of ICN using NRS March 2020
Jungha Hong
ETRI
218 Gajeong-ro, Yuseung-Gu
Daejeon 34129
Korea
Email: jhong@etri.re.kr
Tae-Wan You
ETRI
218 Gajeong-ro, Yuseung-Gu
Daejeon 34129
Korea
Email: twyou@etri.re.kr
Ved Kafle
NICT
4-2-1 Nukui-Kitamachi
Koganei, Tokyo 184-8795
Japan
Email: kafle@nict.go.jp
Hong, et al. Expires September 10, 2020 [Page 11]
