This section discusses the various items that can be considered from the perspective of ICN architecture when employing an NRS system. These items are related to the registration, resolution, and update of name mapping records, protocols and messages, and integration with the routing system.
When an NRS is integrated in ICN architecture, the functions related to the registration, resolution, and update of name mapping records have to be considered. The NRS nodes maintain the name mapping records and may exist as an overlay network over the ICN routers, that is, they communicate to each other through ICN routers. Figure 1
shows the NRS nodes and NRS clients connected through an underlying network. The NRS nodes should be deployed in such a manner that an NRS node is always available at a short distance from an NRS client so that communication latency for the name registration and resolution requested by the NRS client remains very low. The name registration, name resolution, and name record update procedures are briefly discussed below.
| NRS Node | | NRS Node |
+------------+ | | +------------+
| NRS Client |--------------------------------------| NRS Client |
+------------+ underlying network +------------+
Name registration is performed by the producer (as anNRS client) when it creates a new content. When a producer creates contentand assigns a name from its name prefix space to the content, the producerperforms the name registration in an NRS node. Name registration may beperformed by an ICN router when the ICN architecture supports off-path cachingor cooperative caching since involving an NRS may be a good idea for off-pathcaching. The ICN routers with forwarder caches do not require nameregistration for their cached content because they lie on the path toward anupstream content store or producer. They will be hit when a future request isforwarded to the content producer by an ICN router lying downstream toward theICN client node. However, ICN routers performing off-path caching of contentmust invoke the name registration procedure so that other ICN routers candepend on name resolutions to know about the off-path cache locations. If acontent gets cached in many off-path ICN routers, all of them may register thesame content names in the same NRS node, resulting in multiple registrationactions. In this case, the NRS node adds the new location of the content tothe name record together with the previous locations. In this way, each of thename records stored in the NRS node may contain multiple locations of thecontent. Assigning validity time or a lifetime of each mapping record may beconsidered especially for the off-path caching content and managing mobility.
Name resolution is performed by an NRS client to obtain the name recordfrom an NRS node by sending a name resolution request message and getting aresponse containing the record. In the name-based ICN routing context, thename resolution is needed by any ICN router whose forwarding information base(FIB) does not contain the requested name prefix. Name resolution may also beperformed by the consumer (especially in the case where the consumer ismultihomed) to forward the content request in a better direction so that itobtains the content from the nearest cache. If the consumer is single homed,it may not bother to perform name resolution, instead depending on eitherstraightforward name-based routing or name resolution by an upstream ICNrouter. In this case, the consumer creates the content request packetcontaining the content name and forwards to the nearest ICN router. The ICNrouter checks its FIB table to see where to forward the content request. Ifthe ICN router fails to identify whether the requested content is reachable,it performs name resolution to obtain the name mapping record and adds thisinformation to its FIB. The ICN router may also perform name resolution evenbefore the arrival of a content request to use the name mapping record toconfigure its FIB.
Name record update:
Name record update is carried out when a content name mapping recordchanges, e.g., the content is not available in one or more of the previouslocations. The name record update includes the substitution and deletion ofthe name mapping records. The name record update may take place explicitly bythe exchange of name record update messages or implicitly when a timeoutoccurs and a name record is deemed to be invalid. The implicit update ispossible when each record is accompanied by a lifetime value. The lifetimecan be renewed only by the authoritative producer or node. The cached mappingrecords get erased after the lifetime expires unless a lifetime extensionindication is obtained from the authoritative producer.
In order to develop an NRS system within a local ICN network domain or global ICN network domain, new protocols and semantics must be designed and implemented to manage and resolve names among different namespaces.
One way of implementing an NRS for CCNx is by extending the basic TLV format and semantics [RFC 8569
] [RFC 8609
]. For instance, name resolution and response messages can be implemented by defining new type fields in the Interest and Content Object messages [CCNxNRS
]. By leveraging the existing CCNx Interest and Content Object packets for name resolution and registration, the NRS system can be deployed with a few ICN protocol changes. However, because of confining the changes to the basic ICN protocol and semantics, the NRS system may not be able to exploit more flexible and scalable designs.
On the other hand, an NRS system can be designed independently with its own protocol and semantics like the NRS system described in [Hong
]. For instance, the NRS protocol and messages can be implemented by using a RESTful API, and the NRS can be operated as an application protocol independent of the rest of the ICN protocol.
An NRS reduces the routing complexity of ICN architecture compared to pure name-based routing. It does so by permitting the routing system to update the routing table on demand with the help of name records obtained from NRS. The routing system therefore needs to make name resolution requests and process the information returned, such as a prefix, a locator, an off-path-cache pointer, or an alias name, obtained from the name resolution.
No matter what kind of information is obtained from the name resolution, as long as it is in the form of a name, the content request message in the routing system may be reformatted with the obtained information. In this case, the content name requested originally by a consumer needs to be involved in the reformatted content request to check the integrity of the binding between the name and the requested content. In other words, the information obtained from the name resolution is used to forward the content request, and the original content name requested by a consumer is used to identify the content. Alternatively, the resolved information may be used to build the routing table.
The information obtained from name resolution may not be in the form of a name. For example, it may identify tunnel endpoints by IP address and instead be used to construct an IP protocol tunnel through which to forward the content request.