A Controller-Based Architecture for Information Centric Network Construction and Topology management

Zeinab Zali＊, Massoud Reza Hashemi Ilaria Cianci, Alfredo Grieco, Gennaro Boggia

1 Department of Electrical and Computer Engineering, Isfahan University of Technology, Isfahan 84156-83111, Iran

2 DEI, Dep. of Electrical and Information Engineering, Politecnico di Bari, v. Orabona 4, 70125 Bari, Italy

Abstract: Information-Centric Networking(ICN) has recently emerged as a result of the increased demand to access contents regardless of their location in the network services.This new approach facilitates content distribution as a service of the network with lower delay and higher security in comparison with the current IP network. Applying ICN in current IP infrastructure leads to major complexities.One approach to deploy ICN with less complexity is to integrate ICN with Software Defined Networking (SDN). The SDN controller manages the content distribution, caching, and routing based on the users’ requests. In this paper, we extend these context by addressing the ICN topology management problem over the SDN network to achieve an improved user experience as well as network performance. In particular, a centralized controller is designed to construct and manage the ICN overlay. Experimental results indicate that this adopted topology management strategy achieves high performance, in terms of low failure in interest satisfaction and reduced download time compared to a plain ICN.

Keywords: ICN; SDN; controller; topology management; overlay networks.

I. INTRODUCTION

As commonly known, Internet is inherently based on the connectionless service, offered by the IP protocol, with the objective to realize end-to-end communications among the hosts.This generally is referred to as host-centric emerged during a period when each user was interested in only a few services (e.g., web browsing, email, file transfer, remote access)located at the well-known network servers.Over the last twenty years the habits of users have changed dramatically, and nowadays services are content oriented rather than server oriented. Users surf the Internet to retrieve any kind of content, regardless of the providers’position. To manage the mismatch between the requirements of present content dissemination services and the host centric IP design, many different (and non-interoperable) platforms are applied currently at the application layer like Content Distribution Network (CDN) and Peer-to-Peer (P2P) systems.

This work was realized during the first author visiting research period at Politecnico di Bari

In the last decade, to rethink Internet principles with a comprehensive approach, the ICN paradigm is being practiced. In ICN,contents are ranked as first class citizens of the network and all protocols are driven by the content names rather than IP addresses. The initial outcome in applying this radical choice include: (i) native multicast communications,(ii) seamless mobile service provisioning, (iii)inherent support for multipath routing, and(iv) content oriented security schemes, which are all difficcult to provide through common IP functions [1].

In this paper, the SDN based implemetation of ICN is proposed to deploy ICN over existing IP network and to manage ICN topology dynamically using the controller in order to achieve an improved user experience and network performance.

The different ICN architectures introduced so far vary in the namespace structure (i.e.,hierarchical, flat, or hybrid), the approach to routing (i.e., name lookup or name based forwarding), the structure of name resolution system (if any), and the degree of interoperability with current Internet [2].

The spectrum of available solutions is very broad and differentiated. Data Oriented Network Architecture (DONA), one of the pioneer ICN architectures [3], applies a flat name space and still relies on IP routing to deliver contents. The Publish Subscribe Internet Technology (PURSUIT) architecture [4] (like its ancestor Publish Subscribe Internet Routing Paradigm (PSIRP) [5]) keeps the flat names as well, while replacing entire IP stack with a publish/subscribe one. The Network of Information (NetInf) architecture supports both hierarchical and flat names. It is based on a new Name Resolution System (NRS), arranged as a multi-level Distributed Hash tables (DHT)[6]. Named Data Networking (NDN) or Content-Centric Networking (CCN) is based on hierarchical names, without any resolution systems [7]. CONVERGENCE [8] leverages NDN functionalities while introduces a new architecture, named CONET [9] that can ease the integration of ICN primitives in an IP network by adding specialized nodes that handle name resolution and routing.

