ICN Research Group                                               J. Hong
Internet-Draft                                                    T. You
Intended status: Informational                                      ETRI
Expires: October 13, 2021                                        L. Dong
                                                             C. Westphal
                                             Futurewei Technologies Inc.
                                                               B. Ohlman
                                                                Ericsson
                                                          April 11, 2021


        Design Considerations for Name Resolution Service in ICN
                  draft-irtf-icnrg-nrs-requirements-05

Abstract

   This document provides the functionalities and design considerations
   for a Name Resolution Service (NRS) in ICN.  An NRS in ICN is to
   translate an object name into some other information such as a
   locator, another name, etc. for forwarding the object request.  This
   document is a product of the Information-Centric Networking Research
   Group (ICNRG).

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 13, 2021.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of



Hong, et al.            Expires October 13, 2021                [Page 1]


Internet-Draft        Design Considerations for NRS           April 2021


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Name Resolution Service in ICN  . . . . . . . . . . . . . . .   4
     2.1.  Explicit name resolution approach . . . . . . . . . . . .   4
     2.2.  Name-based routing approach . . . . . . . . . . . . . . .   4
     2.3.  Hybrid approach . . . . . . . . . . . . . . . . . . . . .   5
     2.4.  Comparisons of name resolution approaches . . . . . . . .   5
   3.  Functionalities of NRS in ICN . . . . . . . . . . . . . . . .   6
     3.1.  Support heterogeneous name types  . . . . . . . . . . . .   6
     3.2.  Support producer mobility . . . . . . . . . . . . . . . .   7
     3.3.  Support scalable routing system . . . . . . . . . . . . .   9
     3.4.  Support off-path caching  . . . . . . . . . . . . . . . .   9
     3.5.  Support nameless object . . . . . . . . . . . . . . . . .  10
     3.6.  Support manifest  . . . . . . . . . . . . . . . . . . . .  10
     3.7.  Support metadata  . . . . . . . . . . . . . . . . . . . .  11
   4.  Design considerations for NRS in ICN  . . . . . . . . . . . .  11
     4.1.  Resolution response time  . . . . . . . . . . . . . . . .  11
     4.2.  Response accuracy . . . . . . . . . . . . . . . . . . . .  11
     4.3.  Resolution guarantee  . . . . . . . . . . . . . . . . . .  12
     4.4.  Resolution fairness . . . . . . . . . . . . . . . . . . .  12
     4.5.  Scalability . . . . . . . . . . . . . . . . . . . . . . .  12
     4.6.  Manageability . . . . . . . . . . . . . . . . . . . . . .  13
     4.7.  Deployed system . . . . . . . . . . . . . . . . . . . . .  14
     4.8.  Fault tolerance . . . . . . . . . . . . . . . . . . . . .  14
     4.9.  Security and privacy  . . . . . . . . . . . . . . . . . .  14
       4.9.1.  Confidentiality . . . . . . . . . . . . . . . . . . .  14
       4.9.2.  Authentication  . . . . . . . . . . . . . . . . . . .  15
       4.9.3.  Integrity . . . . . . . . . . . . . . . . . . . . . .  15
       4.9.4.  Resiliency and availability . . . . . . . . . . . . .  15
   5.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  15
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  16
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19






Hong, et al.            Expires October 13, 2021                [Page 2]


Internet-Draft        Design Considerations for NRS           April 2021


