ICN Research Group J. Hong
Internet-Draft T. You
Intended status: Informational Y-G. Hong
Expires: April 2, 2017 ETRI
September 29, 2016
Requirements for Name Resolution Service in ICN
draft-hong-icnrg-nrs-requirements-00
Abstract
This document discusses the motivation and requirements for Name
Resolution Service (NRS) in ICN. The NRS in ICN is to translate
object names into routing hints such as locators, where names are
location-independent and locators are network addresses.
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 http://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 April 2, 2017.
Copyright Notice
Copyright (c) 2016 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
(http://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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Hong, et al. Expires April 2, 2017 [Page 1]
Internet-Draft Requirements for NRS September 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Requirements for NRS in ICN . . . . . . . . . . . . . . . . . 4
4.1. Requirements on Operability . . . . . . . . . . . . . . . 4
4.1.1. Scalability . . . . . . . . . . . . . . . . . . . . . 4
4.1.2. Low latency . . . . . . . . . . . . . . . . . . . . . 4
4.1.3. Fast Update . . . . . . . . . . . . . . . . . . . . . 5
4.1.4. Locality . . . . . . . . . . . . . . . . . . . . . . 5
4.1.5. Resilience . . . . . . . . . . . . . . . . . . . . . 5
4.1.6. Fault tolerance / Isolation . . . . . . . . . . . . . 5
4.2. Requirements on Manageability . . . . . . . . . . . . . . 5
4.2.1. Manageabiliyt . . . . . . . . . . . . . . . . . . . . 5
4.2.2. Deployability . . . . . . . . . . . . . . . . . . . . 5
4.2.3. Interoperability . . . . . . . . . . . . . . . . . . 6
4.3. Requirements on Security . . . . . . . . . . . . . . . . 6
4.3.1. Access control . . . . . . . . . . . . . . . . . . . 6
4.3.2. Authentication . . . . . . . . . . . . . . . . . . . 6
4.3.3. Data confidentiality . . . . . . . . . . . . . . . . 6
4.3.4. Data integrity . . . . . . . . . . . . . . . . . . . 6
4.3.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 6
5. Use case of NRS . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Lookup by Name Routing (LBNR) . . . . . . . . . . . . . . 6
5.2. Route by Name Routing (RBNR) . . . . . . . . . . . . . . 7
5.3. Hybrid Routing (HR) . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
The current Internet is a host-centric networkAhlgrening, where hosts
are uniquely 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 host where the information is
stored. In contrast to the host-centric networking, the primary
communication objects in Information-centric networking (ICN) are the
named data objects (NDOs) and they are uniquely identified by the
location-independent names. Thus, ICN aiming to the efficient
dissemination and retrieval of the NDOs in a global scale has been
recognized as a promising technology for the future Internet
Hong, et al. Expires April 2, 2017 [Page 2]
Internet-Draft Requirements for NRS September 2016
architecture to overcome the limitations of the current Internet such
as scalability, mobility, etc [Ahlgren] [Xylomenos].
ICN alsoBaccelliBaccelliBaccelli has been emerged as a candidate
architecture for IoT environment since IoT focuses on data and
information rather than end-to-end communications [Baccelli] [Amadeo]
[Quevedo]. In addition, the following ICN features are fulfilling
well the architectural requirements of IoT such as naming, name
resolution, scalability, resource constraints, mobility, caching,
security, privacy, etc. [Amadeo2] [Zhang]:
o Naming of data, devices, and services independently from their
locations
o Distributed caching and processing
o Decoupling between sender and receiver
o Mobility support
o Authentication and verification of content
Since naming data independently from the current location where it is
stored is a primary concept of ICN, how to discover the NDO using the
location-independent name is one of the most important design
challenges in ICN. There are several projects for ICN which adopt
the lookup-by-name routing scheme exploiting the name resolution
service (NRS) to discover the NDO using the location-independent
name, where the NRS for ICN is to translate object names into routing
hints such as locators. Thus, in this document, we provide the
motivation and the requirements in designing the NRS for ICN.
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Motivation
In this section, we provide why NRS is needed in ICN and how it will
fit into ICN architecture.
ICN routing is a process how to retrieve the NDO based on its name
independently from its network address and may comprise three steps:
name resolution, content discovery, and content delivery. Depending
on how these steps are combined, ICN routing schemes can be
categorized as Route-By-Name Routing (RBNR), Lookup-By-Name Routing
Hong, et al. Expires April 2, 2017 [Page 3]
Internet-Draft Requirements for NRS September 2016
(LBNR), and Hybrid Routing (HR). RBNR omits the first name
resolution step and directly uses the name to route the request to
the NDO. LBNR uses the first name resolution step to translate the
name into its locator and the second content discovery step is based
on the locator. HR combines RBNR and LBNR to benefit from their
advantages [RFC7927].
CCN [Jacobson] and NDN [Zhang2] are the instantiation of RBNR. On
the other hand, LBNR is used in NetInf [Dannewitz], MobilityFirst
[Seskar], and IDNet [Jung]. Consequently, NRS is necessary unless
RBNR itself is chosen as an ICN routing scheme. NRS is also required
in ICN for the efficient support of a flat name such as self-
certifying identifier as well as the efficient mobility support
including the provider mobility.
There are several ICN projects which have their own NRS mechanisms as
an important component in their architecture. For instance, NetInf,
MobilityFirst and IDNet have MDHT [Dannewitz2], DMap [Vu] and BNRS
[Hong], respectively.
NRS for ICN will be a distributed system as an infrastructure in ICN
and will be implemented as a control plane completely separated from
data plan.
4. Requirements for NRS in ICN
In this section, we provide the requirements for designing NRS in ICN
in terms of operability, security and manageability, respectively.
4.1. Requirements on Operability
The requirements on operability aspect are things that should be
considered when the key operations of NRS are designed.
4.1.1. Scalability
The number of NDOs as well as users/publishers is ever-increasing and
it will be more than the order of 10^15 by the sensor data in IoT
environment. Thus, NRS has to be scalable to support such a large
number of NDOs.
4.1.2. Low latency
The process of the name resolution has to be completed within a
minimum delay. If the latency gets too long, then the initial
packets of many new sessions may get dropped or it will yield the
high response time for end users. For example, in order to browse
one web-page which includes several data objects in it, multiple name
Hong, et al. Expires April 2, 2017 [Page 4]
Internet-Draft Requirements for NRS September 2016
resolution queries can be processed at the same time and the latency
has to be user-tolerant.
4.1.3. Fast Update
The update process of NRS has to be fast enough to provide up-to-date
information since the copies of the data objects are frequently
created/disappearing as well as NDOs are moving in a highly dynamic
environment. Otherwise, the NRS may return the stale information.
4.1.4. Locality
In order to achieve the low latency, NRS has to minimize the total
traffic and especially the inter-domain traffic. Thus, NRS has to
keep the name resolution and data retrieval local, which yields the
improvement of network efficiency.
4.1.5. Resilience
If the resolution service fails, there is mostly no way for the user
to reach other end systems as the user knows only their names. Thus
NRS has to be resilience to the failures.
4.1.6. Fault tolerance / Isolation
NRS has to be implemented as a distributed system in order to avoid a
single point of failure. In addition, the architecture of NRS has to
provide fault isolation, which means that the failure part of NRS has
to have an impact only locally.
4.2. Requirements on Manageability
Requirements on manageability are things that should be considered in
terms of the system management aspect.
4.2.1. Manageabiliyt
NRS has to be manageable since some parts of the system may grow or
shrink dynamically and a name resolution server may be added or
deleted.
4.2.2. Deployability
Deployability is important for a real world system. If the NRS can
be deployed from the edges, then the deployment can be simplified.
Hong, et al. Expires April 2, 2017 [Page 5]
Internet-Draft Requirements for NRS September 2016
4.2.3. Interoperability
NRS has to support interoperability between the existing IoT
applications since they have their own ways for data management.
4.3. Requirements on Security
Requirements on security are things that should be considered in
terms of the security aspect for both the node and data.
4.3.1. Access control
A user may want to make a data copy known and accessible only within
the local network. In this case, the access control for the
information of the data stored in NRS is required. In addition,
unauthorized devices may access the NRS network.
4.3.2. Authentication
Users/nodes that register themselves with NRS server require the
authentication to ensure who claims to be. For example, the attacker
can act as a fake NRS server which causes disruption or intercepts
the data.
4.3.3. Data confidentiality
NRS has to keep the data confidentiality to prevent a lot of
sensitive data from reaching unauthorized data requestor in IoT
environment.
4.3.4. Data integrity
NRS has to keep the data integrity to assure the trustworthiness and
accuracy of the information.
4.3.5. Privacy
When a private data is registered in the system, NRS has to support
the privacy to avoid the information leaking. Otherwise,
unauthorized entity may disclose the privacy.
5. Use case of NRS
5.1. Lookup by Name Routing (LBNR)
In this subsection, we discuss some use cases of NRS according to the
mapping record type:
Hong, et al. Expires April 2, 2017 [Page 6]
Internet-Draft Requirements for NRS September 2016
o Name to locator(s): Mapping name to locator(s) is a primary record
type in NRS for ICN, where locator denotes routable information.
Although name can be hierarchical or flat, this type of NRS is
more essential for flat name support. In addition, provider
mobility as well as host mobility can be supported efficiently and
inherently through this type of mapping. A name registered in NRS
can be mapped into multiple locators due to the in-network caches
in ICN.
o Name to name (alias): Even in RBNR scheme, if provider changes the
name to another name which is designed for aggregation by
provider, the resolution of the initial name into the aggregated
name is required [8].
o Name to IP address: From an incremental deployment perspective,
even RBNR would need to map the name onto IP address to access the
current Internet (IP network) if necessary.
5.2. Route by Name Routing (RBNR)
[TBD]
5.3. Hybrid Routing (HR)
[TBD]
6. IANA Considerations
There are no IANA considerations related to this document.
7. Security Considerations
[TBD]
8. Acknowledgements
[TBD]
9. References
9.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,
<http://www.rfc-editor.org/info/rfc2119>.
Hong, et al. Expires April 2, 2017 [Page 7]
Internet-Draft Requirements for NRS September 2016
[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,
<http://www.rfc-editor.org/info/rfc7927>.
9.2. Informative References
[Ahlgren] Ahlgren, B. et al, , "A Survey of Informaiton-Centric
Networking", IEEE Communications Magazine vol. 50, no. 7,
July 2012.
[Xylomenos]
Xylomenos, G. et al., , "A Survey of Information-Centric
Networking Research", IEEE Communications Surveys and
Tutorials vol. 16, no. 2, 2014.
[Baccelli]
Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M.
Wahlisch, "Information Centric Networking in the IoT:
Experiments with NDN in the Wild", ACM ICN , September
2014.
[Amadeo] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, "Named
data networking for IoT: An architectural perspective",
European Conference on Networks and Communications , July
2014.
[Quevedo] Quevedo, J., Corujo, D., and R. Aguiar, "A case for ICN
usage in IoT environments", IEEE GLOBECOM , 2014.
[Amadeo2] Amadeo, M. et al., , "Information-centric networking for
the internet of things: challenges and opportunitiesve",
IEEE Network vol. 30, no. 2, July 2016.
[Zhang] Zhang, Y. et al., , "Requirements and Challenges for IoT
over ICN", Internet Draft, draft-zhang-icnrg-icniot-
requirements-01 , April 2016.
[Jacobson]
Jacobson, V. et al., , "Networking named content",
Proceedings of the 5th international conference on
Emerging networking experiments and technologies ,
December 2009.
[Zhang2] Zhang, L. et al., , "Named data networking", ACM SIGCOMM
Computer Communication Review vol. 44, no. 3, July 2014.
Hong, et al. Expires April 2, 2017 [Page 8]
Internet-Draft Requirements for NRS September 2016
[Dannewitz]
Dannewitz, C. et al., , "Network of Information (NetInf)-
An information centric networking architecture", Computer
Communications vol. 36, no. 7, April 2013.
[Seskar] Seskar, I., Nagaraja, K., Nelson, S., and D. Raychaudhuri,
"MobilityFirst Future Internet Architecture Project", 7th
Asian Internet Engineering Conference , November 2011.
[Jung] Jung, H. et al., , "IDNet: Beyond All-IP Network", ETRI
Jouranl vol. 37, no. 5, October 2015.
[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.
[Vu] Vu, T. et al., , "DMap: A Shared Hosting Scheme for
Dynamic Identifier to Locator Mapping in the Global
Internet", IEEE 32nd International Conference on
Distributed Computing Systems , 2012.
[Hong] Hong, J., Chun, W., and H. Jung, "Demonstrating a Scalable
Name Resolution System for Information-Centric
Networking", ACM ICN , September 2015.
Authors' Addresses
Jungha Hong
ETRI
161 Gajeong-Dong Yuseung-Gu
Daejeon 305-700
Korea
Phone: +82 42 860 0926
Email: jhong@etri.re.kr
Tae-Wan You
ETRI
161 Gajeong-Dong Yuseung-Gu
Daejeon 305-700
Korea
Phone: +82 42 860 0642
Email: twyou@etri.re.kr
Hong, et al. Expires April 2, 2017 [Page 9]
Internet-Draft Requirements for NRS September 2016
Yong-Geun Hong
ETRI
218 Gajeongno, Yuseong
Daejeon 305-700
Korea
Phone: +82 42 860 6557
Email: yghong@etri.re.kr
Hong, et al. Expires April 2, 2017 [Page 10]