Terminologies in the ICN architecture

Terminologies in the ICN architecture The research on the Information-centric Networking initiated with the need to replace the current inefficient architecture to a promising model that could satisfy future network necessities [1]. The several projects on this research are differentiated in the operations of the key building blocks common to most projects [4]. Named Data Objects (NDOs)   Ã‚   Every content on the internet ranging from a web page, documents to media files is referred to as objects (NDOs) which are independent of location, storing and retrieval methods [4]. NDO and its name is the identity of the information on the internet which can be copied, requested and supplied. NDOs can also hold representative data about the information held by the object [4]. Naming Every NDO in ICN is to be assigned a unique name, and should also associate an integrity check with the information it holds to ensure reliability [4]. They are always location-independent and range from structured to flat and may be human interpretable or not [1].There are two different naming schemes hierarchical and flat namespaces. The hierarchical scheme has a structure to the name rooting to publisher prefix which may also be human-readable in some cases, enabling aggregation and scalability in routing mechanisms [4]. The flat namespaces use the hash of the content with the objects name for direct binding and embed public key and hash of the content for indirect binding [4]. The publisher field in flat names facilitates some level of route aggregation even if it is a non-hierarchical scheme [4]. The difference in the design trade-off affects routing and security mechanism [4]. Security This feature is correlated to the naming scheme adopted by the approach. Human-readable names require external trust agent for verification, while flat names support self-certification and validation [1]. Hierarchical naming is considered disadvantageous as it relies on public key infrastructure (PKI) [4]. Application Programming Interface (API) The ICN API is related to the operation of asking and getting the NDOs. There are different terms denoted for the operation that varies which will be discussed during respective approach. The source provides NDOs by publishing it to the network. The user requests the network to get the NDOs by subscribing to it. As per approach, the publish/subscribe operation may be synchronous or asynchronous, while some support location preferences [4]. Name Resolution, Routing, and Forwarding of the Content The name of NDOs is resolved by matching the information name to the source provider [1]. Resolution may be direct or indirect routes to the source/s. The operation is carried out by Name Resolution Service (NRS) in the routing infrastructure which stores pointers to the storage locations containing the object names [4]. The routing and forwarding of the objects are carried out in multiple steps which involve routing the request to the direct source or to the responsible NRS, translation of object name to source/s addresses if indirect, forwarding the request to the source and fulfilling the requested data back to the client [4]. The content routing may be coupled or de-coupled to the name resolution process. Coupled routing backtraces the request message path from the client and follows the same for delivering content. De-coupled routing uses different routes which can be generated by an independent routing module that provides a deliverable route to the source [1]. Caching Caching is application-independent and may be done at every node in the ICN infrastructure [4]. ICN supports on-path caching and off-path caching. On-path caching is caching the information along the path of NDO request message while Off-path caching is exploiting the information cached outside that path [1]. Off-path caching can be supported in both coupled and de-coupled routing mechanisms by routing systems or NRS respectively [1]. Mobility ICN facilitates content request process from user end as the request can be re-initiated after the handoff while providing mobility to the source is difficult in both coupled and de-coupled approach as it burdens the system with additional updates [1]. By caching and replicating content at multiples nodes closer to the mobile subscriber, the ICN infrastructure saves costs and time by bypassing possible congestion [2].