Mobility support and operation of information centric networking approach

Published Online October 2018 in MECS DOI: 10.5815/ijcnis.2018.10.03

• I.    Introduction

  The engineering of today’s Internet architecture was developed in 1960s and 1970s, with the aim to solve resource sharing as networking problem [1,2]. That purpose was achieved beyond its imagination. Currently, there is an extensively increased in services and information dissemination over the Internet, as a result of highly demand from users. In 2017 Cisco’s yearly Visual Networking Index (VNI) estimated that, almost 429 million mobile devices connected to the network in 2016, added up on 7.6 billion devices at of 2015, making the total of 8.0 billion globally and predicted 11.6 billion mobile connections in 2021. Global mobile data traffic will upsurges nearly seven times in 2021, reaching 49.0 EB per month and raises up to 7.2 EB per month in 2016 [3].

Therefore, recent developments in mobile data traffic and vast devices connectivity have heightened the needs for efficient and scalable distribution of content, while the current architecture was designed to address the sharing of resources and long distance communication [4]. Hence, as a result of that demand, an effective and scalable network overlay Content Delivery Network (CDN) and Peer-to-Peer technology (P2P) was proposed [5–7].

Table 1. Type Sizes for Camera-Ready Papers

Name	ICN Approaches
	i С)	§	i	у	§		s' $		!
Flat	√						√	√	x	√
Heirarchical		√	√		√				x
Hybrid				√		√			x

Nevertheless, CDN servers required capability to handle large amount of content when dealing with flash crowds, which resulted to high cost of management [8]. Consequently, the ICN paradigm was proposed to replace current Internet architecture [5]. Moreover, the Information Centric Networking (ICN) architectures are prominently known with content name in place of IP address and they are categorized into flat, hierarchical and hybrid naming [9] as presented in Table 1.

The rest of the paper is organized as follows: Section II provides a review of the trend of ICN approaches, section III is the mode of operation for some approaches, section IV discussed the ICN mobility supports and section V challenges for future solution followed by conclusion.

• II.    Review on Information Centric Networking Approaches

The ICN conception called TRIAD was primarily proposed at Stanford University. TRIAD project offered to use Name Data Object (NDO) as an alternative of DNS lookups, also addresses are no longer useful for identification of endpoints, and instead, name suffixes were used [10]. Data-Oriented Network Architecture

(DONA) project [11] at UC Berkeley proposed in 2006 as Future Internet architecture that used name and name resolution. DONA improved upon TRIAD architecture by in cooperating content security. In 2008, the Publish Subscribe Internet Routing Paradigm (PSIRP) project was funded by European Commission under Framework Seven Program (FP7). PSIRP proposed to design the Future Internet architecture from the publish/subscribe paradigm, for efficient and operative solution of current Internet principal challenges [12]. The Publish Subscribe Internet Technology (PURSUIT) project commenced in 2010 and build on the result of PSIRP project , concerned with a system-level approach focused on internetworking layer, which is the major function of the current Internet [13]. In addition, a project Network of Information sponsored by the European FP7 under the 4WARD project, later undertook by Scalable and Adaptive Internet Solutions (SAIL) [14].

A Content-based publish/subscribe networking (CBN) was proposed to operate based on publish and subscribed like PSIRP and PURSUIT. There are two forms of communication that share the same forwarding table on single routing infrastructure, namely publish/subscribe and on-demand content delivery. The two were hybrid and form a unified content-based network layer and can be implemented with different forwarding scheme, also can greatly reduce overhead by avoiding loops as requests were not be cached at each hop [15]. Fig. 1 shows some ICN projects and their sponsored region.

Further, a clean-slate Internet architecture called Named Data Networking [16] was proposed and sponsored by National Science Foundation to enhance the earlier research project sponsored by Palo Alto Research Center in 2007 called Content Centric Networking (CCN) architecture. CCN was proposed to address modern day requirements of Internet resources sharing by providing content availability, content security and location dependence [2].

Information C entri с Networking Research Proj ect

;

US-Based ION Research Project

IRAID [25]

DONA [26] CCNP"] NDN pq

I

EU-BasedICN

Research Proj ect

PURSUIT [29] PSIRP [30]

Netlnf [31]

COMET [32]

CONVERGENCE [33]

GreenlCN [34]    ' '

UMOBILE [35]

SAIL [36]

Fig.1. ICN Research Projects.

• III.    Information Centric Networking Approaches mode of Operation

