Skip to main content

Requirements for Name Resolution Service in ICN
draft-jhong-icnrg-nrs-requirements-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Jungha Hong , Lijun Dong
Last updated 2017-07-03 (Latest revision 2017-03-13)
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-jhong-icnrg-nrs-requirements-01
ICNRG                                                                        J. Hong
Internet-Draft                                                                   ETRI
Intended status: Informational                                    Lijun Dong
Expires: January 4, 2018                                                Huawei
                                                                                   T. You
                                                                                      ETRI
                                                                      Cedric Westphal
                                                                                  Huawei
                                                                             Y-G. Hong
                                                                                      ETRI
                                                                               GQ Wang
                                                                                  Huawei
                                                                        Jianping Wang
                                                        City University Hong Kong
                                                                           July 3, 2017
 

              Requirements for Name Resolution Service in ICN
                draft-jhong-icnrg-nrs-requirements-01.txt

Abstract

   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 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 January 4, 2018.

Hong, et al.           Expires January 4, 2018                [Page 1]
Internet-Draft            NRS Requirements                   July 2017

Copyright Notice

   Copyright (c) 2017 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 January 4, 2018                [Page 2]
Internet-Draft            NRS Requirements                   July 2017

Table of Contents

   1. Introduction .............................................................. 3
   2. Conventions and terminology ...................................... 5
   3. Name Resolution Service in ICN  .................................. 5
   4. Motivation of NRS in ICN  ............................................ 8
      4.1. Handling Heterogeneous Names in ICN ................... 8
      4.2. Handling Dynamism in ICN ..................................... 9
      4.3. Use cases of NRS ................................................ 9
         4.3.1. Flat Name routing support ................................ 9
         4.3.2. Publisher Mobility support ............................... 10
         4.3.3. Scalable Routing support ................................ 11
         4.3.4. Nameless object support  ............................... 12
   5. Requirements for NRS in ICN ...................................... 12
      5.1. Service aspect .................................................... 12
         5.1.1. Delay sensitivity ............................................. 12
         5.1.2. Time transiency ............................................. 13
         5.1.3. Resolution guarantee ...................................... 13
         5.1.4. Accuracy ...................................................... 13
      5.2. System aspects ................................................... 13
         5.2.1. Scalability    .................................................. 13
         5.2.2. Fault tolerance ............................................... 14
         5.2.3. Minimum inter-domain traffic ........................... 14
         5.2.4. Manageability       .......................................... 14
         5.2.5. Deployability         ......................................... 14
         5.2.6. Interoperability     .......................................... 15
      5.3. Security aspect ................................................... 15
         5.3.1. Accessibility .................................................. 15
         5.3.2. Authentication ................................................ 16
         5.3.3. Data confidentiality ......................................... 16
         5.3.4. Privacy ......................................................... 16
   6. Security Considerations .............................................. 16
   7. IANA Considerations .................................................. 16
   8. References ............................................................... 17
      8.1. Normative References   ........................................ 17
      8.2. Informative References  ........................................ 17

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

Hong, et al.           Expires January 4, 2018                [Page 3]
Internet-Draft            NRS Requirements                   July 2017

   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.[28][29]

   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 [30][31][32]. 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.[33][34]:

   - Naming of data, devices, and services independently from their
      locations

   - Distributed caching and processing

   - Decoupling between sender and receiver

   - Mobility support

   - 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 find the NDO using the
   location-independent name is one of the most important design
   challenges in ICN. There are several projects such as DONA[4],
   PURSUIT[5], SAIL[6], MobilityFirst[9], and IDNet[35] which use the
   name resolution step to discover the NDO using the location-
   independent name.

   The name resolution also can be used to address the routing
   scalability problem such as in NDN [38] and to support efficiently a
   flat name such as self-certifying identifier [5][9] as well as to
   support the producer mobility.

   Thus, in this document, we give the definition of the Name
   Resolution Service (NRS) in ICN and discuss the motivation and the
   requirements in designing the NRS for ICN.

