SD-ICN: Toward Wide Area Deployable Software Defined Information Centric Networking

Abstract

Information Centric Networking that uses content name instead of IP address as routing identifier can handle challenges such as traffic explosion and user mobility, but it also suffers from scalability and incompatibility problems. In this paper by combining the concept of software defined networking and Internet end to end arguments, we propose a wide area deployable software defined information centric networking service model named SD-ICN. SD-ICN employs a dual space structure that separates edge service network and core transmission network. The enhanced SDN techniques are used in edge service network in order to implement intelligent data routing and caching, while traditional IP technique is reserved in core transmission network so as to provide wide area high speed data transmission. Besides, a distributed name resolution system based on the cooperation of different controllers is also presented. The prototype experiments in our campus network show that SD-ICN can be deployed in a scalable and incremental way with no modification of the core network, and can support typical communication modes such as multicast, mobility, multihoming, load balancing, and multipath data transmission effectively.

1. Introduction

With the evolution of the Internet, mobile access traffic has become a main component of Internet traffic, thereby presenting significant pressure and challenge to the current network infrastructure. Moreover, the emergence of new applications such as multimedia content distribution results in a traffic explosion problem. In the face of these challenges, the TCP/IP architecture that aims to achieve host to host data transmission cannot satisfy network application requirements. Information Centric Networking (ICN) is one of the future Internet architectures aiming to solve such problems [1]. The typical features of ICN, such as content name based routing, intelligent data caching, and transparent content location, are appropriate for the evolution of the Internet from a host to host communication infrastructure to an information-sharing service platform. Many ICN implementations have been proposed in recent years, i.e. NetInf [2], NDN [3], PURSUIT [4], SOFIA [5], etc.

Although many efforts with regard to ICN have been made, a few open problems still exist that need to be solved. Firstly, ICN proposals such as NDN use the clean slate design philosophy, whose architectures are incompatible with the TCP/IP architecture. Thus deploying these architectures widely in a short time is impractical. Secondly, the Internet scale name based routing mechanism is difficult to perform routing aggregation, and thus the routing scalability becomes another barrier. Thirdly, according to the design philosophy, ICN can provide a better host mobility support. However, due to problems such as routing update convergence and routing table aggregation, most of current ICN service models still have drawbacks in supporting the mobility of content publishers [6].

In this paper, we attempt to find solutions by investigating the fundamental requirements of network communication. There are two key technical mainlines in the Internet evolution history: one is high speed data transmission and the other is intelligent data processing. The former provides fast routing and high speed connection among wide area distributed hosts, and thus, this component should have a simple packet processing capability. The latter provides on demand data processing capabilities such as reliable data transmission and intelligent data caching; such features require a complicated processing logic. In the TCP/IP architecture the former is implemented by routers, whereas the latter is implemented on the end systems, thereby forming the well-known end-to-end arguments [7]. However, with the emergence of new network applications, these arguments have shortcomings in solving problems such as traffic explosion and user mobility [8].

ICN implements the data caching and name based routing mechanism in the network core. Such a mechanism can help optimize the performance of applications, but it increases the complexity and cost of routers. Furthermore, letting all nodes participate in the intelligent data processing is not the only solution. For example, some studies show that the pervasive caching in ICN provides small performance improvement compared with the edge caching [9]. Thus, in the development of ICN, a reasonable definition on the boundary of high speed data transmission and intelligent data processing should be given by extending the end to end arguments. One the one hand, the core network should be kept simple and efficient, so as to reserve the wide area high speed data transmission capability of the Internet. On the other hand, the data processing capability in the edge network should be enhanced by using the flexible software and hardware structure, so as to improve the intelligent on demand data processing capability.

Software defined networking (SDN) separates the control plane and data plane, and uses the logically centralized controller to define the packet processing policy. Such a mechanism opens the network control plane, and provides a technical support to improve the network data processing capability [10]. Thus, by combining the SDN concept and the end to end arguments, we provide a wide area deployable software defined information centric networking service model SD-ICN. We also give the dynamic name resolution and routing mechanism under the dual routing space. Furthermore, we discuss the functions of SD-ICN, and implement a prototype in our wide area campus network to evaluate the feasibility and performance of SD-ICN. The main contributions of this paper are as follows:

Firstly, based on the analysis of the data communication requirements, we provide an innovated dual space ICN service model named SD-ICN. Such a model separates the high speed data transmission capability in the core network and intelligent data processing capability in the edge network, thereby effectively improving the ICN scalability. SD-ICN also provides an incrementally deployable architecture; hence, the qualitative benefits of ICN can be achieved without any changes to the network core.

Secondly, we propose a two-layer content search mechanism in SD-ICN and implement a prototype of SD-ICN. By doing so, we demonstrate that SD-ICN can support many features such as unicast, multicast, load balancing, multi-homing, and multi-path transmission, etc.

The remainder of this paper is organized as follows. Section 2 gives the related works. Section 3 presents the architecture as well as the content name routing mechanism of SD-ICN. Section 4 discusses the typical communication types supported by SD-ICN. Section 5 develops a prototype of SD-ICN to evaluate its feasibility. Finally, section 6 concludes the paper.

2. Related Work

Existing ICN proposals [2,3,4] build ICN architectures upon content abstraction. For example, NDN adopts a distributed name based routing mechanism, and maintains forwarding information base, pending interest table, as well as content store in each network nodes. NetInf uses a multilevel DHT-based name resolution service called MDHT that provides name-based routing. Intra-area routing and forwarding is done according to the rules of the local DHT algorithms, while inter-area routing is done by the node in both the local DHT and the next higher level DHT [11]. PURSUIT shifts the current send-receive based Internet toward the new publish-subscribe paradigm, and uses the rendezvous network to perform name resolution and data forwarding [4]. These proposals share some commonalities in the perspectives of basic primitives, name based routing, universe in-networking caching, etc [3].

However, there are also some deficiencies in wide area content location as well as data forwarding of these proposals. Though quite a number of improvement mechanisms are proposed, such as stateless forwarding [12], semi-stateless forwarding scheme [13], it still has problems such as routing inefficiency, poor scalability, etc. Besides, due to the routing aggregation constraint, the mobility of content publisher cannot be supported effectively by most of the current proposals [6], and a better node mobility support mechanism for ICN is still needed.

On the other hand, the separation of control plane and data plane, as well as the software defined packet processing mechanism in SDN provides a way of flexible packet processing. Due to the flexibility of SDN, how to use it to cope with the problems in ICN is also discussed comprehensively. Syrivelis et al. propose a SDN and ICN combined architecture [14]. Salsano et al. implement a SDN based ICN architecture and gives an experiment on the OFELIA testbed [15]. However, most of current proposals focus on extending the OpenFlow protocol so as to support ICN packet forwarding, but the problems such as wide area deployment and scalability are not discussed in detail. How to design an evolvable, scalable, and incrementally deployable ICN service model is still an open problem.

Incremental deployment is another focus of attention recently. Fayazbakhsh et al. analyze the necessity of pervasive caching and nearest-replica routing in ICN, and presents an incrementally deployable ICN architecture [9]. Mukerjee et al. propose a general incremental deployment method of new network architecture based on intelligent control plane [16], which can be seen as an upper layer abstraction of our method. XIA [17] is an expressive Internet architecture with native support for multiple proposals, and its main aim is how to support the long term evolution of network architecture, which is quite different from that of SD-ICN. The relationship between SD-ICN and XIA can be regarded as that the former could be implemented within the latter’s architecture.

 

3. Architecture Design of SD-ICN Service Model

3.1 Overview

In accordance with the functional requirement, SD-ICN includes two parts: Core Transmission Network (CTN) and Edge Service Network (ESN). The two parts use different technologies to solve high speed data transmission and intelligent data processing tasks. Thus, a dual space service architecture that allows network edge and network core to evolve separately is formed. In such architecture, CTN that provides wide area connection service is located in the network core and is unique globally. ESN is located in the network edge and includes a group of edge service subnets. As shown in Fig. 1, four edge service subnets are connected through the CTN to provide intelligent data processing service.

