Requirements for Name Resolution Service in ICN

The information below is for an old version of the document
Document Type Active Internet-Draft (icnrg RG)
Authors Jungha Hong  , Taewan You  , Yong-Geun Hong  , Cedric Westphal  , Ved Kafle 
Last updated 2018-10-22 (latest revision 2018-10-17)
Replaces draft-hong-icnrg-nrs-requirements, draft-dong-icnrg-nrs-requirement
Stream Internet Research Task Force (IRTF)
Formats plain text xml htmlized pdfized bibtex
IETF conflict review conflict-review-irtf-icnrg-nrs-requirements, conflict-review-irtf-icnrg-nrs-requirements, conflict-review-irtf-icnrg-nrs-requirements, conflict-review-irtf-icnrg-nrs-requirements, conflict-review-irtf-icnrg-nrs-requirements, conflict-review-irtf-icnrg-nrs-requirements, conflict-review-irtf-icnrg-nrs-requirements
Stream IRTF state Active RG Document
Consensus Boilerplate Unknown
Document shepherd No shepherd assigned
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
ICN Research Group                                               J. Hong
Internet-Draft                                                    T. You
Intended status: Informational                                 Y-G. Hong
Expires: April 20, 2019                                             ETRI
                                                             C. Westphal
                                                                V. Kafle
                                                        October 17, 2018

            Requirements for Name Resolution Service in ICN


   This document discusses the motivation and requirements for Name
   Resolution Service (NRS) in ICN.  The NRS in ICN is to translate an
   object name into some other information such as locator and another
   name which is used for forwarding the object request.

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

   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 20, 2019.

Copyright Notice

   Copyright (c) 2018 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

Hong, et al.             Expires April 20, 2019                 [Page 1]
Internet-Draft            Requirements for NRS              October 2018

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
   3.  Name Resolution Service in ICN  . . . . . . . . . . . . . . .   4
     3.1.  Standalone name resolution approach . . . . . . . . . . .   4
     3.2.  Name based routing approach . . . . . . . . . . . . . . .   4
     3.3.  Hybrid approach . . . . . . . . . . . . . . . . . . . . .   4
     3.4.  Comparisons of name resolution approaches . . . . . . . .   5
   4.  Motivation of NRS in ICN  . . . . . . . . . . . . . . . . . .   6
     4.1.  Heterogeneous names in ICN  . . . . . . . . . . . . . . .   6
     4.2.  Dynamism in ICN . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Routing system in ICN . . . . . . . . . . . . . . . . . .   7
     4.4.  Use cases of NRS  . . . . . . . . . . . . . . . . . . . .   8
       4.4.1.  Flat name based routing support . . . . . . . . . . .   8
       4.4.2.  Producer mobility support . . . . . . . . . . . . . .   8
       4.4.3.  Scalable routing support  . . . . . . . . . . . . . .   9
       4.4.4.  Off-Path cache support  . . . . . . . . . . . . . . .   9
       4.4.5.  Nameless object support . . . . . . . . . . . . . . .  10
       4.4.6.  Menifest support  . . . . . . . . . . . . . . . . . .  10
   5.  Requirements for NRS in ICN . . . . . . . . . . . . . . . . .  11
     5.1.  Requirements as a service . . . . . . . . . . . . . . . .  11
       5.1.1.  Delay sensitivity . . . . . . . . . . . . . . . . . .  11
       5.1.2.  Accuracy  . . . . . . . . . . . . . . . . . . . . . .  11
       5.1.3.  Resolution guarantee  . . . . . . . . . . . . . . . .  11
     5.2.  Requirements as a system  . . . . . . . . . . . . . . . .  11
       5.2.1.  Scalability . . . . . . . . . . . . . . . . . . . . .  11
       5.2.2.  Manageability . . . . . . . . . . . . . . . . . . . .  12
       5.2.3.  Deployability . . . . . . . . . . . . . . . . . . . .  12
       5.2.4.  Fault tolerance . . . . . . . . . . . . . . . . . . .  12
     5.3.  Requirements on Security aspect . . . . . . . . . . . . .  12
       5.3.1.  Accessibility . . . . . . . . . . . . . . . . . . . .  12
       5.3.2.  Authentication  . . . . . . . . . . . . . . . . . . .  12
       5.3.3.  Data confidentiality  . . . . . . . . . . . . . . . .  12
       5.3.4.  Data privacy  . . . . . . . . . . . . . . . . . . . .  13
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