1.  Introduction

   The current Internet is based upon a host-centric networking
   paradigm, 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 the
   host (or server) where information is stored.  In contrast to host-
   centric networking, the primary communication objects in Information-
   centric networking (ICN) are the named data objects (NDOs) and they
   are uniquely identified by location-independent names.  Thus, ICN
   aims for the efficient dissemination and retrieval of NDOs at a
   global scale, and has been identified and acknowledged as a promising
   technology for a future Internet architecture to overcome the
   limitations of the current Internet such as scalability and mobility
   [Ahlgren] [Xylomenos].  ICN also has emerged as a candidate
   architecture in the IoT environment since IoT focuses on data and
   information [Baccelli] [Amadeo] [Quevedo] [Amadeo2] [ID.Zhang2].

   Since naming data independently from its current location (where it
   is stored) is a primary concept of ICN, how to find any NDO using a
   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 the locator
      of content producer or source that can provide the content.

   o  Content request routing: routes the content request towards the
      content's location either based on its name or locator.

   o  Content delivery: transfers the content to the requester.

   Among the three steps of ICN routing, this document investigates only
   the name resolution step which translates a content name to the
   content locator.  In addition, this document covers various possible
   types of name resolution in ICN such as one name to another name,
   name to locator, name to manifest, name to metadata, etc.

   The focus of this document is a Name Resolution Service (NRS) itself
   as a service or a system in ICN and it provides the functionalities
   and the design considerations for an NRS in ICN as well as the
   overview of the NRS approaches in ICN.  On the other hand, its
   companion document [NRSarch] describes considerations from the
   perspective of ICN architecture and routing system when using an NRS
   in ICN.

   This document represents the consensus of the Information-Centric
   Networking Research Group (ICNRG).  It has been reviewed extensively



Hong, et al.            Expires October 13, 2021                [Page 3]


Internet-Draft        Design Considerations for NRS           April 2021


   by the Research Group (RG) members who are actively involved in the
   research and development of the technology covered by this document.
   It is not an IETF product and is not a standard.

2.  Name Resolution Service in ICN

   A Name Resolution Service (NRS) in ICN is defined as the service that
   provides the name resolution function for translating an object name
   into some other information such as a locator, another name,
   metadata, next hop info, etc. that is used for forwarding the object
   request.  In other words, an NRS is a service that can be provided by
   the ICN infrastructure to help a consumer to reach a specific piece
   of information (or named data object).  The consumer provides an NRS
   with a persistent name and the NRS returns a name or locator (or
   potentially multiple names and locators) that can reach a current
   instance of the requested object.

   The name resolution is a necessary process in ICN routing although
   the name resolution either can be separated from the content request
   routing as an explicit process or can be integrated with the content
   request routing as an implicit process.  The former is referred as
   explicit name resolution approach, the latter is referred as name-
   based routing approach in this document.

2.1.  Explicit name resolution approach

   An NRS could take the explicit name resolution approach to return the
   locators of the content to the client, which will be used by the
   underlying network as the identifier to route the client's request to
   one of the producers or to a copy of the content.  There are several
   ICN projects that use the explicit name resolution approach such as
   DONA [Koponen], PURSUIT [PURSUIT], NetInf [SAIL], MobilityFirst [MF],
   IDNet [Jung], etc.  In addition, the explicit name resolution
   approach has been allowed for 5G control planes [SA2-5GLAN].

2.2.  Name-based routing approach

   An NRS could take the name-based routing approach, which integrates
   the name resolution with the content request message routing as in
   NDN [NDN]/CCNx [CCNx].

   In the case that the content request also specifies the reverse path,
   as in NDN/CCNx, the name resolution mechanism also derives 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 finding a copy of the content, but
   also properly delivering the data.



Hong, et al.            Expires October 13, 2021                [Page 4]


Internet-Draft        Design Considerations for NRS           April 2021


2.3.  Hybrid approach

   An NRS could also take hybrid approach.  For instance, it can attempt
   the name-based routing approach first.  If this fails at a certain
   router, the router can go back to the explicit name resolution
   approach.  The hybrid NRS approach also works the other way around by
   performing explicit name resolution first to find locators of
   routers.  And then it can carry out the name-based routing approach
   of the client's request.

   A hybrid approach would combine name resolution over 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 ICN
   network perform name resolution in the name-based routing approach.