Fig. 1.architecture model of SD-ICN

The CTN constitutes the high speed data transmission space of SD-ICN, and it has an independent unified address space. Given that the wide area routing function of the Internet is one of its most valuable parts, the CTN of SD-ICN also uses IP to provide packet routing and forwarding service for ESN. Hence, SD-ICN is compatible with the widely deployed Internet architecture.

The ESN constitutes the intelligent data processing space of SD-ICN, and it is divided into different edge service subnets connected by the CTN, ESN = {ESNi, I = 1,2,...n}. Considering that SDN can implement complicated data processing and control functions based on software defined method in the controller, the enhanced SDN mechanism is introduced in the edge service subnet to perform intelligent data processing and content name based routing and caching. Each edge service subnet includes a logically unique controller and some ICN enabled OpenFlow switches. The intelligent content routing is performed based on the controller decision.

Fig. 2 shows the logical structure of the edge service subnet, which adopts the control plane and data plane separation concept of SDN. The upper control plane maintains the topology view and the resource view of the edge service subnet. The control plane is responsible for controlling decision related operations such as content name registration and resolution, global content location, content processing rule generation, and content transmission optimization, etc. Meanwhile, the bottom layer data plane is composed of name routing enabled OpenFlow switches, content caching devices, and end systems. The data plane is responsible for content name based data transmission.

Fig. 2.logical structure of edge service subnet

In each edge service subnet, the content name based routing mechanism is implemented by enhancing the functions of the controller and OpenFlow switches. The dynamic registration and query mechanism of content name in an edge service subnet are also designed. Furthermore, to interconnect the ESN and CTN, the OpenFlow gateway (OFG) is designed by extending the basic functions of OpenFlow switch. Each edge service subnet has a unique OFG logically, but it can have many implementation instances so as to satisfy the scalability requirement. The OFG plays an interconnection role between the edge service subnet and the core transmission network. For one thing, packets can be routed to the OFG through name based routing in the edge service subnet. For the other, each OFG also has a global IP address of the core transmission network, and thus packets can be routed to different OFGs through IP based routing in the core transmission network.

Fig. 3 demonstrates the content transmission process in SD-ICN through a simple network structure. Suppose host H0 and H1 are located in ESN1, whose controller and OFG is Ctrl1 and OFG1 respectively. Host H2 is located in ESN2, with Ctrl2 and OFG2 as its controller and OFG. When host H0 requires content Namei that stored in host H2, its request will reach Ctrl1 through the forwarding of OpenFlow switches. By using the name resolution system, Ctrl1 finds that Namei is located in ESN2 that has IP2 as the address of OFG2, and then Ctrl1 will add rules for the request packet and the response packet in the OpenFlow switch1 and OFG1. The format of the rule is , in which Name is the identifier of the content, Type shows whether the packet is a request packet or a response one, and Next-hop denotes the next hop that the packet should be forwarded. The request packet will then be routed to OFG1, which encapsulates the ICN packet into an IP packet with source address as IP1 and destination address as IP2. Next, the encapsulated IP packet will be routed to OFG2 through the CTN. Ctrl2 will also add rules for the request packet and the response packet in the OpenFlow switch2 and OFG2. OFG2 extracts the ICN packet and routes this packet to host H2 through name based routing. When H2 sends the response packet, given that all the related switches and OFGs already have the rules in their flow table, the response packet will be routed back to H0 in reverse.

Fig. 3.demonstration of content transmission process in SD-ICN

Moreover, the received content can be cached in the end system such as host H0 or other specific caching systems. Other end systems, such as host H1, can fetch the content in the local edge service subnet directly. Thus the network transmission load is decreased, whereas the content fetching efficiency is increased.

3.2 Controller Cooperation based Content Routing Mechanism