• A.    Data-Oriented Network Architecture Architecture

In Koponen et al., [11] proposed the pioneer ICN approach called DONA; focus more about replacement of host-centric network to data-centric network application. Many applications with regards to current Internet architecture referred as host-centric network are strictly designed on host-to-host communication. Moreover, DONA was designed to route data packets between pairs of stationary hosts [17].

• a)    Name and Name Resolution:

DONA used flat namespace for NDO and selfcertifying names, for the provision of persistence and authenticity, that are organized around principals associated with security keys pair and named contents, host domain are associated principal [11]. Content names are organized in the form of P:L, where P is the principal’s cryptographic publisher key and L is the principal’s chosen label to identify the unique content name [5,11,17]. The designed impacts of DONA’s was not restricted to Internet data and service access [11], rather support host mobility, multicasting, multi-homing, placed anycast at the naming layer in place of IP layer and provide network scalability

DONA uses paradigm called route-by-name for name resolution, rather than DNS servers, and required each domain to deploy servers as a replacement of DNS called Resolution Handlers (RH), that indexed content stored by authorized storage points [11]. Name resolution achieved through the use of two basic rules: FIND and REGISTER.

• b)    Named Based Routing:

DONA used named-based routing of FIND and content catching to support information centric architecture. RHs are structured in the form of tree topology that symbolizes the BGP topology of the network and each client knows the whereabouts of its local RH [11,17]. Any client authorized to provide a data or service with name P:L send a packet command REGISTER (P:L) to its local RH. After registration of the content or service, the consumer can send FIND request for the content to the connected RH. Upon recipient of the command, if such type of records exists it will reply back to the consumer, otherwise, forward it onward to next RH, as in Fig. 2.

Fig.2. DONA mode of Operations

Each RH reserves a registration table that maintained next hope information and distance to the copy. When a FIND (P:L) reaches RH and there was no records in the registration table, the FIND is forward to its parent RH up the tree until the source discovered. The data exchange occur directly from source to destination using IP routing and forwarding.

• B.    Network of Information Architecture

NetInf [14] was proposed to targets large-scale content distribution to replace or supplement current Internet architecture. NetInf targets to support different type of networks including traditional Internet with the help of convergence layers (CLs), hybrid Name-Based Routing (NBR) and Name Resolution (NR) scheme to provide global scale communication and infrastructure-less networks. It also used named data object (NDO) for accessing name content for NetInf node with tight security and data integrity.

• 1)    Naming and Caching:

NetInf uses flat namespace for NDO [14] and selfcertifying names as in [11], unlike DONA a Public Key Infrastructure (PKI) is not required. Flat names without topology or organizational hierarchy limits the ability to aggregate names based on hierarchy, method like explicit aggregation used to replace name aggregation using hierarchy. NetInf nodes can be able to understand NDO naming format, object model and implement NetInf protocols [14]. In addition, nodes can forward requests and responses, cached data, and name resolution.

NetInf supports three different types of caching, for easy access to the nearest available copy to provide load balancing and efficient content distribution [14]. First on-path caching provided by NetInf supported router with built-in caching functionality, on the process of forwarding GET responses, the router can cache the content objects. Second, an off path cache is provided directly by the source or producer especially during interdomain traffic to reduce network latency and objects were cache based on popularity issued by NRS. Lastly, peer caching supported by NetInf nodes it can function as on- path caches, off-path caches or both.

• 2)    Name Resolution and Name-based Routing

NetInf used two models name resolution and namebased routing for retrieving NDOs [5,14,17], also supports a hybrid of name-based routing and name resolution using a routing hints [14]. The source node has a choice to register with Name Resolution Service to publish NDOs or use routing protocol to announce routing hint. Further, the hybrid approach is used for global connectivity with Border Gateway Protocol (BGP)-like routing infrastructure combined binding with global name resolution service [14].

Table 2. Routing Types for ICN Approaches

Routing	ICN Approaches
	i ©	g	i	Co	и	и %	S'		и
NBR	√	√	√	√	√	√	√	√	√	√
RH	√
NRS				√		√	√		√
RN								√		√

Fig.3. NetInf Mode of Operations

Fig. 3, illustrates how the name resolution, name-based routing as well as hybrid works. In name-based routing approach, the client first forward a GET request of NDO between nodes until a cached copy of NDO is found or its reaches the original server or source, the data are sent back to the client. Alternatively, the client can perform a name resolution as alternative if the routers not have enough routing information. The client forwards the request to the NRS to resolve and retrieved routing hints for that NDO. The client uses the hint to retrieved data from best available source. Also the data are sent back to the client with object cached intermediary for subsequent used. These can either be merged as hybrid or used separately in the network.