2.4.  Comparisons of name resolution approaches

   The following compares the explicit name resolution and the name-
   based routing approaches for several aspects:

   o  Overhead due to the maintenance of the content location: The
      content reachability is dynamic and includes new content being
      cached or content being expired from a cache, content producer
      mobility, etc.  Maintaining a consistent view of the content
      location across the network requires some overhead that differs
      for the name resolution approaches.  The name-based routing
      approach may require flooding parts 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).  However, the explicit name resolution
      approach only requires updating propagation in part of the name
      resolution system (which could be an overlay with a limited number
      of nodes).

   o  Resolution capability: The explicit name resolution approach, if
      designed and deployed with sufficient robustness, can offer at
      least weak guarantees that resolution will succeed for any content
      name in the network if it is registered to the name resolution
      overlay.  In the name-based routing approach, content resolution
      depends on the flooding scope of the content names (i.e. content
      publishing message and the resulting name-based routing tables).
      For example, when a content is cached, the router may only notify
      this information to its direct neighbors.  Thus, only those
      neighboring routers can build a named based entry for this cached
      content.  But if the neighboring routers continue to propagate
      this information, the other nodes are able to direct to this
      cached copy as well.




Hong, et al.            Expires October 13, 2021                [Page 5]


Internet-Draft        Design Considerations for NRS           April 2021


   o  Node failure impact: Nodes involved in the explicit 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 the name-based routing tables (e.g.  NDN routers).  Node
      failures in the explicit name resolution approach may cause some
      content request routing 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 explicit name
      resolution approach is different from that of the name-based
      routing approach.  The explicit 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 only the name-based routing tables.

   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 [Westphal] [Mosko].  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.

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

3.  Functionalities of NRS in ICN

   This section presents the functionalities of an NRS in ICN.

3.1.  Support heterogeneous name types

   In ICN, a name is used to identify data object and is bound to it
   [RFC7927].  ICN requires uniqueness and persistency of the name of
   data object to ensure the reachability of the object within a certain
   scope.  There are heterogeneous approaches to designing ICN naming
   schemes [Bari].  Ideally, a name can include any form of identifier,




Hong, et al.            Expires October 13, 2021                [Page 6]


Internet-Draft        Design Considerations for NRS           April 2021


   which can be flat or hierarchical, and human readable or non-
   readable.

   Although there are diverse types of naming schemes proposed in
   literature, they all need to provide basic functions for identifying
   data object, supporting named data lookup and routing.  An NRS may
   combine the better aspects of different schemes.  Basically, an NRS
   should be able to support a generic naming schema so that it can
   resolve any type of content name, irrespective of whether it is flat,
   hierarchical, attribute-based or anything else.

   In PURSUIT [PURSUIT], names are flat and the rendezvous functions are
   defined for an NRS, which is implemented by a set of Rendezvous Nodes
   (RNs), the Rendezvous Network (RENE).  Thus, a name consists of a
   sequence of scope IDs and a single rendezvous ID is routed by the RNs
   in RENE.  Thus, PURSUIT decouples name resolution and data routing,
   where the 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 a flat typed 160-bits string with self-certifying properties.
   Thus, MobilityFirst defines a Global Name Resolution Service (GNRS)
   which resolves GUIDs to network addresses and decouples name
   resolution and data routing similarly to PURSUIT.

   In NetInf [Dannewitz], information objects are named using ni-naming
   [RFC6920], which consist of an authority part and digest part
   (content hash).  The ni names can be flat as the authority part is
   optional.  Thus, the NetInf architecture also includes a Name
   Resolution System (NRS) which can be used to resolve ni-names to
   addresses in an underlying routable network layer.

   In NDN [NDN] and CCNx [CCNx], names are hierarchical and may be
   similar to URLs.  Each name component can be anything, including a
   human-readable string or a hash value.  NDN/CCNx adopts the name-
   based routing approach.  The NDN router forwards the request by doing
   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).

3.2.  Support producer mobility

   ICN natively supports mobility management.  Namely, consumer or
   client mobility is handled by re-requesting the content in case the
   mobility event (say, handover) occurred before receiving the
   corresponding content from the network.  Since ICN can ensure that
   content reception continues without any disruption in ICN




Hong, et al.            Expires October 13, 2021                [Page 7]