Hong, et al.           Expires January 4, 2018                [Page 4]
Internet-Draft            NRS Requirements                   July 2017

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

   The name resolution is defined as the first step in ICN routing
   along with the content request routing and content delivery as the
   second and the third steps, respectively [RFC 7929].

       - Name resolution[11][12][14][15][17][18]: matches/translates a
       content name to locators of providers/sources that can provide
       the content.

       - Content request routing: routes the content request towards the
       content either based on its name or locator. The process of name
       resolution and content request routing can be integrated. If
       integrated, the content request is routed by name, such as in
       NDN[7]/CCN[8]. If not integrated, the content request is routed
       by the locator obtained from the previous name resolution step,
       such as in DONA[4], PURSUIT[5], SAIL[6], MobilityFirst[9],
       IDNet[35].

       - Content delivery: constructs a path for transferring the
       content to the requester.  In the integrated approach, content
       can be routed using breadcrumbs left by the request to define a
       reverse path, or by some other mechanism, such as including a
       locator for the requester in the content request. In the
       uncombined approach, the content can be routed from the provider
       back to the request through an independent path.

   Thus, the name resolution is a necessary process in ICN routing
   although the name resolution either can be separated from the
   content request routing as a standalone process or can be integrated
   with the content request routing as one combined process. The former

Hong, et al.           Expires January 4, 2018                [Page 5]
Internet-Draft            NRS Requirements                   July 2017

   is referred as standalone name resolution approach, the latter is
   referred as name based routing approach in this document.

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

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

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

       - 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 resolution to fail even though
       the content is available. This problem does not exist in the name
       based routing approach because other alternative paths can be
       discovered to bypass the failed ICN routers, given the assumption
       that the network is still connected.

       - Maintained databases: The storage usage for the standalone name
       resolution approach is different from that of the name based
       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 requester.

Hong, et al.           Expires January 4, 2018                [Page 6]
Internet-Draft            NRS Requirements                   July 2017

   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[4],
   PURSUIT[5], SAIL[6], MobilityFirst[9], IDNet[35], etc.

   The NRS could take the name based routing approach, which integrates
   the name resolution with the content request message routing as in
   NDN[7]/CCN[8].

   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.

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

   Additionally, some other intermediary step may be included in the
   name resolution, namely the mapping of one name to other names, in
   order to facilitate the retrieval of named content, by way of a
   manifest[24][25]. The manifest is resolved using one of the two
   above approaches, and it may include further mapping of names to
   content and location. The steps for name resolution then become:
   first translate the manifest name into a location of a copy of the
   manifest; the manifest includes further names of the content
   components, and potentially locations for the content. The content
   is then retrieved by using these names and/or location, potentially
   resulting in additional name resolutions.

Hong, et al.           Expires January 4, 2018                [Page 7]
Internet-Draft            NRS Requirements                   July 2017

   Thus, no matter which approach is taken by the NRS in ICN, the name
   resolution is the essential function that shall be provided by the
   ICN infrastructure.

4. Motivation of NRS in ICN

   In this section, we discuss the motivation and use cases of NRS in
   ICN.

4.1. Handling 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[16][19] and name
   resolution approaches from different ICN architectures. For example:

   - Names in DONA[4] 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 (RHs).

   - Content in PURSUIT[5] 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)[13][14].

   - Names in NDN/CCN[8][10] 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 the longest-

Hong, et al.           Expires January 4, 2018                [Page 8]
Internet-Draft            NRS Requirements                   July 2017

   match lookup in the Forwarding Information Base (FIB) based on the
   content name and the request is stored in the Pending Interest Table
   (PIT).

   - In MobilityFirst[9], every network entity, content has a Global
   Unique Identifier (GUID). GUIDs are flat 160-bit strings with no
   semantic structure. Name Resolution in MobilityFirst all 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 may be able to provide a
   generic naming schema to resolve any type of content name, either it
   is flat or hierarchical.

4.2. Handling Dynamism in ICN

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

   [TBD]

4.3. Use cases of NRS

   In this section, we describe usages of NRS in the ICN literature.

4.3.1. Flat Name routing support

   In ICN, data objects must be identified by names regardless their
   location or container [RFC 7927] 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
   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.