Despite the popularity of ICN, there exist some open issues related to its implementation. ICN can offer its benefits when it is deployed in the current IP infrastructure. This transition has to be smooth, and it needs to enable technologies to allow ICN primitives to be installed, con figured and controlled [10]. To face these issues adoption of SDN principles are promising [10, 11, 12].

In SDN, all the functionalities of the control plane (i.e., controlling devices and instructing them with the most appropriate forwarding strategies to apply) are logically centralized,while the data plane is responsible for handling network messages only based on instructions received from the control plane. To decouple the two planes, the SDN architecture contains a controller entity which manipulates one or more controlled entities through a standardized interface [13].

In addition to the technical benefits of SDN, like reducing complexity, its adoption can facilitate the introduction of ICN functionalities, without redeploying new ICN capable hardware. ICN deployments are more likely to be edge-driven, sponsored by industries, rather than relying on an adoption of ICN through key core Internet players [14]. This edge-driven deployment corresponds to the SDN solutions.

In this context, as to the authors’ opinion,SDN is observed as a key enabling technology for ICN. The integration between ICN and SDN have gained momentum in the recent years. Some papers address the possible integration strategies of ICN and SDN, like [11,12], while others assess the benefits contributed by SDN on optimized caching [15] and resource adaptation [16].

Because of the ICN implementation challenges, an incremental deployment of ICN is recommended instead of a clean-slate design.Implementing ICN as an overlay on legacy network is an incremental solution. On the other hand, different topologies have different costs for the users and for the network operator. Moreover, dynamic change of communication requirements and trafficc demand affect the overlay cost and performance. So dynamic topology management is one of the important issues in overlay networks [24].

Considering the mentioned challenges, in this paper, we propose to implement an ICN by deploying an overlay on legacy network.This overlay consists of some customer networks who want to create an ICN on the lega-cy network. Moreover, we introduce a new approach to tackle topology management issues in ICN. Also, according to the justi fication of using SDN to deploy ICN, we use SDN to create and manage the ICN overlay. For this purpose, we utilize the flexibility of the controller to monitor and manage the network. The major concern in this paper is load balancing and user experience quality enhancement.

The abstraction of controller and data planes in SDN facilitates monitoring and management of network including routing, con figuring the forwarding tables in the switches and enhancement functions. The mentioned capabilities come with SDN, but the actual control and management modules in the controller need to be developed for different networks and protocols. To the best of our knowledge,our work is the first one that proposes to use SDN to construct and manage the topology of an ICN overlay on legacy network using the controller’s management capabilities.

To achieve the mentioned goals, a centralized controller is designed to construct and manage the ICN overlay. It constructs the ICN topology incrementally when new customer networks join the overlay. Moreover, we define a parameter for ICN namedfailure. We call this parameterfailure, since it presents the failure rate in retrieving the requested contents based on ICN protocols. The controller dynamically monitorsfailurevalue on the overlay links. When a high failure value is detected, the controller modi fies the topology of the ICN overlay in order to reduce the load on the congested links. Moreover, topology management functions try to avoid overloads of the ICN nodes.

The main contribution of this article are: (1)constructing an ICN overlay from some customer networks on legacy network using SDN concepts; (2) dynamic topology management of the ICN overlay using a controller module based on a new de fined ICN parameter calledfailure.

To experimentally demonstrate the effectiveness of this proposed controller-based architecture, an ICN overlay has been deployed through the CCN-Joker tool (an NDN emulator) [17], and has been extended with control plane features. An extensive experimental evaluation of this proposed method is carried out on the PlanetLab network [18].Experimental results indicate that this adopted topology management strategy guarantees high performance, in terms of lowfailurethat results in reducing latency and download time in comparison with a plain NDN without such topology management capabilities.

The rest of the paper is organized as follow:The literature review is presented in Section 2. The original contribution of this article is described in Section 3, the proposed controller is evaluated in Section 4, and the conclusion is expressed in Section 5.

II. RELATED WORK

2.1 SDN and ICN