Hong, et al.             Expires April 20, 2019                 [Page 2]
Internet-Draft            Requirements for NRS              October 2018

1.  Introduction

   The current Internet is a host-centric networking, 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 identified and
   acknowledged as a promising technology for the future Internet
   architecture to overcome the limitations of the current Internet such
   as scalability, mobility, etc.[Ahlgren] [Xylomenos].  ICN also 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] [Amadeo2] [ID.Zhang2].

   Since naming data independently from the current location where it is
   stored is a primary concept of ICN, how to find the NDO using the
   location-independent name is one of the most important design
   challenges in ICN.  Such ICN routing may comprise three steps
   [RFC7927] :

   o  Name resolution : matches/translates a content name to locators of
      providers/sources that can provide the content.

   o  Content discovery : routes the content request towards the content
      either based on its name or locator.

   o  Content delivery : transfers the content to the requester.

   In three steps of ICN routing, this document focuses only the name
   resolution step which translates a content name to its locators.  In
   addition, this document considers all other types of name resolution
   in ICN such as name to name, name to manifest.

   Thus, this document presents the definition of the Name Resolution
   Service (NRS) in ICN and discusses 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",
   document are to be interpreted as described in [RFC2119].

Hong, et al.             Expires April 20, 2019                 [Page 3]
Internet-Draft            Requirements for NRS              October 2018

3.  Name Resolution Service in ICN

   The Name Resolution Service (NRS) in ICN is defined as the service
   that provides the name resolution function translating an object name
   into some other information such as locator and another name that is
   used for forwarding the object request.  In other words, the NRS is
   the service that shall be provided by ICN infrastructure to help a
   consumer to reach a specific piece of content, service, or host using
   a persistent name when the name resolution is needed.

   The name resolution is a necessary process in ICN routing although
   the name resolution either can be separated from the content
   discovery as a standalone process or can be integrated with the
   content discovery as one combined process.  The former is referred as
   standalone name resolution approach, the latter is referred as name
   based routing approach in this document.

3.1.  Standalone name resolution approach

   The NRS could take the standalone name resolution approach to return
   the client with the locators of the content, which will be used by
   the underlying network as the identifier to route the client's
   request to one of the producers.  There are several ICN projects that
   use the standalone name resolution approach such as DONA[Koponen],
   PURSUIT [PURSUIT], SAIL [SAIL], MobilityFirst [MF], IDNet [Jung],

3.2.  Name based routing approach

   The NRS could take the name based routing approach, which integrates
   the name resolution with the content request message routing as in

   In the case that the content request also specifies the reverse path,
   as in NDN/CCN, the name resolution mechanism also determines the
   routing path for the data.  This adds a requirement on the name
   resolution service to propagate request in a way that is consistent
   with the subsequent data forwarding.  Namely, the request must select
   a path for the data based upon the finding the copy of the content,
   but also properly delivering the data.

3.3.  Hybrid approach

   The NRS could also take hybrid approach which can perform name based
   routing approach from the beginning, when it fails at certain router,
   the router can go back to the standalone name resolution approach.
   The alternative hybrid NRS approach also works, which can perform

Hong, et al.             Expires April 20, 2019                 [Page 4]
Internet-Draft            Requirements for NRS              October 2018

   standalone name resolution approach to find locators of routers which
   can carry out the name based routing of the client's request.

   A hybrid approach would combine name resolution as 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
   architecture perform name resolution in the name-based routing