Internet-Draft        Design Considerations for NRS           April 2021


   applications, seamless mobility from the consumer's point of view can
   be easily supported.

   However, producer mobility does not emerge naturally from the ICN
   forwarding model as does consumer mobility.  If a producer moves into
   a different network location or a different name domain, which is
   assigned by another authoritative publisher, it would be difficult
   for the mobility management to update RIB and FIB entries in ICN
   routers with the new forwarding path in a very short time.
   Therefore, various ICN architectures in the literature have proposed
   to adopt an NRS to achieve the producer or publisher mobility, where
   the NRS can be implemented in different ways such as rendezvous
   points and/or overlay mapping systems.

   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).  This can be classified into two
   approaches: 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 name of
   the MP's current point of attachment (PoA).  Alternatively, the RV
   serves as a home agent as in IP mobility support, so the RV enables
   consumer's interest message to tunnel towards the MP at the PoA.
   Regarding rendezvous data, the solution involves moving the data
   produced by the MP to a 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 an 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 the network
   domains or to 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 an 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/CCNx.





Hong, et al.            Expires October 13, 2021                [Page 8]


Internet-Draft        Design Considerations for NRS           April 2021


   In NetInf [Dannewitz], mobility is handled by an NRS in a very
   similar way to MobilityFirst.

   Besides the consumer and producer mobility, ICN also has to face
   challenges to support the other dynamic features such as multi-
   homing, migration, and replication of named resources such as
   content, devices, and services.  Therefore, an NRS can help to
   support these dynamic features.

3.3.  Support scalable routing system

   In ICN, the name of data objects is used for routing by either a name
   resolution step or a routing table lookup.  Thus, routing information
   for each data object should be maintained in the routing base, such
   as Routing Information Base (RIB) and Forwarding Information Base
   (FIB).  Since the number of data objects would be very large, the
   size of information bases would be significantly larger as well
   [RFC7927].

   The hierarchical namespace used in CCNx [CCNx] and NDN [NDN]
   architectures reduces the size of these tables through name
   aggregation and improves the scalability of the routing system.  A
   flat naming scheme, on the other hand, would aggravate the
   scalability problem of the routing system.  The non-aggregated name
   prefixes injected to the Default Route Free Zone (DFZ) of ICN would
   create more serious scalability problem when compared to the
   scalability issues of the IP routing system.  Thus, an NRS may play
   an important role in the reduction of the routing scalability problem
   regardless of the types of namespaces.

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

3.4.  Support off-path caching

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



Hong, et al.            Expires October 13, 2021                [Page 9]


Internet-Draft        Design Considerations for NRS           April 2021


   path from the original server to the consumer.  Off-path caching,
   also referred as content 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 an
   NRS.

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

3.5.  Support nameless object

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

3.6.  Support manifest

   For collections of data objects which are organized as large and file
   like contents [FLIC], manifests are used as data structures to
   transport this information.  Thus, 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 such 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 such as an NRS may be involved to give this
   information to the consumer.




Hong, et al.            Expires October 13, 2021               [Page 10]


Internet-Draft        Design Considerations for NRS           April 2021


3.7.  Support metadata

   When resolving the name of a content object, NRS could return a rich
   set of metadata in addition to returning a locator.  The metadata
   could include alternative object locations, supported object transfer
   protocol(s), caching policy, security parameters, data format, hash
   of object data, etc.  The consumer could use this metadata for
   selection of object transfer protocol, security mechanism, egress
   interface, etc.  An example of how metadata can be used in this way
   is provided by the NEO ICN architecture [NEO].

4.  Design considerations for NRS in ICN

   This section presents the design considerations for NRS in ICN, not
   requirements.  The key words "MUST", "MAY", and "SHOULD" in this
   section are used consistently with [RFC2119].

4.1.  Resolution response time

   The name resolution process should provide a response within a
   reasonable amount of time.  The response should be either a proper
   mapping of the name to a copy of the content, or an error message
   stating that no such object exists.  If the name resolution does not
   map to a location, the system may not issue any response, and the
   client should set a timer when sending a request, so as to consider
   the resolution incomplete when the timer expires.

   The acceptable response delay could be of the order of a round trip
   time between the client issuing the request and the NRS servers that
   provides the response.  While this RTT may vary greatly depending on
   the proximity between the two end points, some upper bound need be
   used.  Especially, in some delay-sensitive scenarios such as
   industrial Internet and telemedicine, the upper bound of the response
   delay must be guaranteed.

   The response time includes all the steps of the resolution, including
   potentially a hop-by-hop resolution or a hierarchical forwarding of
   the resolution request.