SDN is supported by four pillars: (i) separation of the control plane from the data plane,(ii) adoption of a logically centralized controller, (iii) set up of open interfaces between the two planes, and (iv) programmability of the network by external applications [19].

The most popular implementation of SDN paradigm applies OpenFlow [20] protocol as the interface between controller and data plane. Adoption of SDN principles in ICN design is considered a promising approach to enable a friendly integration of ICN and IP and optimize name based operations across different domains. Different contributions are formulated so far, addressing architectural facets, interoperability issues, and routing optimization.

An OpenFlow-based implementation for the CONET architecture is reported in [10].For this reason routing, caching and security operations are decoupled from the forwarding plane and are implemented in a controller.In this method, a name resolution system is responsible for routing operations which is also implemented in the controller. Content name can be carried in IP Options or transport level headers in order to enable content name matching in OpenFlow routers. In this effort,an extended version of OpenFlow is proposed to support new matching fields for ICN message forwarding.

PURSUIT architecture is implemented with OpenFlow in [11], where routing is implemented with bloom filter method. For every requested content, the topology management part finds the best path represented by a bloom filter ID. This ID is applied by OpenFlow tables for identifying a flow matching operation.The authors claim that using bloom filter ID in OpenFlow tables, instead of content name,solves the scalability issue, due to the fact that the number of different bloom filter IDs is smaller than the number of different content names.

Authors in [10, 11] combine ICN with SDN and implement it using IP layer or as a new clean slate network, while authors in [21, 12]propose to deploy ICN over existing network through SDN. They use non-modi fied IP and perform routing and caching decisions using SDN controllers. In these two works, a controller is responsible for finding the complete path to a source server or a cache node that contains the requested content. After finding an appropriate path, the controller updates the flow tables of all the switches on the path in a sense that they can forward the clients’ request to their locations.

Some essential principles for ICN is re flected in [22] which are used to design a framework called SDICN and implemented based on OpenFlow and datacenter technology. In SDICN, the controller handles user’s requests,locates contents, and provides them from optimum data centers. Also, a packet forwarding strategy in SDN-based CCN environment is proposed in [23] using distributed SDN controllers. Using the proposed strategy the amount of trafficc caused by Interest packets in CCN is decreased.

The authors in [24] give a solution to apply SDN to the NDN context to manage and control the network. They implement adaptive forwarding via intra-domain multipath routing using SDN in NDN.

SDN is used to implement an optimized caching scheme in ICN in [15]. Since an OpenFlow controller has a global view of ICN nodes, it can detect the most popular contents for solving an optimization problem in order to find the best locations for caching every content. The controller inserts new routing tables in ICN nodes. A framework to enable ICN-based service platform as virtualized network functions using SDN is proposed by[25]. Through virtualization it is possible to host several ICN services. This method enables the network to have several edge-cloud services like enterprise applications, big data analysis, or Internet of Things (IoT) services.

Implementing forwarding and caching in ICN using SDN has been well studied in the mentioned related research works. To extend these efforts, we introduce a new approach to deal with topology management issues in ICN using SDN infrastructure.

Also, a resource adaptation scheme for ICN is proposed in [16] where a controller collects the network status including bandwidth utilization and response delay from ICN nodes.Then based on the collected information, the controller updates the forwarding tables in the nodes. ?This research work is related to our work in the point that the leading result of both is better load balancing using feedback from some network status parameters?. However our solution is based on creating ICN as an overlay over the network while this work assumes ICN built into the network. So we manage the overlay network topology using the management by the controller but [6] controls the routing in the network by managing the forwarding tables. ?

2.2 Overlay topology management

Topology is a basis for achieving all the functions of an overlay such as routing, searching and information dissemination. So topology has a major impact on overlays efficciency and cost. There are some research works related to topology management in overlay networks.We address some of the most noticeable works in this section.

A framework for topology-aware overlay networks that enhances the availability and performance of end-to-end communications is proposed in [26]. In this method, the overlay network that maximize path independence without degrading performance is constructed.The authors deploy overlay nodes using offline topology analysis rather than randomly deploying overlay nodes, and this off-line node placement is updated over a long period.