• C.    Content-Centric Networking Architecture

CCN [1] was proposed to addresses the modern day requirements of Internet resources sharing that are facing some challenges on content availability, content security and location dependence [2]. CCN operates based on what content needed by the client, accessed by its named content and delivered a secured content to destination using named based routing. In contrast to current internet that is IP oriented, operates on host-to-host communication that uses IP address and secured communication channel.

• 1)    Name and Security:

CCN use hierarchical namespace in naming of contents for efficient routing of data packet and cryptographically secure data packet with digital signatures to achieved data integrity [2]. In the architecture, IP network stack was replaced by named content chunks to provide large amount of name prefix for the achievement of scalability, aggregation of routing and forwarding state.

• a) In the model there are two types of packets namely Interest and Data, each CCN node either a router, consumer or producer possess three data structurers: forwarding information base (FIB), Pending Interest Table (PIT) and Content Store (CS) to support efficient routing and forwarding of data [2].

• 2)  Routing and Forwarding:

CCN uses name base routing to forward data packets to destination when client put a request. Communication of data in CCN is consumer driven [2], the client consumer forward Interest packets in the network for the required content. The Interest is forwarded to the destination using FIB’s longest-prefix matching in any intermediate node. PIT received any incoming Interest stored its information and aggregates multiple Interest requesting the same content.

• D.    Named Data Networking Architecture

NDN [16] is also proposed as a clean-slate Internet architecture called that present an evolution of IP architecture, to discourse the weaknesses of current Internet, by transforming address centric nature of point-to-point communication to content-centric nature. NDN rooted from earlier project CCN [6,7] for enhancement and provision of standard Future Internet.

• 1)  Naming and Security:

Like other ICN approaches, NDN uses self-certifying named data, secured with digital signature in order to achieve data authenticity, confidentiality and integrity which among the main objectives of NDN design. The architecture named data or content in hierarchical namespace structure for NDOs, same as TRAID, DONA and CCN. Thus, the naming scheme allows different application to choose its scheme independent of the network refers to opaque of the network [16]. The hierarchical structure of naming represent the context and its relationship for each application,

• 2)    Routing and Forwarding:

To achieves routing and forwarding of packets NDN uses named base routing and possesses two different types of packets, namely Interest and Data packets. Also NDN node can be represented as client consumer, producer or a router were in possession of three data structure PIT, FIB and CS, determines when and where to forward Data and Interest packets, similar to CCN. PIT records and store any incoming Interest, FIB maintained the Forwarding Strategy and decide when and where to forward Interest and CS is a temporary cached of data stored based on NDN caching policy. The data packets looks PIT and forward while Interest lookup FIB to forward, see Fig. 4

Fig.4. NDN/CCN Mode of Operations

An illustration of Fig. 4 shows the routing and forwarding strategy of NDN. When network was setup and client nodes consumer 1 and 2 established connection in the network. The consumer 1 intended to retrieved data from the network, will send an Interest to NDN router labeled as Router A (RA). On arrival of the Interest the router, RA checks the CS for matching data, if found the

RA forward the data packets back to the consumer 1. Otherwise the RA looks up the name content in its PIT for matching entries, if entry was not found it will records the name of the content and incoming interface, then forward the Interest to the next hop through FIB, otherwise it will aggregates and records the interface only. The same process will takes place up towards data producer. Interest can be dropped on certain circumstances depends on forwarding strategy e.g congestion of upstream links or security breaches by suspecting Interest to be part of DoS [16]. Once the data producer received Interest request from Router D and its PIT found the required content, it will forward the data packets back through interface received the Interest to the downstream interface recorded in PIT. When a data packet reaches RD founds matching PIT entry, it will cache the data save in CS and forward the data downstream to the consumer 1. Additionally, each NDN node has the capability to cache data and save in Content Store for subsequent used based on NDN caching policy. Assume consumer 2 want the same data content requested by consumer 1, as its connected to Router B, consumer 2 forward its request to RB, on the arrival of the Interest RB check the CS and found cached content and forward it back to consumer 2 without routing upward to the original producer. However, unlike in IP network architecture where each consumer must have a dedicated connection from source to destination because it cannot support on-path caching. NDN also control looping by symmetrical nature of Data/Interest exchange targets hop-by-hop unlike end-to-end packets delivery in respect to IP address model.