3.4.  Comparisons of name resolution approaches

   The following compares the standalone name resolution and name based
   routing approaches from different aspects:

   o  Update message overhead : The update message overhead is due to
      the change of content reachability, which may include content
      caching or expiration, content producer mobility etc.  The name
      based routing approach may require to flood part 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).  The standalone name
      resolution approach only requires to update propagation in part of
      the name resolution overlay.

   o  Resolution capability : The standalone name resolution approach
      can guarantee the resolution of any content in the network if it
      is registered to the name resolution overlay (assuming the
      information of content is being broadcast in the overlay after it
      is registered).  On the other hand, the name based routing
      approach can only promise a high probability of content
      resolution, depending on the flooding scope of the content
      availability information (i.e. content publishing message and name
      based routing table).

   o  Node failure impact : Nodes involved in the standalone 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 which route messages based on
      locally maintained name based routing tables (e.g.  NDN routers).
      Node failures in the standalone name resolution approach may cause
      some content discovery 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.

   o  Maintained databases : The storage usage for the standalone name
      resolution approach is different from that of the name based

Hong, et al.             Expires April 20, 2019                 [Page 5]
Internet-Draft            Requirements for NRS              October 2018

      routing approach.  The standalone 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 different databases: name routing table and
      optionally breadcrumbs for reverse routing of content back to the

4.  Motivation of NRS in ICN

   This section presents the motivation and use cases of NRS in ICN.

4.1.  Heterogeneous names in ICN

   In ICN design, a name is used to identify an entity, such as named
   data content, a device, an application, a service.  ICN requires
   uniqueness and persistency of the name of any entity to ensure the
   reachability of the entity within certain scope and with proper
   authentication and trust guarantees.  The name does not change with
   the mobility and multi-home of the corresponding entity.  A client
   can always use this name to retrieve the content from network and
   verify the binding of the content and the name.

   Ideally, a name can include any form of identifier, which can be
   flat, hierarchical, and human readable or non-readable.

   There are heterogeneous content naming schemes [ID.Zhang] [RFC1498]
   and name resolution approaches from different ICN architectures.  For

   o  Names in DONA [Koponen] consist of the cryptographic hash of the
      principal's public key P and a label L uniquely identifying the
      information with respect to the principal.  Name resolution in
      DONA is provided by specialized servers called Resolution Handlers

   o  Content in PURSUIT [PURSUIT] is identified by a combination of a
      scope ID and a rendezvous ID.  The scope ID represents the
      boundaries of a defined dissemination strategy for the content it
      contain.  The rendezvous ID is the actual identity for a
      particular content.  Name resolution in PURSUIT is handled by a
      collection of Rendezvous Nodes (RNs), which are implemented as a
      hierarchical Dynamic Hash Table (DHT)[Rajahalme] [Katsaros].

   o  Names in NDN [NDN] and CCN [CCN] are hierarchical and may be
      similar to URLs.  Each name component can be anything, including a
      dotted human-readable string or a hash value.  NDN/CCN adopts the
      name based routing.  The NDN router forwards the request by doing

Hong, et al.             Expires April 20, 2019                 [Page 6]
Internet-Draft            Requirements for NRS              October 2018

      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).

   o  In MobilityFirst [MF], every network entity, content has a Global
      Unique Identifier (GUID).  GUIDs are flat 160-bit strings with no
      semantic structure.  Name Resolution in MobilityFirst is carried
      out via a Global Name Resolution Service (GNRS).

   Although the existing naming schemes are different, they all need to
   provide basic functions for identifying a content, supporting trust
   provenance, content lookup and routing.  The NRS may combine the
   advantages of different mechanisms.  The NRS should be able to
   support a generic naming schema to resolve any type of content name,
   either it is flat or hierarchical.