The authors in [27], formulate the problem of creating the overlay topology based on Integer Linear Programming. In their formulation,the cost is proportional to the length of the shortest path and the amount of trafficc demand between any pair of nodes. They use heuristic methods to find near-optimal overlay topologies.

T-Man method is proposed as the topology management method, where a ranking function is applied for each node to order any set of other nodes; consequently, the nodes with higher ranks are chosen as neighbors [28].

The problem of dynamically recon figuring the topology of an overlay network in response to the changes in the communication requirements is studied in [29]. They consider two costs: occupancy and recon figuration for an overlay. Then they formulate an optimization problem to define the most appropriate topology. This problem is NP-hard and the authors propose some heuristic methods to solve it.

Particularly, a Simulated-Annealing (SA)based algorithm for finding the optimal topology for a given communication pattern is proposed in [29]. We also use SA for finding a topology with good performance. But we specialize it for the dynamic topology management problem with communication requirements in ICN. For this purpose, we adopt different initial points, cost function, and rules for changing the topology.

III. PROPOSED ARCHITECTURE

We assume some customer networks want to join each other through an ICN which is based on NDN. Each customer network has a gateway located on ICN. There exist some publishers and content consumers on every customer network. Gateways are analogous to routers in NDN, hence they cache every received content. According to NDN, communications are driven by content consumers, and are based on two types of messages: Interest and Data.A user asks for a content by issuing an Interest packet, routed within the network towards the nodes with the required information, triggering them to reply with the corresponding Data packet. Packet forwarding in each gateway takes place based on the three main structures of Content Store (CS), Forwarding Information Base (FIB), and Pending Interest table(PIT). CS is a cache memory implementing an arbitrary cache replacement policy and Data is cached on-path during traversing the reversed path of Interest’s route.

This newly proposed architecture consists of two planes: the data plane which is an NDN overlay and the control plane which is composed by a logically centralized controller. The objective of the control strategy is to enhance the user experience through topology management. Herein, an NDN overlay is considered in order to ease the implementation of this proposed architecture. The same design principles can be applied at the network layer in straight manner. Furthermore, the same architecture can be extended to be applied in other ICN architectures.

A high-level view of the proposed architecture is shown in figure 1, where in the data plane, the NDN overlay connects some gateways, each one linked to one customer network. There exists some content consumers and publishers in each customer network.Each publisher announces its prefixes to the connected gateway.

The control plane is managed by a logically centralized controller, connected to the gateways through logical links. The controller dynamically updates the topology (i.e., sets FIB entries in the gateways) for optimizing the QoS provided to the end users. Routes are computed according to the shortest path strategy, where the controller computes the shortest path for each pair of gateway-pre fix, installing the FIB entries accordingly similar to other NDN routing methods like OSPFN [30] and NLSR [31]. In these two methods, the publishers announce their name pre fixes through some routing messages. Next, a name-based multipath routing table is generated in each router by calculating the next hop(s) to the original router of each name prefix. OSPFN and NLSR have applied distributed routing approaches, while here a centralized approach is applied to leverage the controller in order to calculate the routes and set the next hops in the FIB tables. In the process, when an Interest packet is forwarded along the path between a gateway and the publisher, if it encounters a node that has the requested data, a Data packet is sent back, so the Interest packet does not travel the whole shortest path to the publisher.

The adopted name scheme is also hierarchical similar to NDN with the following structure of

NDNO://publisher-name/content-type/content-ID/Chunk#,For example NDNO://telematics.org/video/2500/125.

Before discussing the details of the proposed topology management strategy, here we de fine the adopted terminology.

Fig. 1. The high-level view of the proposed architecture.

1.TG: It is the Topology Graph which is a graph data structure constructed and managed by the controller that resembles the topology of the NDN overlay. It is a weighted graphTG=, whereVincludes all the gateways in the ICN overlay andEincludes all the established overlay links between the gateways.Moreover, each edge (i,j)∈Eis associated with two values offailureijanddijde fined as:

·failureij: Failure of the link from nodeito nodejinTGis defined as, where,rDandslare the number of incoming Data packets received byifromjand the number of outgoing Interest packets sent byitojrespectively.

·dij: The network delay between nodeiandj.

2.p - gatewayg: The publisher gateway is a gateway within which at least one publisher registers some contents.

3.lhigh: The link with the highestfailurevalue among all the links withfailurelarger than a given threshold.

3.1 Controller description

The main task of this controller is to manage the ICN topology by updating the FIB entries in the gateways. This task is executed with the final objective of balancing the loads of links and gateways and decreasing the average length of route paths, thus improving the users’ quality of experience.

Topology management is based on measuringfailurevalue. According to the value of this parameter, the routes are updated whenever one or more links are congested or the transfer time of a route is higher than the timeout value for retrieving a data (i.e., the failure is very high). The topology management function tries to avoid overload of the gateways.

Thefailureparameter corresponds to the ratio of failure in receiving the Data packets for the forwarded Interest packets on a link.The failure in receiving the Data happens as a result of various factors such as high delay to the closest cache or overloaded links and nodes. So,failureis a suitable parameter for evaluating the performance of ICN as an aggregation of various network parameters.

Once the gateway is connected to the controller, the gateway periodically measures thefailurefor each outgoing link and sends this information to the controller. Using the received information, the controller knows the load of each data link according to which it can decide to change the topology in order to decrease thefailure.

The controller tasks, as presented in figure 2, are driven by the following events:

1. One connection request is received from a new gateway: in order to join the overlay,the new gateway sends a connection request to the controller, assuming that the gateways know the IP address of the controller. Upon the reception of a request, the controller connects the new gateway to the overlay. To connect this gateway to the overlay, the controller selects a nearby gateway among previously connected gateways, it constructs a logical link between the new gateway and the selected nearby gateway, and sends some commands to them to insert a new entry in their FIBs. It should be noted that, in this process, the new gateway is added to the Topology Graph.

2. One new prefix registration is received from the gatewayg: each publisher is directly connected to a gateway, so it registers its content through that gateway. This gateway sends a message to the controller and informs it about the new pre fix. The controller is responsible to de fine the next hop for the new pre fix in the gateways. Therefore, it calculates the shortest path from each gateway togwhich calculated only once.

Fig. 2. Controller functions.

Accordingly, it installs a new entry for that pre fix in the FIB table of every gateway.After the first pre fix registration in a gateway,the controller does not calculate the shortest path again for the next prefixes of the same gateway, it is sufficcient to install a new entry for those pre fixes according to the previously calculated shortest path to the correspondent gateway. FIBs will be updated any time there is a change in the topology as a result of the topology management operation.

3. Onefailurefeedback is received from a gateway: the controller updates the value offailurefor the correspondent link inTopology Graph. When a gateway fails or leaves the overlay, the controller checks the reachability of all remaining couple of(gateway, p-gateway). As soon as a gateway loses its network connectivity, first, the controller tries to inject the minimum number of new links required to ensure the reachability of eachp-gatewayfrom all the other gateways in the overlay,next, it recalculates the shortest path for all thep-gatewaysfrom all other gateways, and then it sends the updated FIB only to the gateways that have new next-hop for some pre fixes.

4. Onefailurevalue higher than a threshold is recognized: first the controller periodically analyzes thefailureof existing links, and if there exists at least one link with afailurehigher than a given threshold, the controller changesTGaccording to the topology management algorithm. This is followed by sending the updated FIB entries for only the gateways that have updated next-hops for some pre fixes. Thefailurevalues received after this process are not valid because of the change in topology, therefore, the controller waits for another period in order to execute this phase again.

3.2 Topology management

