This section presents the functionalities of an NRS in ICN.
In ICN, a name is used to identify the data object and is bound to it [RFC 7927
]. ICN requires uniqueness and persistency of the name of the 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, human readable or non-readable.
Although there are diverse types of naming schemes proposed in the literature, they all need to provide basic functions for identifying a 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), known as 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 known as a "Global Unique Identifier (GUID)", derived from a human-readable name via a global naming service, is a flat typed 160-bit 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 Named Information (NI) names [RFC 6920
], 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 inherently supports mobility by consumers. 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 Routing Information Base (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 adopting 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 interest 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 the 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 called a "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.
], the forwarding label (FL) object is used 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 mapped to heterogeneous name schemes and LIDs are mapped 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 a 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 faces 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 RIB and FIB. Since the number of data objects would be very large, the size of information bases would be significantly larger as well [RFC 7927
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 into the Default Route Free Zone (DFZ) of ICN would create a 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 order to address the routing scalability problem in NDN's DFZ, a well-known concept called "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 looks up 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 to 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.
], an NRS is used to find off-path copies in the network, which may not be accessible via name-based routing mechanisms. Such a 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 a "Nameless Object", which is 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, which is to restrict Content Object matching by using a 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 the proper name and hashes through an outside system, which can be considered as an NRS.
For collections of data objects that 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 that represent a large piece of application data can be collected by using such a manifest.
In order to request Content Objects, a consumer needs to know a manifest root name to acquire the manifest. In the case of File-Like ICN Collections (FLIC), a manifest name can be represented by a nameless root manifest so that an 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 the 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 Networked Object (NEO) ICN architecture [NEO