4.2.  Dynamism in ICN

   In ICN literature, it is said that mobility can be achieved in
   fundamental feature of ICN.  Especially, consumer or client mobility
   can be achieved by requesting information again according to the
   basic procedure from different interfaces or through attachment point
   of the new network.  Moreover, seamless mobility service in ICN
   ensures that content reception continues without any disruption in
   ICN application, so in consumer point of view, seamless mobility can
   be easily supported.

   However, producer or publisher mobility in ICN is more complicated to
   be supported.  If a producer moves into different authority domain or
   network location, then the request for a content published by the
   moving puroducer with origin name would be hardly forwarded to the
   moving producer since the routing tables related in broad area should
   be updated according to the producer movement.  Therefore, various
   ICN literatures would adopt NRS to achieve the producer or publisher
   mobility, where NRS can be implemented in different ways such as
   rendezvous mechanism, mapping, etc.

   Besides mobility, ICN has challenge to support the dynamism features
   like multi-homing, migration, and replication of named resources such
   as content, devices, services, etc. and NRS may help to support the
   dynamism features.

4.3.  Routing system in ICN

   In ICN, data objects must be identified by names regardless their
   location or container [RFC7927] and the names are divided into two
   types of schemes: hierarchical and flat namespaces.  A hierarchical
   scheme used in CCN and NDN architectures has a structure similar to

Hong, et al.             Expires April 20, 2019                 [Page 7]
Internet-Draft            Requirements for NRS              October 2018

   current URIs, where the hierarchy improves scalability of routing
   system.  It is because the hierarchy enables aggregation of the name
   resulting in reducing the size of RIB or FIB as similar to IP routing
   system.  In a flat scheme, on the other hand, name routing is not
   easy since names in a flat namespace cannot be aggregated anymore,
   which would cause more the scalability problem in routing system.  In
   order to address such problem, a flat name can be resolved to some
   information which is routable through NRS.

   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.  Regardless of name
   scheme, if non-aggregated name prefixes are injected to the Default
   Route Free Zone (DFZ) of ICN, then they would be driving the growth
   of the DFZ routing table size, which is the same as the scalability
   issue of IP routing.  Thus a solution to keep the routing table size
   under control is needed, which can be done by defining indirection

4.4.  Use cases of NRS

   This subsection describes NRS used in many other ways in ICN

4.4.1.  Flat name based routing support

   In PURSUIT [PURSUIT], names are flat and the rendezvous functions are
   defined for NRS, which is implemented by a set of Rendezvous Nodes
   (RNs), the Rendezvous Network (RENE).  Thus a name consisted of a
   sequence of scope IDs and a single rendezvous ID is routed by RNs in
   RENE.  Thus, PURSUIT decouples name resolution and data routing,
   where NRS is performed by the RENE.

   In MobilityFirst [MF], a name called a global unique Identifier
   (GUID) derived from a human-readable name via a global naming service
   is flat typed 160-bits strings with self-certifying function.  Thus,
   MobilityFirst defines a global name resolution service (GNRS) which
   resolves GUIDs to network addresses and decouples name resolution and
   data routing as similar to PURSUIT.

4.4.2.  Producer mobility support

   In NDN [Zhang2], for producer mobility support, rendezvous mechanisms
   have been proposed to build interests rendezvous (RV) with data
   generated by a mobile producer (MP).  There can be classified two
   approaches such as 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

Hong, et al.             Expires April 20, 2019                 [Page 8]
Internet-Draft            Requirements for NRS              October 2018

   the MP's current point of attachment (PoA) name.  Alternatively, the
   RV serves as a home agent like as IP mobility support, so the RV
   enables consumer's interest message to tunnel towards the MP at the
   PoA.  Regarding rendezvous data, moving the data produced by the MP
   have been hosting at data depot instead of forwarding interest
   messages.  Thus a consumer's interest message can be forwarded to
   stationary place as called 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 NRS in NDN.

   In [Ravindran], forwarding-label (FL) object is referred 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 mapping to
   heterogeneous name schemes and LIDs are mapping to network domains or
   specific network elements.  Thus the proposed FL object acts as a
   locator (LID) and provides the flexibility to forward Interest
   messages through mapping service between IDs and LIDs.  Therefore,
   the mapping service in control plane infrastructure can be considered
   as NRS in this draft.

   In MobilityFirst [MF], 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/CCN.