It is important for us to present the effectiveness of our general proposal of ICN overlay topology management idea with a sample algorithm. For topology management, an algorithm is proposed based on the Simulated Annealing (SA) algorithm in [29]. However,the proposed algorithm herein adopts different initial points, cost function, and rules for changing the topology to match the communication requirements in ICN. This dynamic topology management contributes in reducing the costs and increasing the performance of the ICN operation.

Whenever afailurehigher than the de fined threshold level is observed, this algorithm is executed to update theTGwhich is the initial topology for the SA algorithm. In SA, an initial “temperature” must be chosen. This algorithm works over multiple iterations where at every iterationTGis updated according to a randomly selected rule. A new topology with a lower cost is always confirmed while a topology with higher cost is accepted only with a prede fined probability. The cost is calculated for eachTGaccording to a predefined cost function. After every iteration the temperature is reduced by a discount coefficient and the algorithm finally stops on a topology when“temperature” is almost zero. In details, the cost function forTG=(V,E) is defined as follows:

where,SP(i,j) is the shortest path betweeni∈Vandj∈V, and the cost ofSP(i,j) is de fined asis a coefficcient in (1/s) to make both parts of the cost function have the same unit. Moreover, for everyiandj,e(i,j)∈Erepresents an edge inTGwhich connects gatewayito gatewayj.Therefore, the cost function for aTGis based onfailurevalues and the cost of the shortest paths between the gateways.

SA examines feasible neighbor solutions one by one until it stops at a final solution where it approaches almost near zero temperature. This final solution approximates the minimum cost topology for the current communication pattern of the ICN. A neighbor solution for aTGis generated by a rule which is randomly selected from among four possible rules. These rules are defined in a sense that the new topology contributes to the distribution of trafficc onlhighamong other links, including new ones, or shorten the path between some pairs of gateways. In the following definitions,sanddare the assumed source and destination gateway nodes of linklhigh, respectively.

· Rule 1: This rule randomly chooses a nodekand adds an overlay link fromsto it.

· Rule 2: This rule randomly chooses a nodekfrom the nodes which are currently sending trafficc tos, and adds an overlay link fromktod.

· Rule 3: This rule randomly chooses a nodeifrom the nodes which are currently sending trafficc tod. It also randomly chooses a nodek,and adds an overlay link fromitok.

· Rule 4: This rule is a derivative of rule 3, which randomly chooses a nodeifrom the nodes which are currently sending trafficc tos.It also randomly chooses a nodek, and adds an overlay link fromitok.

3.3 Scalability discussion

Scalability may be a major concern in SDN-based solutions. Similar to the available solutions, the proposed architecture and algorithm may face scalability problem. Many researchers have tried and try to overcome the scalability challenge in SDN [32, 33]. Authors in [34]have discussed this issue in the context of ICN integrated with SDN. They propose a scalable area-based hierarchical architecture to address the control plane scalability problem. In their proposal, the global network is divided into some local areas. There is an area controller for every local area that only knows the local area view. At the same time a centralized root controller at the top layer has the global abstract view of the local areas. These proposed solutions can be applied in the context of ICN to solve the scalability problem of the SDN based solutions. Based on this newly proposed controller in this paper is an area controller and a root controller coordinates all area controllers.

IV. IMPLEMENTATION AND EVALUATION

In this section, prototype implementation of the proposed topology management algorithm for ICN overlays is described. The CCN-Java Open source Kit EmulatoR (CCN-Joker) [4]is applied here to emulate the NDN overlay.Joker constructs an NDN based overlay at the application layer, the controller of which has been completely written by the authors.

The testbed consists of 1 controller, 10 gateways, 10 customer networks, and 3 publishers deployed on 24 PlanetLab nodes (see figure 4). The initial topology includes all the gateways connected in a two-way ring.

Fig. 3. Rules set for generating a neighbor topology solution in Simulated Annealing method.

Table I. list of pre fixes and content IDs.

Fig. 4. The testbed used in evaluation on PlanetLab nodes. The links between nodes are the initial links before adding extra links by controller.

Fig. 5. Number of links in the ICN overlay topology during time.

