| Internet-Draft | Design Considerations for NRS | July 2021 |
| Hong, et al. | Expires 29 January 2022 | [Page] |
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).¶
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 29 January 2022.¶
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 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.¶
The current Internet is based upon a host-centric networking paradigm, where hosts are 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]:¶
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 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.¶
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.¶
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].¶
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.¶
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.¶
The following compares the explicit name resolution and the name-based routing approaches for several aspects:¶
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.¶
This section presents the functionalities of an NRS in ICN.¶
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, 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).¶
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 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.¶
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.¶
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.¶
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 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.¶
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.¶
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.¶
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].¶
This section presents the design considerations for NRS in ICN.¶
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.¶
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.¶
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.¶
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.¶
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 [RFC9064] 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.¶
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. 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.¶
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.¶
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.¶
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.¶
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.¶
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 specific user's NRS requests should not be shared outside the NRS system (with the exception of legal intercept).¶
The NRS system must be prevented from malicious users attempting to hijack or corrupt the name mapping records.¶
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.¶
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.¶
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.¶
There are no IANA considerations related to this document.¶
A discussion of security guidelines was provided in section 4.9.¶
The authors would like to thank Dave Oran, Dirk Kutscher, Ved Kafle, Vincent Roca, Marie-Jose Montpetit, Stephen Farrell, Mirja Kuhlewind, and Colin Perkins for very useful reviews, comments and improvement on the document.¶