4.4.3.  Scalable routing support

   In [Afanasyev], in order to address the routing scalability problem
   in NDN's DFZ, a well-known concept of 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 lookups the mapping
   information from a name to its globally routed prefixes, where NDNS
   is a kind of NRS.

4.4.4.  Off-Path cache support

   Caching in-network is considered to be a basic architectural
   component of an ICN architecture.  It may be used to provide a
   Quality-of-Service (QoS) experience to users, reduce the overall
   network traffic, prevent network congestion and Denial-of-Service
   (DoS) attacks and 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 a original
   server to a consumer.  Off-path caching, also referred as content

Hong, et al.             Expires April 20, 2019                 [Page 9]
Internet-Draft            Requirements for NRS              October 2018

   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 NRS.

   In [Bayhan], a NRS used to find off-path copies in the network, which
   may not be accessible via content discovery mechanisms.  Such
   capability is essential for an Autonomous System (AS) to avoid the
   costly inter-AS traffic for external content, to yield higher
   bandwidth efficiency for intra-AS traffic, and to decrease the data
   access latency for a pleasant user experience.

4.4.5.  Nameless object support

   In CCNx 1.0 [Mosko2], the concept of "Nameless Objects" that are 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 that is to restrict Content Object
   matching by using 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 proper
   name and hashes through an outside system, which can be considered as

4.4.6.  Menifest support

   In collection of data objects which were organized as large and file
   like contents [FLIC], the manifests are used as data structures to
   transport this information.  Thus, the manifests may contain hash
   digests of signed content objects or other manifests, so that large
   content objects which represent large piece of application data can
   be collected by using the manifest.

   In order to request content objects, a consumer needs to know a
   manifest root name to acquire the manifest.  In case of FLIC, a
   manifest name can be represented by a nameless root manifest, so that
   outside system may be involved to give this information to the
   consumer.  Therefore, NRS can be considered as a kind of mapping
   database system.

Hong, et al.             Expires April 20, 2019                [Page 10]
Internet-Draft            Requirements for NRS              October 2018

5.  Requirements for NRS in ICN

   This section presents the requirements for designing NRS in ICN in
   terms of service, system and security aspects, respectively.

5.1.  Requirements as a service

   This subsection presents the requirements for NRS as a service.

5.1.1.  Delay sensitivity

   The name resolution process provided by the NRS must be completed
   within a minimum delay.  If the name resolution takes too long, then
   the content request packet may get dropped or it will yield the high
   content retrieval time for content requestor.  Thus, the content
   retrieval time has to be content requestor-tolerant.

5.1.2.  Accuracy

   The NRS must provide accurate and up-to-date information on how to
   discover the requested content with minimum overhead in propagating
   the update information.  For example, a content can be moved from one
   domain to another domain due to the mobility of the producer, then
   the old name record should be deleted from the NRS system and a new
   name record should be added and updated with minimum delay.

5.1.3.  Resolution guarantee

   The NRS must ensure the name resolution success if the matching
   content exists in the network, regardless of its popularity, number
   of cached copies.

5.2.  Requirements as a system

   This subsection presents the requirements for NRS as a system.

5.2.1.  Scalability

   The NRS system must be extremely scalable to support a large number
   of content objects as well as billions of users, who may access the
   system through various connection methods and devices.  Especially in
   IoT applications, the data size is small but frequently generated by
   sensors.  Message forwarding and processing, routing table building-
   up and name records propagation must be efficient and scalable.

Hong, et al.             Expires April 20, 2019                [Page 11]
Internet-Draft            Requirements for NRS              October 2018

5.2.2.  Manageability

   The NRS system must be manageable since some parts of the system may
   grow or shrink dynamically and a NRS system node may be added or

5.2.3.  Deployability

   The NRS system must be deployable since deployability is important
   for a real world system.  If the NRS system can be deployed from the
   edges, then the deployment can be simplified.

5.2.4.  Fault tolerance

   The NRS system must ensure resilience to node failures.  After a NRS
   node fails, the NRS system must be able to restore the name records
   stored in the NRS node.