In SD-ICN, the CTN of SD-ICN uses the IP routing mechanism, whereas the ESN uses software defined content name routing mechanism. Given that the edge service subnets are distributed in a wide area and that different edge service subnets are independent of each other, the way to implement global name based content location and routing is an important problem in SD-ICN. In this paper, by using the logically unique controller that maintains information such as network topology and routing policy in each edge service subnet, we construct a scalable wide area content routing mechanism based on controller cooperation.

As in SDN, the routing in a single edge service subnet can be solved through the controller scheduling. By enhancing the functions of controllers in different edge service subnets, we construct a two-layer abstraction content registration structure to solve the global content name routing problem. In such a structure, the controllers in different edge service subnets form a distributed global name resolution system, and cooperate with each other to respond the content name registration and lookup. Considering the high efficiency of Distributed Hash Table (DHT), SD-ICN adopts a DHT based distributed name resolution system, which is shown in Fig. 4. The controllers of each edge service subnets build a logical DHT structure using their global IP addresses. As a result, the content name resolution problem becomes a distributed content lookup problem similar to that in P2P network. This problem can be solved effectively through the DHT structure.

Fig. 4.DHT based content registration and lookup

Suppose a node Hk in the edge service subnet ESNm adds content Namei. Hence, Hk will notify the controller Cm in ESNm to add the mapping relationship between Namei and Hk by registering Namei to the controller in ESNm. The registration format is (Namei, Hostk), which means content Namei is located in host Hk. Moreover, each controller must maintain a mapping between host and its current location. The format is (Hk, ), which means host Hk is connected to porti of switch SID, if host Hk moves to another location such as , an then the mapping will be updated to be (Hk, ).

During the content registration process, if other hosts in ESNm already have the replica of content Namei, then Cm will process no operation in the upper DHT based global name resolution system; otherwise, Cm will publish the registration information in the DHT structure with the format (Namei, IPm), in which IPm is the IP address of the OFG in ESNm. Such registration information will be stored in the corresponding controller of the DHT structure determined by the hash value of Namei. When searching for the content Namei, other nodes will discover that one or more replica of Namei is located in ESNm, whose OFG address is IPm. Given that many edge service subnets may have the replica of content Namei, the registration information is stored with the format (Namei, IP1,…,IPn), which means content Namei can be found in n edge service subnets with OFG addresses IP1, …, IPn.

Algorithm 1 presents the basic description of the content registration process.

Lines 1-5 demonstrate the local record operation process, in which localUpdate and localInsert are the information update and insert process in the local controller respectively. Lines 6-10 represent the global record operation process in the DHT structure, in which globalUpdate and globalInsert are the information update and insert process of content Namei, respectively. As observed from Algorithm 1, only the first addition of a content replica in an ESN will cause the insert or update operation in the DHT structure. Furthermore, the variation of content replica number is handled locally with no affect on the global DHT structure. Thus, the overall load on the DHT structure is decreased effectively.

The content lookup also includes a two-layer mechanism: global fuzzy search and local accurate search. The former provides a means to quickly locate the ESNs that have the content replica, whereas the latter determines which hosts have the content replica in a special ESN. When searching the content Namei, Hi firstly queries the controller Cm in its ESNm locally. If the matching result is found D = {< SID, proti >} (SID is the special OpenFlow switch identifier and proti is a port of switch SID, and the two values can locate a host uniquely), then the controller Cm will notify the related switches to construct a route from Hi to a certain host in set D. Otherwise, if no matching is found locally, then the controller Cm will use Namei as the key to search in the DHT structure. As a result, the DHT structure will send back a list of OFG addresses whose ESNs have the replica of content Namei. After receiving the OFG list, the controller Cm will select one or more ESNs to request content Namei based on some specific criteria. Suppose the ESNk with OFGk is selected, and then Cm will notify the related switches to construct a route from Hi to OFGm and will notify OFGm to encapsulate the request packet so as to transmit this packet globally through IP routing. Finally, the controller in ESNk will perform the local accurate search in its local ESN.

