| ICN Research Group | J. Hong |
| Internet-Draft | T. You |
| Intended status: Informational | Y-G. Hong |
| Expires: September 12, 2019 | ETRI |
| L. Dong | |
| C. Westphal | |
| Huawei | |
| V. Kafle | |
| NICT | |
| B. Ohlman | |
| Ericsson | |
| March 11, 2019 |
Requirements for Name Resolution Service in ICN
draft-irtf-icnrg-nrs-requirements-01
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 a locator and another name which is used for forwarding the object request towards the object location.
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 September 12, 2019.
Copyright (c) 2019 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 a host-centric networking, where hosts are uniquely identified with IP addresses and communication is possible between any pair of hosts. Thus, information in the current Internet is identified by the name of host where the information is stored. In contrast to the host-centric networking, the primary communication objects in Information-centric networking (ICN) are the named data objects (NDOs) and they are uniquely identified by the location-independent names. Thus, ICN aiming to the efficient dissemination and retrieval of the NDOs in a global scale has been identified and acknowledged as a promising technology for the future Internet architecture to overcome the limitations of the current Internet such as scalability and mobility.[Ahlgren] [Xylomenos]. ICN also has been emerged as a candidate architecture for IoT environment since IoT focuses on data and information rather than end-to-end communications [Baccelli] [Amadeo] [Quevedo] [Amadeo2] [ID.Zhang2].
Since naming data independently from the current location where it is stored is a primary concept of ICN, how to find the NDO using the location-independent name is one of the most important design challenges in ICN. Such ICN routing may comprise three steps [RFC7927] :
Among these three steps of ICN routing, this document focuses only on the name resolution step which translates a content name to the content locators. In addition, this document covers various possible types of name resolution in ICN such as one name to another name, name to manifest, and name to locator.
This document first presents the components of the Name Resolution Service (NRS) in ICN and then discusses the objectives of NRS and the requirements in designing the NRS for ICN.
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].
The 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 and another name that is used for forwarding the object request. In other words, the NRS is the service that shall be provided by ICN infrastructure to help a consumer to reach a specific piece of content, service, or host using a persistent name when the name resolution is needed.
There are two main NRS components:
There are two main NRS processes:
This section presents the objectives and use cases of 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 and with proper authentication and trust management. There are heterogeneous approaches to designing ICN naming schemes [Bari]. Ideally, a name can include any form of identifier, which can be flat, 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 trust provenance, named data lookup and routing. The NRS may combine the good aspects of different schemes. Basically, the 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 or hierarchical.
ICN natively supports mobility management. Especially, consumer or client mobility is handled by requesting the content again in case the mobility or handover occurred before receiving the corresponding content from the network. Since ICN can ensure that content reception continues without any disruption in ICN application, seamless mobility in consumer point of view can be easily supported.
However, producer or publisher mobility in ICN is complicated to support. If a producer moves into a different authority domain or network location, it would be difficult for the mobility management update RIB and FIB entries in ICN routers with the new forwarding path in a very short time. Therefore, various ICN architectures in literatures have proposed to adopt NRS to achieve the producer or publisher mobility, where NRS can be implemented in different ways such as at rendezvous points and overlay mapping systems.
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, NRS can help to support these dynamic features.
In ICN, name of data objects is used for routing by either name resolution step or routing table lookup. Thus, routing information for each data object should be maintained in 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 large as well [RFC7927].
The hierarchical namespace used in CCN [CCN] and NDN [NDN] architectures reduces the size of these tables through name aggregation and improves scalability of routing system. In a flat naming scheme, on the other hand, it would aggravate the scalability problem in routing system. The non-aggregated name prefixes injected to the Default Route Free Zone (DFZ) of ICN would create more serious scalability problem similar to the scalability issue of IP routing system. Thus, NRS may play an important role in the reduction of the routing scalability problem regardless of the types of namespaces.
This subsection describes more specific use cases of NRS reported in ICN literature.
In PURSUIT [PURSUIT], names are flat and the rendezvous functions are defined for NRS, which is implemented by a set of Rendezvous Nodes (RNs), the Rendezvous Network (RENE). Thus a name consisted of a sequence of scope IDs and a single rendezvous ID is routed by RNs in RENE. Thus, PURSUIT decouples name resolution and data routing, where NRS is performed by the RENE.
In MobilityFirst [MF], a name called a global unique Identifier (GUID) derived from a human-readable name via a global naming service is flat typed 160-bits strings with self-certifying function. Thus, MobilityFirst defines a global name resolution service (GNRS) which resolves GUIDs to network addresses and decouples name resolution and data routing as similar to PURSUIT.
In NetInf [Dannewitz], named information (ni) naming consist of an authority part and digest part (content hash). The ni names can be flat as the authority part is optional. Thus, the 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 [Zhang2], for producer mobility support, rendezvous mechanisms have been proposed to build interests rendezvous (RV) with data generated by a mobile producer (MP). There can be classified two approaches such as chase mobile producer and rendezvous data. Regarding MP chasing, rendezvous acts as a mapping service that provides the mapping from the name of the data produced by the MP to the MP's current point of attachment (PoA) name. Alternatively, the RV serves as a home agent like as IP mobility support, so the RV enables consumer's interest message to tunnel towards the MP at the PoA. Regarding rendezvous data, moving the data produced by the MP have been hosting at data depot instead of forwarding interest messages. Thus a consumer's interest message can be forwarded to stationary place as called data rendezvous, so it would either return the data or fetch it using another mapping solution. Therefore, RV or other mapping functions are in the role of NRS in NDN.
In [Ravindran], forwarding-label (FL) object is referred to enable identifier (ID) and locator (LID) namespaces to be split in ICN. Generally, IDs are managed by applications, while locators are managed by a network administrator, so that IDs are mapping to heterogeneous name schemes and LIDs are mapping to network domains or specific network elements. Thus the proposed FL object acts as a locator (LID) and provides the flexibility to forward Interest messages through mapping service between IDs and LIDs. Therefore, the mapping service in control plane infrastructure can be considered as NRS in this draft.
In MobilityFirst [MF], both consumer and publisher mobility can be primarily handled by the global name resolution service (GNRS) which resolves GUIDs to network addresses. Thus, the GNRS must be updated for mobility support when a network attached object changes its point of attachment, which differs from NDN/CCN.
In [Afanasyev], in order to address the routing scalability problem in NDN's DFZ, a well-known concept of Map-and-Encap is applied to provide a simple and secure namespace mapping solution. In the proposed map-and-encap design, data whose name prefixes do not exist in the DFZ forwarding table can be retrieved by a distributed mapping system called NDNS, which maintains and lookups the mapping information from a name to its globally routed prefixes, where NDNS is a kind of NRS.
Caching in-network is considered to be a basic architectural component of an ICN architecture. It may be used to provide a Quality-of-Service (QoS) experience to users, reduce the overall network traffic, prevent network congestion and Denial-of-Service (DoS) attacks and increase availability. Caching approaches can be categorized into off-path caching and on-path caching based on the location of caches in relation to the forwarding path from a original server to a consumer. Off-path caching, also referred as content replication or content storing, aims to replicate content within a network in order to increase availability, regardless of the relationship of the location to the forwarding path. Thus, finding off-path cached objects is not trivial in name based routing of ICN. In order to support off-path caches, replicas are usually advertised into a name- based routing system or into NRS.
In [Bayhan], a NRS used to find off-path copies in the network, which may not be accessible via content discovery mechanisms. Such capability is essential for an Autonomous System (AS) to avoid the costly inter-AS traffic for external content, to yield higher bandwidth efficiency for intra-AS traffic, and to decrease the data access latency for a pleasant user experience.
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 NRS.
In collection of data objects which were organized as large and file like contents [FLIC], the manifests are used as data structures to transport this information. Thus, the manifests may contain hash digests of signed content objects or other manifests, so that large content objects which represent large piece of application data can be collected by using the manifest.
In order to request content objects, a consumer needs to know a manifest root name to acquire the manifest. In case of FLIC, a manifest name can be represented by a nameless root manifest, so that outside system may be involved to give this information to the consumer. Therefore, NRS can be considered as a kind of mapping database system.
This section presents the requirements for designing NRS in ICN in terms of service, system and security aspects.
Resolution response time, resolution accuracy, resolution guarantee, and resolution fairness are the requirements for NRS as a service, which are described below.
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 file 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 should 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 be very greatly depending on the proximity between the two end points, some upper bound should be used.
The response time should be within the same order of magnitude for most pairs of a client issuing a request, and the NRS server responding to this request.
The response time should include all the steps of the resolution, including potentially a hop-by-hop resolution or a hierarchical forwarding of the resolution request.
The 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.
The NRS must provide an up-to-date response, namely the 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.
The NRS must provide mechanisms to update the mapping of the content with its location. Namely, the NRS must provide a mechanism for a content owner 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.
The NRS must ensure that the name resolution would be successful if the name matching content exists in the network, regardless of its popularity and number of cached copies existing in the network.
The NRS should 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.)
Scalability, manageability, deployability, and fault tolerant are the requirements for NRS as a system, which are described below.
The NRS system must scale up to support a very large user population (including human users as well as machine-to-machine communications). 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.
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 impact on the other NRS servers (or should have impact on only a small subset of the NRS servers).
The NRS system should support access from a heterogeneity of connection methods and devices. In particular, the NRS system should support access from constrained devices and interactions with the NRS system should 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 may support an NRS management layer that allows for adding or subtracting NRS nodes. The management layer should be able to infer if the use of the NRS in some parts of the network is growing (or shrinking).
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 a NRS server fails, the NRS system must be able to recover and/or restore the name records stored in the NRS server.
Accessibility, authentication, confidentiality and privacy protection are the requirements on security aspect of both the NRS server nodes and mapping records stored in the NRS system. These requirements are described below.
The name records must have assigned with proper access rights such that the information contained in the name mapping record would not be revealed to unauthorized users. In other words, the NRS system must be prevented from malicious users attempting to hijack or corrupt the name mapping records.
The NRS may support access control for certain name records, so that only users with the proper credential can access these record, and these records would not be shared to unauthorized users.
The NRS may support authentication of the content producers to determine that any location update/addition/removal that a content producer is requesting is indeed valid and that the content producer is authorized to modify this record.
The NRS should verify new mapping location that are being registered so that it cannot be polluted with falsified information or invalid records.
The NRS must require authentication of new NRS nodes that register themselves in the NRS system to ensure they are who they claim to be. For example, it should detect an attacker attempting to act as a fake NRS server to disrupt the NRS service, or to intercept some users' data.
NRS must keep the data confidentiality to prevent a lot of sensitive data from reaching unauthorized data requestor such as in IoT environment.
NRS must keep meta-data confidential as well as 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).
When a private name mapping record is registered in the system, the NRS system must support the privacy to avoid the information leaking. Otherwise, unauthorized entity may disclose the privacy.
The NRS system should be resilient to denial of service attacks and/or other common attacks on the integrity of its system. The NRS system should be resilient if a few attacked nodes are unable to participate in the system.
The NRS node in a given subdomain should not leak information about this domain (say, topology, number of nodes, number of clients, number of requests) to nodes outside of this domain, except for sharing the content that it is allowed to advertise, or for the management protocols that it is supporting.
There are no IANA considerations related to this document.
[TBD]
[TBD]
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC7927] | Kutscher, D., 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. |