5.3.  Requirements on Security aspect

   This subsection presents the requirements for NRS on security aspect
   for both node and data in the NRS system.

5.3.1.  Accessibility

   The name records must have proper access rights such that the
   information contained in the name record would not be revealed to
   unauthorized users.  In other words, The NRS system must be prevented
   from the malicious users attempting to hijack or corrupt name

5.3.2.  Authentication

   Users/nodes that register themselves in the NRS system must 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.

5.3.3.  Data confidentiality

   NRS must keep the data confidentiality to prevent a lot of sensitive
   data from reaching unauthorized data requestor such as in IoT

Hong, et al.             Expires April 20, 2019                [Page 12]
Internet-Draft            Requirements for NRS              October 2018

5.3.4.  Data privacy

   When a private data is registered in the system, the NRS system must
   support the privacy to avoid the information leaking.  Otherwise,
   unauthorized entity may disclose the privacy.

6.  IANA Considerations

   There are no IANA considerations related to this document.

7.  Security Considerations


8.  Acknowledgements


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,

   [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,

9.2.  Informative References

   [Ahlgren]  Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D.,
              and B. Ohlman, "A Survey of Information-Centric
              Networking", IEEE Communications Magarzine Vol.50, Issue
              7, 2012.

              Xylomenos, G., Ververidis, C., Siris, V., Fotiou, N.,
              Tsilopoulos, C., Vasilako, X., Katsaros, K., and G.
              Polyzos, "A Survey of Information-Centric Networking
              Research,Communications Surveys and Tutorials", IEEE
              Communications Surveys and Tutorials vol. 16, no. 2, 2014.

Hong, et al.             Expires April 20, 2019                [Page 13]
Internet-Draft            Requirements for NRS              October 2018

              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 2014, 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
              (EuCNC) , 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, Y., "Design Considerations for Applying ICN to
              IoT", draft-zhang-icnrg-icniot-01 , June 2017.

   [Koponen]  Koponen, T., Chawla, M., Chun, B., Ermolinskiy, A., Kim,
              K., Shenker, S., and I. Stoica, "A Data-Oriented (and
              Beyond) Network Architecture", ACM SIGCOMM 2007 pp.
              181-192, 2007.

   [PURSUIT]  "FP7 PURSUIT project.",

   [SAIL]     "FP7 SAIL project.", .

   [NDN]      "NSF Named Data Networking project.",

   [CCN]      "Content Centric Networking project.",

   [MF]       "NSF Mobility First project.",

   [Jung]     Jung, H. et al., "IDNet: Beyond All-IP Network", ETRI
              Jouranl vol. 37, no. 5, October 2015.

              Jacobson, V., Smetters, D., Thornton, J., Plass, M.,
              Briggs, N., and R. Braynard, "Networking Named Content",
              ACM CoNEXT , 2009.