• E.    Content Network Architecture

COntent NETwork architecture (CONET) was proposed to extend CONVERGENCE [18] by improving network scalability using route caching technique [19]. In

CONET nodes are classified in to four groups such as, routing system nodes (NRSs), border nodes (BN), serving nodes (SN), end nodes (EN), and internal nodes (IN). The nodes exchanges information units for data and interest labeled Interest CIUs and named-data CIUs, EN refers to the user or client that sends interest request to the network for named data through BN, border node locate at the border between different network and sub-system. SN can cache the named-data for subsequent used, advertise and provide it when necessary, as in Fig.5. Also, can splits named-data in to related sequence of bytes to represent series of named-data CIUs and transmitted by carrier packets, BN forward those carrier packets using routing mechanism supported by CONET. Internal nodes are optional in the architecture deployed in CONET sub system to support in-network caching independent of BN. Name Routing Systems node used to promote route-by name process [20].

Fig.5. CONET Mode of Operations

Consider Fig. 5, as example, EN sends an Interest CIU requesting named data, BN checks for the availability of the content if found in its cache, it would sends back to the client otherwise CONET forward the interest onward. If CONET Sub Systems (CSS) is IP network, the interest should be forwarded-by-name with IP address overlay. IN along the path between the BN intercepts the Interest and checks it cache for relevant content, if not found forward the request to the destination as directed in the IP address with the help of in-path IP router between two BN. In short, three different topologies were being supported by CONET, clean slate over layer two (L2), CONET over IP layer and hybrid of CONET integrated in the IP layer [18].

• IV.    Mobility Support in Information Centric Networking

The mobility concern in ICN was generally divided into three categories, the consumer mobility, producer mobility and network mobility. Consumer mobility is the ability for the client on request of data or services to relocate to another access point without disrupting the content availability and minimal hand-off delay. Producer mobility is the support for the content provider to relocate without disrupting consumer and intermediate router for content name and its location. Meanwhile, the different architectural designs of ICN approaches were developed with different mechanism to support and achieved the benefit of ICN in terms of mobility. Some researchers indicates the natural mobility support, as in [4] stated that, ICN supports and provides many benefits upon deployment for multicast mechanisms and in-network caching, to facilitate network efficiency and timely delivery of information to the users on mobile. Also, caching was proposed to remedy losses as a result of handoff in the situation of mobile IP, therefore, caching enhances and support client mobility seamlessly [21]. Further, caching is an integral part of ICN architecture to facilitate storage of caching NDOs. Thus, all ICN nodes such as mobile terminal and user-run home network were potentially have caches [5]. However, in terms of consumer mobility almost all approaches were supporting it by default. For example, DONA uses RH to support both consumer and producer mobility and NetInf uses named resolution mechanism to support network, consumer and producer mobility.

DONA manages both consumer and producer mobility by changing edge RH attached to the host. For consumer mobility, any existing requests can simply be resend to the new RH to discover the new optimal source [11]. A client as producer is allowed to re-REGISTER its contents upon reestablishment of new session after relocation to new network’s RH. Therefore, DONA supported producer mobility without much challenges. However, unlike NDN, CCN, NetInf and other approaches, DONA architecture relied on current Internet transport protocol TCP, for out-of-band content delivery from source to destination. In addition, the registration of source client must be renewed in certain period as it has a given life-time. Hence support for mobile producer was not guaranteed and the claimed of DONA as clean-slate was not justified.

Mobility and multi-homing supported in a global NetInf network was based on automatic dynamic updates in the NRS. NetInf support network, consumer/client mobility and producer mobility [5]. In terms of network mobility, LLC [22] supported and provides very good support in routing and forwarding processes. Also, GIN support client mobility without inflated look-up for routing table [23] and other network-based services such as private data networks, dissemination services, directory services, etc. Such services are implemented by network protocols or network applications, run over the GIN nodes. Content provider or producer mobility supported through NRS. When a copy of data moves between nodes, the movement result NRS update and accounts for the new location [5]..

In PURSUIT and PSIRP, when consumer re-locates it simply uses publish/subscribe nature of the architecture to re-subscribes the content being used to the network [13], [17]. Therefore consumer mobility was inherently achieved, however, producer mobility required to update the routing information. Hence, producer mobility support was not guaranteed in PSIRP. In addition, producer mobility was likely complex as it does require updating of routing information while consumer mobility was relatively straight forward [24]. Also, as in NDN, CCN and PSIRP, consumer mobility, a client can unsubscribed change the location and re-subscribed again, then routing path will be computed and seamless handing over should take place while updating the routing sate of provider mobility is complex [5].