Hong, et al.           Expires January 4, 2018                [Page 9]
Internet-Draft            NRS Requirements                   July 2017

   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 is resolved to some information
   which is routable through NRS or a sort of NRS in various ICN
   literatures.

   In PURSUIT [5], 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 [9], 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.3.2. Publisher Mobility support

   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 allowing information requests to 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 publisher moves into different authority
   domain or network location, then the request for a content published
   by the moving publisher with origin name would be hardly forwarded
   to the moving publisher. Especially in a hierarchical name scheme,
   publisher mobility support is much harder than in a flat name scheme
   since the routing tables related in broad area should be updated
   according to the publisher movement. Therefore, various ICN
   literatures would adopt NRS to achieve the publisher mobility, where
   NRS can be implemented in different ways such as rendezvous
   mechanism, mapping, etc.

   In NDN, for publisher mobility support, rendezvous mechanisms have
   been proposed to build interests rendezvous (RV) with data generated
   by a mobile producer (MP) [36]. There can be classified two

Hong, et al.           Expires January 4, 2018               [Page 10]
Internet-Draft            NRS Requirements                   July 2017

   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
   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 [37], 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 [9], 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.3.3. Scalable Routing support

   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. As same as
   scalability of IP routing, 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. Thus a
   solution to keep the routing table size under control is needed,
   which can be done by defining indirection layer.

   In [38], a well-known concept of Map-and-Encap is applied to provide
   a simple and secure namespace mapping solution to address the
   routing scalability problem in NDN's DFZ. 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

Hong, et al.           Expires January 4, 2018               [Page 11]
Internet-Draft            NRS Requirements                   July 2017

   called NDNS, which maintains and lookups the mapping information
   from a name to its globally routed prefixes. Therefore, NDNS is a
   kind of NRS.

4.3.4. Nameless object support

   In CCNx 1.0, 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 [39].

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

5. Requirements for NRS in ICN

   In this section, we provide the requirements for designing NRS in
   ICN in terms of service, system and security aspects, respectively.

5.1. Service aspect

   We enumerate the requirements on service aspect.

5.1.1. Delay sensitivity

   The name resolution process provided by the NRS must not introduce
   significant latencies. With more number of name record replications,
   the number of nodes involved in the name resolution may be reduced.
   For example, in the standalone name resolution approach, with the
   name record being replicated to higher hierarchy or the peer NRS
   server in the overlay, the name resolution can be responded more
   promptly. In the name based routing approach, with the content based
   routing table being broadcast within the larger scope in the
   network, the name resolution and request routing can have higher
   probability to successfully reach the nearer copy of the requested
   content.

Hong, et al.           Expires January 4, 2018               [Page 12]
Internet-Draft            NRS Requirements                   July 2017

   The NRS deployment should balance the number of nodes involved in
   the name resolution and the overhead/cost for the name record
   replication. To ensure the low latency, the NRS should be able to
   route a content request to the closest copy. Message forwarding and
   processing should be efficient and computation complexity should be
   reasonable low and affordable by the current processor technologies.

5.1.2. Time transiency

   The NRS should support time-transient content, which is frequently
   created in and disappearing from the network. This kind of content
   only stays in the network for a short time, which requires the NRS
   to be able to promptly reflect the records of them in the system.
   For example, some video clip only exists in the network for a very
   short time, which requires the NRS to promptly update their name
   records.

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.1.4. Accuracy

   The NRS must provide accurate and up-to-date information on how to
   reach the producer(s) of requested content with minimum overhead in
   propagating the update information. Content mobility and expiration
   must be reflected in the corresponding records in the NRS system
   with minimum delay to guarantee the accurate resolution.

   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.2. System aspects

   We enumerate the requirements on system aspect.

5.2.1. Scalability

   The NRS system must to 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.

Hong, et al.           Expires January 4, 2018               [Page 13]
Internet-Draft            NRS Requirements                   July 2017

   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. The memory requirement for NRS nodes should
   be achievable by the current memory technologies.

5.2.2. Fault tolerance

   The NRS 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. The NRS must also ensure resolution failure
   at one NRS node would be resolved and corrected by other NRS nodes.

   For example, in the standalone name resolution approach, when a NRS
   overlay server fails, the name records should be able to transferred
   and recovered in its peer server or its replacement. In the name
   based approach, the failure of one ICN router does not cause much
   trouble in the name resolution, because the other alternative paths
   can be established that bypass the failed ICN router. However, it
   requires that the ICN router has propagated its name based routing
   information in the network.