4.2.  Response accuracy

   An NRS must provide an accurate response, namely a proper binding of
   the requested name (or prefix) with a location.  The response can be
   either a (prefix, location) pair, or the actual forwarding of a
   request to a node holding the content, which is then transmitted in
   return.





Hong, et al.            Expires October 13, 2021               [Page 11]


Internet-Draft        Design Considerations for NRS           April 2021


   An NRS must provide an up-to-date response, namely an NRS should be
   updated within a reasonable time when new copies of the content are
   being stored in the network.  While every transient cache addition/
   eviction should not trigger an NRS update, some origin servers may
   move and require the NRS to be updated.

   An NRS must provide mechanisms to update the mapping of the content
   with its location.  Namely, an NRS must provide a mechanism for a
   content provider to add new content, revoke old/dated/obsolete
   content, and modify existing content.  Any content update should then
   be propagated through the NRS system within reasonable delay.

   Content that is highly mobile may require to specify some type of
   anchor that is kept at the NRS, instead of the content location.

4.3.  Resolution guarantee

   An NRS must ensure that the name resolution is successful with high
   probability if the name matching content exists in the network,
   regardless of its popularity and number of cached copies existing in
   the network.  As per Section 4.1, some resolution may not occur in a
   timely manner.  However, the probability of such event should be
   minimized.  The NRS system may provide a probability (say, five 9s,
   or five sigmas for instance) that a resolution will be satisfied.

4.4.  Resolution fairness

   An NRS could provide this service for all content in a fair manner,
   independently of the specific content properties (content producer,
   content popularity, availability of copies, content format, etc.).
   Fairness may be defined as a per request delay to complete the NRS
   steps that is not agnostic to the properties of the content itself.
   Fairness may be defined as well as the number of requests answered
   per unit of time.

   However, it is notable that content (or their associated producer)
   may request a different level of QoS from the network (see [QoSarch]
   for instance), and this may include the NRS as well, in which case
   considerations of fairness may be restricted to content within the
   same class of service.

4.5.  Scalability

   The NRS system must scale up to support a very large user population
   (including human users as well as machine-to-machine communications).
   As an idea of the scale, it is expected that 50 billion devices will
   be connected in 2025 (per ITU projections).  The system must be able
   to respond to a very large number of requests per unit of time.



Hong, et al.            Expires October 13, 2021               [Page 12]


Internet-Draft        Design Considerations for NRS           April 2021


   Message forwarding and processing, routing table building-up and name
   records propagation must be efficient and scalable.

   The NRS system must scale up with the number of pieces of content
   (content names) and should be able to support a content catalog that
   is extremely large.  Internet traffic is of the order of the
   zettabytes per year (10^21 bytes).  Since NRS is associated with
   actual traffic, the number of pieces of content should scale with the
   amount of traffic.  Content size may vary from a few bytes to several
   GB, so the NRS should be expected scale up to catalog of the size of
   10^21 in the near future, and larger beyond.

   The NRS system must be able to scale up, namely to add NRS servers to
   the NRS system, in a way that is transparent to the users.  Addition
   of a new server should have limited negative impact on the other NRS
   servers (or should have a negative impact on only a small subset of
   the NRS servers).  The impact of adding new servers may induce some
   overhead at the other servers to rebuild a hierarchy or to exchange
   messages to include the new server within the service.  Further, data
   may be shared among the new servers, for load balancing or tolerance
   to failure.  These steps should not disrupt the service provided by
   the NRS and should in the long run improve the quality of the
   service.

   The NRS system may support access from a heterogeneity of connection
   methods and devices.  In particular, the NRS system may support
   access from constrained devices and interactions with the NRS system
   would not be too costly.  An IoT node for instance should be able to
   access the NRS system as well as a more powerful node.

   The NRS system should scale up in its responsiveness to the increased
   request rate that is expected from applications such as IoT or M2M,
   where data is being frequently generated and/or frequently requested.