The literature shows that almost all the approaches supported mobile producer except CCN and NDN as shown in Table 2.1. In addition, the table summarizes several features of each approach that can be used to support mobility such as, Resolution Handlers (RH), Named Based Routing (NBR), Named Resolution Services (NRS), Rendezvous Services (RS), in-network and on-network caching. Moreover, naming play an important role for mobility support, hence, the nature hierarchical name of NDN caused contributes to the mobility support problems. Therefore, among the approaches that need further research on producer mobility, NDN is the most recent approach; that evolved from CCN. Moreover, NDN provide network scalability due to nature of using hierarchical name prefix and one of the infrastructures less network architecture. Meanwhile, this research would focus on producer mobility support for NDN.

Table 3. Mobility Support for ICN Approaches

Mobility	ICN Approaches
	i С)		i	ЬО	§		s'		!
CONSUMER	√	√	√	√	√	√	√	√	√	√
PRODUCER	√			√		√	√		√

• V.    Mobility Challenges from Current to Future Internet

Mobility support allows mobile devices to relocate between different access point without disrupting the content availability and minimal hand-off delay. Despite the rapid development in networking and vast emergence of mobile devices, many organizations such as Cisco, IETF and NDN [25], CCN [26] research teams studied how to manage the mobility of such devices that are attached or connected to the network. A well-known organization Internet Engineering Task Force (IETF), organized by Internet Society to make and facilitate the Internet functions better, provided many standard protocols that were developed to support nodes on mobile such as Connexion, WINMO [27], NEMO [28], [29], Mobile IPv4 (MIP) [30], Mobile IPv6, Proxy Mobile IP (PMIP) [31] and their many extensions [32].

IPv4 mobility support with request for comment number (RFC) 2002 was developed and revised with RFC 5944 [30] designed to support IP and provides smooth communications between moving host in the Internet. A mobile node (MN) can be identified with its home address at any location moved and the protocol provides a care-off address registered with home agent (HA) which can be a home router and foreign agent (FA) which can be a new location router. The HA sends datagram through tunnel using care-of address, once datagrams arrived the FA delivered it to the MN [30].

IPv6 mobility support with RFC 6275 and proxy mobile IPv6 RFC 5213 extended by RFC 7864 to support flow mobility [31]. The extended proxy MIPv6 support flow mobility over different and multiple interfaces as already PMIPv6 used to allow MN connection through different interface to the same PMIPv6 domain. However, the proposed solutions were based on IP networks uses IP addresses, yielding some problems as result of tunneling when delivering a data to the MN, such problems are Triangular routing that causes low efficiency and delay, handoff problems that causes high level of packets droplet and provision of QoS, intra-domain movement result to frequent hand-off that defends on address. Moreover, ICN was anticipated as future Internet to address the services problem that traditional Internet cannot cope with.

Information Centric Networking paradigm was offered to support more benefit such as network performance and scalability, any-casting and multicasting security and data integrity, mobility and multi-homing, in-network caching and reduction of network resources. Naturally ICN approach provides mobility support and security integration to manage, preserves privacy for both consumers and producers’ locations [33]. Recently, many researches have been conducted to provides support to content producer on mobile [34–36]. However, there are various challenges for the use of ICN wireless resources in wireless networking and mobility impact on seamless handoff performance [37,38]. Hence, further research in the area of ICN is needed to perfectly prepared ICN to replace current Internet architecture.

• VI.    Conclusion

In conclusion, ICN provides data availability by supporting location independence, security and caching. Network caching enhances data packets delivery and network performance in dynamic enviroments, also smooth handoff can be achieved for a mobile consumer. However, more challenges arises to make it better in mobility, naming, security, catching etc. For the content mobility support, consumer mobility was inherently supported in almost all ICN approaches with less challenges based on different application scenario. While producer mobility is facing many challenges that make it not supported in some approaches like NDN and CCN. The challenges arises from initial architectural design for a moving object making a new route that needs to be announce and propagated to replace old routing information, which causes similar problem as in IP. Also, naming structure generates substantial challenges when providers move to different location. Therefore further research needs to be conducted in namespaces, catching and mobility support. Our future research will focus on producer mobility support for content centric networking.