The deletion of content is also performed hierarchically. When host Hi in ESNm deletes content Namen, Hi will notify the controller Cm in ESNm. Cm will then delete the mapping relationship between Namen and Hi. If other hosts in ESNm still have the replica of content Namen, then Cm will process no operation in the upper DHT based global name resolution system; otherwise, Cm will request to delete the mapping relationship between Namen and its OFG IP address. After the deletion in the upper DHT, if no other ESN has the replica of content Namen, then the recording entry of Namen will be deleted from the DHT structure.

Algorithm 2 describes the content lookup and deletion process. For content lookup, if a replica is found in local ESN, then the controller can select one or more hosts as the content publishers, and can notify the related switches to construct a route to these hosts. During the communication process, the route and the hosts can be adjusted dynamically.

Suppose there are n ESNs in the SD-ICN architecture, and each ESN has m hosts. The time complexity of local content lookup can be reduced to O(1) by using Hash method [18]. According to the definition of DHT, in a DHT structure with n nodes, the time complexity of global content lookup is O(logn) [19]. If the content requested by a node pi locates evenly among different ESNs, then the probability of the requested content in the same ESN with pi is whereas the probability of the requested content in different ESN with pi is Accordingly the time complexity of finding such a content will be Notably, in each ESN, only the first request of a content needs the global content lookup process. Subsequent requests can be served locally because of the local caching feature of SD-ICN. Thus, the average content lookup complexity for a random host will be which means it has a time complexity of As n increases, the multi-level DHT [11] technology could be used to guarantee the lookup latency.

If multiple ESNs that have the required content replica are found, then one or more optimized targets need to be selected from them. To utilize the advantage of ICN’s content name based routing, we design a multiple controller cooperation based content locating mechanism in SD-ICN. This mechanism can perform the best mapping between content name and content location based on criteria such as network performance, network policy, etc. Algorithm 3 describes the basic concept of such a mechanism.

In algorithm 3, IPList represents the set of ESNs that have content Namei, and uIP represents the OFG address of the content requester’s ESN. Firstly the path information as well as the path properties to all candidate ESNs is acquired. Then an integrated path cost is calculated. Finally one or more ESNs are selected as the communication targets based on the calculated costs, whose OFG addresses are returned back to the content requester’s controller.

After receiving the content location information, the controller of the content requester will construct the transmission paths. It’s needed to point out that the path cost here could be defined flexibly according to application types. For example, the online streaming applications should select paths with high available bandwidth and low jitter, whereas the interactive applications should select paths with low latency, etc. Algorithm 3 only provides the optimized target selection capability of SD-ICN, and the detailed cost definition as well as cost calculation is beyond the scope of this paper. Such an issue will be discussed in a future work.

 

4. Typical Communication Types of SD-ICN

Before data transmission, SD-ICN uses the controller to select the best communication peers based on the content name. SD-ICN can support typical communication types such as unicast, multicast, mobility and multi-homing, load balancing and multipath transmission effectively. In this part, we will analyze the implementation mechanism of typical communication types in SD-ICN.

4.1 Unicast

In unicast communication mode of SD-ICN, if the content requester and publisher are located in the same edge service subnet, then they will use content name based routing directly. The controller is responsible for determining the route by sending the specific flow processing rules to the related OpenFlow switches. If the content requester and publisher are located in different edge service subnets, then the data will traverse two edge service subnets and the CTN. Such a process has already been discussed in Section 3.

During the communication process, the source host only needs to send out its content request, and does not need to know in which host and ESN the content is located. All the content lookup and mapping operations are handled by the cooperation of the controllers and the OFG gateways. Moreover, when there are multiple replicas in the network, the controller can select the best one according to the predefined criteria. The communication peer can also be changed dynamically during the communication process, which is also handled by the controllers and is transparent to the end host.

4.2 Multicast

Multicast is a network function that facilitates efficient information dissemination. Based on the content name routing in edge service network, SD-ICN can support content multicast in the granularity of different ESNs.