Hong, et al.             Expires April 20, 2019                [Page 14]
Internet-Draft            Requirements for NRS              October 2018

   [Baid]     Baid, A., Vu, T., and D. Raychaudhuri, "Comparing
              Alternative Approaches for Networking of Named Objects in
              the Future Internet", IEEE Workshop on Emerging Design
              Choices in Name-Oriented Networking (NOMEN) , 2012.

   [Bari]     Bari, M., Chowdhury, S., Ahmed, R., Boutaba, R., and B.
              Mathieu, "A Survey of Naming and Routing in Information-
              Centric Networks", IEEE Communications Magazine Vol. 50,
              No. 12, P.44-53, 2012.

              Rajahalme, J., Sarela, M., Visala, K., and J. Riihijarvi,
              "On Name-based Inter-domain Routing", Computer
              Networks Vol. 55, No. 4, P. 975-986, March 2011.

              Katsaros, K., Fotiou, N., Vasilakos, X., Ververidis, C.,
              Tsilopoulos, C., Xylomenos, G., and G. Polyzos, "On Inter-
              Domain Name Resolution for Information-Centric Networks",
              Proc.IFIP-TC6 Networking Conference , 2012.

   [ID.Wang]  Wang, J., Li, S., and C. Wetphal, "Namespace Resolution in
              Future Internet Architectures", draft-wang-fia-
              namespace-01 , October 2015.

              Zhang, X., Ravindran, R., Xie, H., and G. Wang, "PID: A
              Generic Naming Schema for Information-centric Network",
              draft-zhang-icnrg-pid-naming-scheme-03 , August 2013.

   [D.Zhang]  Zhang, D. and H. Liu, "Routing and Name Resolution in
              Information-Centric Networks", 22nd International
              Conference on Computer Communications and Networks
              (ICCCN) , 2013.

   [Sevilla]  Sevilla, S., Mahadevan, P., and J. Garcia-Luna-Aceves,
              "iDNS: Enabling Information Centric Networking Through The
              DNS", Name Oriented Mobility (workshop co-located with
              Infocom 2014) , 2014.

   [RFC1498]  Saltzer, J., "On the Naming and Binding of Network
              Destinations", RFC 1498, DOI 10.17487/RFC1498, August
              1993, <>.

   [oneM2M]   "oneM2M Functional Architecture TS 0001.",

Hong, et al.             Expires April 20, 2019                [Page 15]
Internet-Draft            Requirements for NRS              October 2018

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,

              Shelby, Z., "CoRE Resource Directory", draft-ietf-core-
              resource-directory-10 , March 2017.

   [CoRE]     "Constrained RESTful Environments, CoRE",
     , March

              Westphal, C. and E. Demirors, "An IP-based Manifest
              Architecture for ICN", ACM ICN , 2015.

   [Mosko]    Mosko, M., Scott, G., Solis, I., and C. Wood, "CCNx
              Manifest Specification", draft-wood-icnrg-
              ccnxmanifests-00 , July 2015.

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830,
              DOI 10.17487/RFC6830, January 2013,

   [RFC6833]  Fuller, V. and D. Farinacci, "Locator/ID Separation
              Protocol (LISP) Map-Server Interface", RFC 6833,
              DOI 10.17487/RFC6833, January 2013,

   [Zhang]    Zhang, L. et al., "Named data networking", ACM SIGCOMM
              Computer Communication Review vol. 44, no. 3, July 2014.

   [Zhang2]   Zhang, Y., "A Survey of Mobility Support in Named Data

              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.

Hong, et al.             Expires April 20, 2019                [Page 16]
Internet-Draft            Requirements for NRS              October 2018

              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.

              Ravindran, R. et al., "Forwarding-Label support in CCN
              Protocol", draft-ravi-icnrg-ccn-forwarding-label-01 , July

              Afanasyev, A. et al., "SNAMP: Secure Namespace Mapping to
              Scale NDN Forwarding", IEEE Global Internet Symposium ,
              April 2015.

   [Mosko2]   Mosko, M., "Nameless Objects",  , July 2015.

   [Bayhan]   Bayhan, S. et al., "On Content Indexing for Off-Path
              Caching in Information-Centric Networks", ACM ICN ,
              September 2016.

   [FLIC]     Tschudin, C. and C. Wood, "File-Like ICN Collection
              (FLIC)", draft-irtf-icnrg-flic-01, , June 2018.

Authors' Addresses

   Jungha Hong
   218 Gajeong-ro, Yuseung-Gu
   Daejeon  34129


Hong, et al.             Expires April 20, 2019                [Page 17]
Internet-Draft            Requirements for NRS              October 2018

   Tae-Wan You
   218 Gajeong-ro, Yuseung-Gu
   Daejeon  34129


   Yong-Geun Hong
   218 Gajeong-ro, Yuseung-Gu
   Daejeon  34129


   Cedric Westphal
   2330 Central Expressway
   Santa Clara, CA  95050


   Ved Kafle
   4-2-1 Nukui-Kitamachi
   Koganei, Tokyo  184-8795


Hong, et al.             Expires April 20, 2019                [Page 18]