4.6.  Manageability

   The NRS system must be manageable since some parts of the system may
   grow or shrink dynamically and an NRS system node may be added or
   deleted frequently.

   The NRS system may support an NRS management layer that allows for
   adding or subtracting NRS nodes.  In order to infer the circumstance,
   the management layer can measure network status.








Hong, et al.            Expires October 13, 2021               [Page 13]


Internet-Draft        Design Considerations for NRS           April 2021


4.7.  Deployed system

   The NRS system must be deployable since deployability is important
   for a real-world system.  The NRS system must be deployable in
   network edges and cores so that the consumers as well as ICN routers
   can perform name resolution in a very low latency.

4.8.  Fault tolerance

   The NRS system must ensure resiliency in the event of NRS server
   failures.  The failure of a small subset of nodes should not impact
   the NRS performance significantly.

   After an NRS server fails, the NRS system must be able to recover
   and/or restore the name records stored in the NRS server.

4.9.  Security and privacy

   On utilizing an NRS in ICN, there are some security considerations
   for the NRS servers/nodes and name mapping records stored in the NRS
   system.  This subsection describes them.

4.9.1.  Confidentiality

   The name mapping records in the NRS system must be assigned with
   proper access rights such that the information contained in the name
   mapping records would not be revealed to unauthorized users.

   The NRS system may support access control for certain name mapping
   records.  Access control can be implemented with a reference monitor
   that uses client authentication, so only users with appropriate
   credentials can access these records, and they are not shared with
   unauthorized users.  Access control can also be implemented by
   encryption-based techniques using control of keys to control the
   propagations of the mappings.

   The NRS system may support obfuscation and/or encryption mechanisms
   so that the content of a resolution request may not be accessible by
   third parties outside of the NRS system.

   The NRS system must keep confidentiality to prevent sensitive name
   mapping records from being reached by unauthorized data requesters.
   This is more required in IoT environments where a lot of sensitive
   data is produced.

   The NRS system must also keep confidentiality of meta-data as well as
   NRS usage to protect the privacy of the users.  For instance, a




Hong, et al.            Expires October 13, 2021               [Page 14]


Internet-Draft        Design Considerations for NRS           April 2021


   specific user's NRS requests should not be shared outside the NRS
   system (with the exception of legal intercept).

4.9.2.  Authentication

   o  NRS server authentication: Authentication of the new NRS servers/
      nodes that want to be registered with the NRS system must be
      required so that only authenticated entities can store and update
      name mapping records.  The NRS system should detect an attacker
      attempting to act as a fake NRS server to cause service disruption
      or manipulate name mapping records.

   o  Producer authentication: The NRS system must support
      authentication of the content producers to ensure that
      update/addition/removal of name mapping records requested by
      content producers are actually valid and that content producers
      are authorized to modify (or revoke) these records or add new
      records.

   o  Mapping record authentication: The NRS should verify new mapping
      records that are being registered so that it cannot be polluted
      with falsified information or invalid records.

4.9.3.  Integrity

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

4.9.4.  Resiliency and availability

   The NRS system should be resilient against denial of service attacks
   and other common attacks to isolate the impact of the attacks and
   prevent collateral damage to the entire system.  Therefore, if a part
   of the NRS system fails, the failure should only affect a local
   domain.  And fast recovery mechanisms need to be in place to bring
   the service back to normal.

5.  Conclusion

   ICN routing may comprise three steps: name resolution, content
   request routing, and content delivery.  This document investigates
   the name resolution step, which is the first and most important to be
   achieved for ICN routing to be successful.  A Name Resolution Service
   (NRS) in ICN is defined as the service that provides such a function
   of name resolution for translating an object name into some other
   information such as a locator, another name, metadata, next hop info,
   etc. that is used for forwarding the object request.




Hong, et al.            Expires October 13, 2021               [Page 15]