As shown in Fig. 5, host H1, H2 and H3 in ESN1 are all requesting content Namei. When these request packets arrive at the OFG1, it will ask the controller to handle such requests. The controller finds that ESN2 has the content, and then it will notify the OFG1 to encapsulate only one packet with source IP address IPOFG1 and destination IP address IPOFG2. After receiving the response IP packet, OFG1 will extract the content packet and send this packet to H1, H2 and H3 separately. When hosts in multiple ESNs request the same content in server S, S could only send one copy to OFG2, and let OFG2 encapsulate a packet for each ESN. In this manner, the edge service subnet based multicast mechanism is implemented, and the traffic load in the wide area network is decreased.

Fig. 5.multicast in SD-ICN

4.3 Mobility and Multihoming

Since SD-ICN uses the content name based routing in the edge service network, and the end hosts do not care the location of contents, the mobility of end hosts will not affect the ongoing communications. With the dynamic mapping of content name and the OFG address, SD-ICN can support the mobility of both content requester and content publisher effectively. Meanwhile, the switching among different interfaces of the multi-homing node can be seen as a special type of mobility, and it can also be handled by SD-ICN effectively.

Suppose hosts H1 and H2 are located in ESN1 and ESN2, and the original communication path is . When H2 moves to ESN3, H2 will firstly register to controller C3 in ESN3. Then C3 will notify controller C1 in ESN1 to update the mapping relationship. Finally will be used as the new data transmission path. In this manner, the goal of seamless handover during node mobility can be achieved.

Such a feature is vital for improving the data transmission performance. The following two issues are solver effectively: the limitations of mobility support in IP network and the inability to handle content publisher mobility effectively because of route aggregation in current ICN proposals. By supporting the interface switch of multi-homing hosts, SD-ICN can ensure seamless host switch among WiFi and 3G interfaces according to the traffic and network performance status.

4.4 Load Balancing and Multipath Data Transmission

SD-ICN uses content name based routing mechanism in the edge service network, and let the controller be responsible for the dynamic mapping between the content name and the core transmission network IP address. Thus during the mapping process, a dynamic load balancing and multipath transmission mechanism can be implemented according to the content location status.

For load balancing, suppose a server S1 in ESN1 is selected as the content downloading source, if the transmission rate is decreased due to the overload of S1 or ESN1, the controller can adjust the mapping between the content name and the OFG, and switch to another server S2 to download the content. Such a switch is accomplished by the controller dynamically, and is totally transparent to the end host.

By using the feature of dynamic mapping between the content name and the IP address, SD-ICN can also achieve the multipath efficient data transmission aims. As shown in Fig. 6, host H1 in ESN1 request the content Namei, and when such a request arrives at the OFG1, it selects to download the content from S1 in ESN2, and thus forms the transmission path. If the bandwidth of such a path cannot satisfy the application requirement, OFG1 can select S2 in ESN2 and S3 in ESN3 as the communication peers too, and form three parallel data transmission paths , , and simultaneously. The content data is scheduled among the three paths, so that the data transmission efficiency can be increased. Besides, the end host only sees the content name, and it does not care how many paths are used to transmit the data. Thus, the number of transmission paths can be adjusted dynamically according to the content distribution and network performance status.

Fig. 6.multipath data transmission in SD-ICN

The multipath data transmission in SD-ICN is fundamentally different form that of MPTCP. MPTCP utilizes multiple paths for data transmission for the same TCP connection between two ends, while multipath transmission in SD-ICN could involve multiple servers, rather than a fixed one. Besides, the implementation of multipath transmission is transparent for the applications. Compared with other information centric networks such as NDN and Sofia, SD-ICN utilizes a dual space structure that separates edge processing and core transmission, which has a better scalability.

 

5. Prototype Implementation and Evaluation

5.1 Prototype Implementation

The controller in SD-ICN is implemented based on the POX controller, whereas the OFG gateway is implemented by enhancing the OpenFlow switch. Finally, the end host is modified so as to support the name based communication.

The main components of the controller and switch are shown in Fig. 7. The OpenFlow switch maintains the flow table, which supports the flexible routing policies defined by the controller. The OFG gateway has an additional packet encapsulation component apart from the standard OpenFlow switch components. This component is responsible for data encapsulation of packets transmitted among different edge service subnets. The controller manages the topology, path, and cache in its subnet and DHT structure with other subnets. With the cooperation of different controllers, the content replica can be optimized according to the request distribution.