5.2.3. Minimum inter-domain traffic

   The NRS must attempt to minimize total traffic, and inter-domain
   traffic in particular. In order to achieve that, message propagation
   for name resolution and retrieval should retain the locality and
   should be kept in the network domain if that domain contains both
   the client and the content copy.

   For example, a client is requesting the temperature data of the
   building that he/she is residing in, the NRS should be able to
   return or route to the nearest gateway in the building that stores
   such data instead of a remote server in the cloud.

5.2.4. Manageability

   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.

5.2.5. 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 January 4, 2018               [Page 14]
Internet-Draft            NRS Requirements                   July 2017

5.2.6. Interoperability

   Considering the emergence of IoT applications, many standard bodies
   for IoT have settled their ways for resource/data management. For
   example:

   - oneM2M[19] uses tree structure to store resources. Each resource
   is addressable by its URI. oneM2M resources are linked together by
   parent-child relationship or link relationship with pointers.
   Resource resolution is indicated in the hierarchical name of the
   resources. With one entrance, a client can go anywhere within the
   tree structure. As an example, a content is stored under the
   container with URI prefix of /CSEBase-ID/AE-ID/container
   ID/contentInstance-ID. From the URI of the content, a client would
   be able to easily do the name resolution and go to the oneM2M server
   identified by CSEBase-ID.

   - IETF CoRE[21] specifies the Resource Directory (RD) [23] for
   resource registration and resolution. A RD is a database that stores
   links about resources hosted by endpoints (EP), which are called RD
   entries. An EP is a server that is associated with a scheme (e.g.
   CoAP[22] by default, or HTTP), IP address and port.

   It is likely that a physical IoT node may host one or more Eps. The
   RD provides a set of RESTful interface for EPs to register and
   maintain sets of RD entries, and for clients to look up resources.

   In order for the ICN infrastructure to support IoT applications, the
   NRS should provide the interoperability between those existing
   resource registries as well as integration of them into the ICN
   infrastructure. The NRS should allow different providers to coexist
   and for requesters to choose one or more preferred providers on
   their own.

5.3. Security aspect

   We enumerate the requirements on service aspect for both the node
   and data.

5.3.1. Accessibility

   The NRS system must be prevented from the malicious users attempting
   to hijack or corrupt name records.

Hong, et al.           Expires January 4, 2018               [Page 15]
Internet-Draft            NRS Requirements                   July 2017

   The name records must have proper access rights such that the
   information contained in the name record would not be revealed to
   unauthorized users.

   The name records may be associated within certain domain, and cannot
   be propagated outside the domain. For example, for content that is
   only shared within the community should be restricted within the
   community network, outside of which the content may not exist.

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

   [TBD]

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

   [TBD]

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

   [TBD]

6. Security Considerations

   [TBD]

7. IANA Considerations

   This document makes no specific request of IANA.

Hong, et al.           Expires January 4, 2018               [Page 16]
Internet-Draft            NRS Requirements                   July 2017

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, <http://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,
             <http://www.rfc-editor.org/info/rfc7927>.

8.2. Informative References

   [1]  G. Xylomenos, C. N. Ververidis, V. A. Siris, N. Fotiou,
         C.Tsilopoulos, X. Vasilakos, K. V. Katsaros, and G. C.
         Polyzos, A Survey of Information-Centric Networking Research,
         Communications Surveys and Tutorials, Vol. 16, No. 2, 2014,
         pp. 1024-1049.

   [2]  E. Baccelli, C. Mehlis, O. Hahm, T. Schmidt, and M. Wahlisch,
         Information Centric Networking in the IoT: Experiments with
         NDN in the Wild, in ACM ICN, 2014.

   [3]  Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, Named data
         networking for IoT: An architectural perspective, in European
         Conference on Networks and Communications (EuCNC), 2014.

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

   [5]  FP7 PURSUIT project. http://www.fp7-pursuit.eu/PursuitWeb/.

   [6]  FP7 SAIL project. http://www.sail-project.eu/.

   [7]  NSF Named Data Networking project. http://www.named-data.net/.

   [8]  Content Centric Networking project. http://www.ccnx.org/.

   [9]  NSF Mobility First project.
         http://mobilityfirst.winlab.rutgers.edu/.