Internet-Draft        Design Considerations for NRS           April 2021


   This document classifies and analyzes the NRS approaches according to
   whether the name resolution step is separated from the content
   request routing as an explicit process or not.  This document also
   explains the NRS functions used to support heterogeneous name types,
   producer mobility, scalable routing system, off-path caching,
   nameless object, manifest, and metadata.  Finally, this document
   presents design considerations for NRS in ICN, which include
   resolution response time and accuracy, resolution guarantee,
   resolution fairness, scalability, manageability, deployed system, and
   fault tolerance.

6.  IANA Considerations

   There are no IANA considerations related to this document.

7.  Security Considerations

   A discussion of security guidelines was provided in section 4.9.

8.  Acknowledgements

   The authors would like to thank Dave Oran (ICNRG Co-chair), Ved
   Kafle, and Vincent Roca for very useful reviews, comments and
   improvement on the document.

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

   [RFC7927]  Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I.,
              Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
              "Information-Centric Networking (ICN) Research
              Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,
              <https://www.rfc-editor.org/info/rfc7927>.

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.





Hong, et al.            Expires October 13, 2021               [Page 16]


Internet-Draft        Design Considerations for NRS           April 2021


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

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

   [ID.Zhang2]
              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.",
              http://www.fp7-pursuit.eu/PursuitWeb/ .

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

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

   [CCNx]     "Content Centric Networking project.",
              https://wiki.fd.io/view/Cicn .

   [MF]       "NSF Mobility First project.",
              http://mobilityfirst.winlab.rutgers.edu/ .





Hong, et al.            Expires October 13, 2021               [Page 17]


Internet-Draft        Design Considerations for NRS           April 2021


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

   [SA2-5GLAN]
              3gpp-5glan, "SP-181129, Work Item Description,
              Vertical_LAN(SA2), 5GS Enhanced Support of Vertical and
              LAN Services", 3GPP ,
              http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_82/Docs/SP-
              181120.zip.

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

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

   [RFC6920]  Farrell , S., Kutscher, D., Dannewitz, C., Ohlman, B.,
              Keranen, A., and P. Hallam-Baker, "Naming Things with
              Hashes", RFC6920, DOI 10.17487/RFC6920,
              https://rfc-editor.org/rfc/rfc6920.txt , Apr. 2013.

   [Zhang2]   Zhang, Y., "A Survey of Mobility Support in Named Data
              Networking", NAMED-ORIENTED MOBILITY: ARCHITECTURES,
              ALGORITHMS, AND APPLICATIONS(NOM) , 2016.

   [Dannewitz]
              Dannewitz, C. et al., "Network of Information (NetInf)-An
              information centric networking architecture", Computer
              Communications vol. 36, no. 7, April 2013.

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

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



Hong, et al.            Expires October 13, 2021               [Page 18]


Internet-Draft        Design Considerations for NRS           April 2021


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

   [NEO]      Eriksson, A. and A. M. Malik, "A DNS-based information-
              centric network architecture open to multiple protocols
              for transfer of data objects", 21st Conference on
              Innovation in Clouds, Internet and Networks and Workshops
              (ICIN), pp. 1-8, 2018.

   [NRSarch]  Hong, J. et al., "Architectural Considerations of ICN
              using Name Resolution Service", draft-irtf-icnrg-nrsarch-
              considerations-05 , September 2020.

   [QoSarch]  Oran, D., "Considerations in the development of a QoS
              Architecture for CCNx-like ICN protocols", draft-oran-
              icnrg-qosarch-05 , August 2020.

Authors' Addresses

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

   Email: jhong@etri.re.kr


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

   Email: twyou@etri.re.kr


   Lijun Dong
   Futurewei Technologies Inc.
   10180 Telesis Court
   San Diego, CA  92121
   USA

   Email: lijun.dong@futurewei.com



Hong, et al.            Expires October 13, 2021               [Page 19]


Internet-Draft        Design Considerations for NRS           April 2021


   Cedric Westphal
   Futurewei Technologies Inc.
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Email: cedric.westphal@futurewei.com


   Borje Ohlman
   Ericsson Research
   S-16480 Stockholm
   Sweden

   Email: Borje.Ohlman@ericsson.com




































Hong, et al.            Expires October 13, 2021               [Page 20]