Fig. 7.structure of controller and of-switch in SD-ICN

The main goal of this paper is to demonstrate the feasibility of SD-ICN. Thus, we use the raw socket programming method to generate the content requesting packet. The format of the header is similar to that of the IP packet, but the semantic of the two formats is different. For example, we use the 64-bit source and destination address fields to represent the hash value of the content name, and we use the protocol type field to identify the ICN request and response packet.

After receiving a packet, the OpenFlow switch identifies the ICN packet based on the protocol type field, and then it uses the 64-bit content name hash value and the protocol type to match its flow table. If a matching entry is found, then the packet will be forwarded based on the entry; otherwise the packet will be forwarded to the controller. For the content request packet, the controller finds the best replica of the requested content based on the DHT structure, and sends back the flow entries to the switch. The flow entries include an entry for the request packets and an entry for the corresponding response packets. Since the forwarding path for the content response packet will be constructed when handling the corresponding content request packet, match entries will be found in the specific OpenFlow switch for the content response packet. The switch will then forward packets (either request packets or response packets) to the appropriate destination host (if located in the same edge service subnet) or to the OFG gateway (if located in different edge service subnet). The OFG gateway is responsible for encapsulating packets and sending them to the right destination edge service subnet’s OFG gateway through the core transmission network. And finally the destination edge service subnet’s OFG gateway extracts the ICN packets and sends them to the right end host.

To validate the feasibility of the SD-ICN service model, we implement a prototype as shown in Fig. 8. The prototype includes three edge networks connected by our campus IP network. Each edge network includes three OpenFlow switches, one OFG gateway, one local controller and a few end hosts. We implement the OFG and the DHT name resolution system for each ESN. We also implement the raw socket programming based video streaming and file sharing demonstration applications in the end host. The experiments are repeated 15 times and the result is the average of these experiments.

Fig. 8.experiment environment of SD-ICN

All OpenFlow switches are 64-bit Linux PCs with five Ethernet ports, running the OpenFlow 1.0.0 Stanford reference software implementation [20]. It supported 100 Mbps throughput without dropping packets, which is sufficient for our experiments. For our prototype, other hardware OpenFlow switches can also be used. But in the future work, some modules such as an improved content name based routing mechanism may be added to the switches. Thus the software based implementation is a better choice. The OFG gateway is implemented based on the OpenFlow 1.0.0 Stanford reference software implementation, and modules such as packet encapsulation and IP packet forwarding are added. The POX OpenFlow controllers are used, and also Python modules are developed for local name resolution, global DHT name resolution, flow table manipulation, etc. Controllers in different edge service subnets form a chord DHT structure, and content names are registered in the chord structure.

5.2 Experiment Analysis

5.2.1 Multicast

Firstly we give a test on the multicast capability of SD-ICN. Host HB1 in ESNB registers a 2 Mbps high-definition video streaming Vi in the network, and Hosts HA1, HA2, HA3, HA4, HA5 and HA6 in ESNA all request to watch such a video streaming at different intervals. When the first request arrives at the OFGA, OFGA will query CtrlA for the mapping relationship of Vi and the global IP address, and will then encapsulate the request packet to process the wide area communication. When the other requests arrive at OFGA, OFGA can duplicate the received streaming packets, and then send them to HA1, HA2, HA3, HA4, HA5 and HA6. If host HA1 leaves during the multicast process, then CtrlA will capture such an event, and select another request from other host randomly as the new representative request. The upload and download rates are calculated every 8 seconds.

Fig. 9 shows the comparison of the streaming server’s upload rate and the sum of hosts’ download rate. As the number of hosts joining the multicast process increases, the sum of the download rate that each host acquired also increases accordingly. However, during the entire process, the upload rate of the streaming server remains constant. Such an experiment illustrates that SD-ICN is an attractive architecture to support multicast, and thus provides an efficient solution for live video streaming, multiparty video conference, and IPTV.

Fig. 9.transmission rate comparison of server and hosts

