[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-irtf-icnrg-nrsarch-considerations

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/