Number of ICN gateways in this real testbed is chosen to be minimal but good enough to evaluate the controller’s performance and topology management outcomes. The initial topology is selected with minimum resources required for the connectivity of all the gateways in the overlay.

There exist 2000 different contents with three pre fixes, and every pre fix is published by one of the publishers. All the contents are of 1M Bytes size. The prefixes and content IDs are tabulated in table 1.

According to [14, 35] content request popularity follows a Zipf distribution (i.e. theith popular content has a request probability proportional toi-afor somea＞0). Here, the requests are generated for the set of contents according to Zipf function wherea=0.3, and the requests are sent in time according to a Poisson process of rateΛ(request rate issued by each consumer is 0.1Λ). In each one of the experiments the execution continues until each content is requested at least once.

The low value of α results in a lower request redundancy, in a sense that the average number of hops that a request traverses to reach the correspondent cache is higher [14].This value is chosen to better demonstrate the effectiveness of this proposed method. LetBWbe the bandwidth on each link of the overlay,Λbe the request rate on the overlay,ρbe the average load on each link between two gateways in the initial topology. The following configurations are considered in the experiments:

The failure threshold is set to 0.2 and the delay on each link is set to 5ms. Theδcoefficient in the cost function is chosen to be 1.Here, we choose the parameters for the network in order to provide a congested network with 3 different load levels from normal to high.

4. Experimental results

To evaluate this proposed algorithm, the behavior of the overlay is analyzed with and without the topology control functions. The number of links does not vary over time when the controller is not applied. The variation of the number of links in the overlay topology when the controllers are used in three different scenarios are illustrated in figure 5. In all the cases, the controller adds links to the overlay in order to keep the targetfailurebelow the selected threshold (i.e., 0.2).

Note that, after achieving an appropriate topology, some of the overlay links are not involved in any of the shortest paths and can be removed from the overlay. Despite the fact that the mentioned rules in figure 3 only add some edges and do not remove any edge, the final topology does not contain all the added links. If the communication pattern changes and another topology management execution is required this algorithm begins with an initial topology including all the links involved in packet routing.

The Cumulative Distribution Function(CDF) of thefailureobserved over the overlay links is shown in figure 6, which is considered as the algorithm result. In this figure, it is observed that without the topology control algorithm, the overlay would suffer unacceptable highfailurevalues that would prevent the deployment of new services. On the contrary,with the topology control algorithm, thefailurealmost never exceeds the selected threshold value.

Figure 7 shows the averagefailuremeasured for each link of the topology. This figure makes it clear that the few links of the initial topology are overloaded if the topology control algorithm is not applied, thus, con firming the results presented before. From another perspective, this proposed topology management algorithm reduces the delays, figure 8, and the content retrieval time, figure 9. In fact, by distributing the load over multiple links and adding new routes to decrease the routes’ total transfer time, it becomes possible to decrease average delay and content retrieval time, increase the throughput and responsiveness perceived by the users.

Selecting an appropriate reasonable threshold depends on the network parameters like delay, the length of largest shortest path, de-sired RTT between every two nodes, cache size, and the trafficc pattern.

Fig. 6. CDF of average failure of links for different network loads.

Fig. 8. Average delay for each chunk of different contents in different values of network load.

Fig. 9. Average retrieved time for each content ID for different values of network load.

V. CONCLUSIONS

In this paper, the SDN based implementation of ICN is proposed as a preferable way of deploying ICN over existing IP network. It eliminates most of the complexities by introducing a centralized controller for topology management of the ICN overlay. The main objective of topology management in this proposed method is load balancing, decreasing network delays, and ultimately improving the user experience by reducing the content retrieval time. For this purpose, an ICN overlay is constructed, monitored and managed applying the controller. This dynamic topology enhancement is based on monitoring a failure metric de fined in the proposed method which is implemented easily in software in SDN controller without requiring any other extra modi fication in the network. Experimental results on PlanetLab indicate the effectiveness of this proposed method in achieving its objectives.