5.2.2 Multihoming

To validate the multihoming supporting capability of SD-ICN, we let host HB1 in ESNB register a video streaming application Vi in the network, and then HA1 in ESNA requests such a streaming by name. HA1 has two network interfaces: a wired one and a wireless one. The link bandwidths of these interfaces are restricted to be 2 and 1 Mbps respectively through the Linux TC tool. During the communication process the wired link that has a higher speed is preferred if possible, and the data transmission rate is also calculated every 8 seconds.

Firstly, the streaming is transferred from host HB1 to host HA1 via the wired link at approximately 2 Mbps. Then, the wired cable of host HA1 is unplugged. As shown in Fig. 10, the SD-ICN detects the failure of the wired network interface and switches to the low speed available wireless interface by notifying the controller about the change of the transmission interface. All these operations are transparent from the perspective of the application. Afterwards, the wired cable of HA1 is re-plugged. The SD-ICN switches back to the wired link without interrupting the transfer. Our experiment results demonstrate that SD-ICN can support multihoming efficiently, and thus provide a useful way of utilizing the increasing number of ubiquitous multihoming devices.

Fig. 10.multihoming switch data transmission

5.2.3 Load Balancing and Multipath Data Transmission

During the load balancing capability evaluation process, we let HB1 and HB2 in ESNB and HC1 in ESNC register a large file Fi in the network, and then HA1 in ESNA downloads such a file by name. The data transmission rate is recorded every 8 seconds. The upload rates of HB1, HC1, and HB2 are restricted to be 2048, 2048, and 1536 Kbps respectively through the Linux TC tool.

Firstly HA1 downloads Fi from HB1. Afterwards, we restrict the access bandwidth of HB1 to 1 Mbps. When detecting the transmission rate decreasing, the controller selects HC1 as the new server; thus HA1 requires Fi from host HC1. A few moments later, we also restrict the access bandwidth of HC1 to 1 Mbps. The controller then selects HB2 as the new server. Fig. 11 presents the downloading bandwidth variation during such a process. The trend shows that as the bandwidth changes, SD-ICN can always help HA1 select the best download sources dynamically.

Fig. 11.load balancing in SD-ICN

To validate the multipath data transmission capability, we let HB1 and HC1 register a large file Fi in the network and adjust their access bandwidths between 200 and 1000 Kbps dynamically. The download rate is recorded every 8 seconds. When HA1 requires the content Fi, the controller of ESNA will map the content name Fi to the OFG IP addresses of both ESNB and ESNC. Accordingly, HA1 can download data from HB1 and HC1 simultaneously.

Fig. 12 shows the download rate of HA1 and upload rates of HB1 and HC1 with multipath data transmission mechanism. The trend shows that as the upload rates of HB1 and HC1 vary, the download rate of HA1 also varies correspondingly. In addition, the download rate HA1 is approximately equal to the sum of the upload rates of HB1 and HC1. Compared with the single data source downloading in traditional TCP/IP architecture, SD-ICN can improve the data downloading rate effectively.

Fig. 12.multipath data transmission in SD-ICN

 

6. Conclusions

To solve the deficiencies such as incremental deployment, scalability, and mobility support of existing ICN proposals, we propose a wide area deployable software defined information centric networking service model SD-ICN in this paper. SD-ICN utilizes the dual space architecture that separates the edge service network and the core transmission network. In the edge service network, the enhanced SDN technology is used to implement the intelligent data routing and caching functions. In the core transmission network, the high speed transmission IP functions are reserved. The controller cooperation based distributed name resolution system and the OFG gateways are implemented to solve the global name resolution problem. Finally, we implement a prototype that includes three edge service subnets and use the wide area campus network as the core transmission platform. Our experiment results show that SD-ICN can be deployed in a scalable and incremental manner without the need to modify the core IP network. SD-ICN can also support unicast, multicast, mobility and multihoming, load balancing and multipath transmission effectively. In future work, we will validate the feasibility of SD-ICN in a larger testbed, and the optimization of path selection and caching in SD-ICN is another important issue that needs to be considered further.