Hong, et al.           Expires January 4, 2018               [Page 17]
Internet-Draft            NRS Requirements                   July 2017

   [10] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N.H.
         Briggs, and R. L. Braynard, "Networking Named Content." in ACM
         CoNEXT, 2009.

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

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

   [13] J. Rajahalme, M. Sarela, K. Visala, and J. Riihijarvi, "On
         Name-based Inter-domain Routing," Computer Networks, vol. 55,
         no. 4, pp. 975-986, March 2011.

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

   [15] Namespace Resolution in Future Internet Architectures, draft-
         wang-fia-namespace-01.

   [16] PID: A Generic Naming Schema for Information-centric Network,
         draft-zhang-icnrg-pid-naming-scheme-03.

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

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

   [19] On the Naming and Binding of Network Destinations,
         https://tools.ietf.org/html/rfc1498.

   [20] oneM2M Functional Architecture TS 0001,
         http://www.onem2m.org/technical/published-documents.

   [21] Constrained RESTful Environments, CoRE,
         https://datatracker.ietf.org/wg/core/charter/, 2013.

   [22] RFC 7252, The Constrained Application Protocol (CoAP).

Hong, et al.           Expires January 4, 2018               [Page 18]
Internet-Draft            NRS Requirements                   July 2017

   [23] CoRE Resource Directory,
         https://datatracker.ietf.org/doc/draft-ietf-core-resource-
         directory/.

   [24] C. Westphal, E. Demirors, An IP-based Manifest Architecture
         for ICN, 2nd ACM Conference on Information-Centric Networking
         (ICN 2015).

   [25] M. Mosko, G. Scott , I. Solis , C. Wood, CCNx Manifest
         Specification, http://www.ccnx.org/pubs/draft-wood-icnrg-
         ccnxmanifests-00.html.

   [26] The Locator/ID Separation Protocol (LISP),
         https://datatracker.ietf.org/doc/rfc6830/.

   [27] Locator/ID Separation Protocol (LISP) Map-Server Interface,
         https://datatracker.ietf.org/doc/rfc6833/.

   [28] Ahlgren, B. et al., "A Survey of Information-Centric
         Networking", IEEE Communications Magazine vol. 50, no. 7, July
         2012.

   [29] Xylomenos, G. et al., "A Survey of Information-Centric
         Networking Research", IEEE Communications Surveys and
         Tutorials vol. 16, no. 2, 2014.

   [30] 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.

   [31] 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.

   [32] Quevedo, J., Corujo, D., and R. Aguiar, "A case for ICN usage
         in IoT environments", IEEE GLOBECOM, 2014.

   [33] Amadeo, M. et al., "Information-centric networking for the
         internet of things: challenges and opportunities", IEEE
         Network vol. 30, no. 2, July 2016.

   [34] Zhang, Y. et al., " Design Considerations for Applying ICN to
         IoT", Internet Draft, draft-zhang-icnrg-icniot-00, March 2017.

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

Hong, et al.           Expires January 4, 2018               [Page 19]
Internet-Draft            NRS Requirements                   July 2017

   [36]  Yu Zhang et al., "A Survey of Mobility Support in Named Data
         Networking," NOM 2016.

   [37] R. Ravindran et al., "Forwarding-Label support in CCN
         Protocol," IETF draft, March 2016.

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

   [39] Marc Mosko, "Nameless Objects," July 2015.

Hong, et al.           Expires January 4, 2018               [Page 20]
Internet-Draft            NRS Requirements                   July 2017

Authors' Addresses

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

   Phone: +82-42-860-0926
   Email: jhong@etri.re.kr

   Lijun Dong
   Huawei Technologies
   10180 Telesis Court
   Suite 220
   San Diego, CA, 92121

   Phone:
   Email: lijun.dong@huawei.com

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

   Phone: +82-42-860-0642
   Email: twyou@etri.re.kr

   Cedric Westphal
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA 95050

   Phone:
   Email: cedric.westphal@huawei.com

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

   Phone: +82-42-860-6557
   Email: yghong@etri.re.kr

Hong, et al.           Expires January 4, 2018               [Page 21]
Internet-Draft            NRS Requirements                   July 2017

   GQ Wang
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA 95050

   Phone:
   Email: gq.wang@huawei.com

   Jianping Wang
   City University Hong Kong

   Phone:
   Email: jianwang@cityu.edu.hk

Hong, et al.           Expires January 4, 2018               [Page 22]