Towards Incremental Deployment of Diverse Network Architectures on the Internet

Ming Chen, Ke Ding,＊, Changyou Xing,＊, Honghua Zhao,＊, Qinghua Wu, Gaogang Xie

1 Army Engineering University of PLA, Nanjing 210007, China

2 Institute of Computing Technology, CAS, Beijing 100190, China

I. INTRODUCTION

The Internet, with TCP/IP as its core and narrow waist, has greatly promoted the independent development of both communication technologies and network applications, which brings unprecedented success to Internet consequently. However, the rapid advance of the Internet has also exposed essential issues such as scalability, security, mobility and manageability, which are inherent with the TCP/IP architecture. Therefore, various clean-slate network architectures have been proposed,e.g. content/service-centric [1][2], evolvability-preferential [3], mobility-oriented [4],to address these issues by replacing TCP/IP architecture in the last decade [5]. However,most of them have not attained wide deployment on the Internet. In fact, there is still no consensus on the future network architectures.

The root cause for the deployment problem of the future Internet architectures is the stability and rigidity of TCP/IP architecture,i.e. the inability of incremental deployment.Despite the shortcomings of the Internet architecture, its position and role are still not replaceable [5]. In this paper, we proposed three principles that the future Internet should obey to be well-defined network architecture:inheriting, evolvability and consolidation.In order to inherit the existing hardware and software resources of the Internet, the TCP/IP architecture must be maintained. Meanwhile to solve the above problems, the architecture must be changed to enhance its control ability.Software De fined Networking (SDN) [6][7][8][9] is a promising technology to solve the ossification problem of the TCP/IP architecture by separating data plane and control plane. However, since it becomes a centrally-controlled network, such a mechanism has been only applied in limited cases such as data center networks or enterprise networks [10]. Thus,it is very important to eliminate such a contradiction for developing the future network architecture.

This paper integrates SDN into TCP/IP architecture. The authors argue that the CDC mode network can support the principles they proposed.

To this end, we abstract the characteristics of the current Internet architecture as D mode(Distributed) and the SDN technology as C mode (Centralized) respectively. Based on the two abstractions, we enumerate all the possible combinations of them and analyze their properties. Among the combinations, CDC(Centric-Distributed-Centric) mode has great potential for the well-defined future network architecture. The essence of CDC mode is that the core of the Internet is kept unchanged,with TCP/IP as its core, which enables utilization of legacy hardware and resources; meanwhile, on the edge of the Internet, SDN is exploited for flexible control, which facilitates development and deployment of new network architectures, thus enabling the Internet architecture to evolve. It is argued that CDC mode is consistent with the essential principles of the development of the future network architecture. A prototype system regulated by CDC mode is implemented and experimental results reveal its great potential in developing the future Internet architectures.

The rest of this paper is organized as follows. Related work is discussed in Section 2.In Section 3, the essential principles that the future network architecture should obey are proposed, followed by several basic modes with SDN integrating into TCP/IP as well as their combinations. Section 4 analyzes that CDC mode is consistent with the essential principles of the future network architecture.A prototype system is developed to prove that CDC mode can support the traditional IP services and new services in Section 5. Finally,the paper is summarized in Section 6.

II. RELATED WORK

The Internet architecture, despite its unprecedented great success in the past decades, has been exposing great challenges and problems in traf fic scalability, security, mobility and others. Dozens of works, to name a few [3][1][2],have proposed either incremental changes or clean-slate solutions, attempting to rectify one or more of these afore-mentioned problems.

Blumenthal and Clark [5] argued that the development of the Internet architecture would continue to seed a new balance between the existing system and the newly proposed architectures. Authors in [11] argued that the stability of the evolutionary kernel is the evolvable basis of the diversity and complexity of the high-level processes, which could also be applied to the Internet system. Ratnasamy et al. [12] illustrated that the evolution of the system structure, such as IP, is considered to be a gradual change. These works above do not provide methodology as to how these proposed solutions are developed and deployed.

Many ongoing studies have proposed the future network solutions, which lie in the scope of new architecture to solve one or more problems that the current Internet faces,such as XIA [3], OPAE [13], CCN [14], NDN[1], DONA [15], the evolvable Internet architecture and coexistence of diverse Internet architectures, such as Framework for Internet Innovation (FII) [16]. Data-oriented network architectures like CCN [14], NDN [1], DONA[15], attempt to reduce server load and user-perceived latency when retrieving content by enabling in-network caching. XIA [3] enables evolvability of the Internet architecture by supporting multiple principals and fallback between them. However, both data-oriented architectures and XIA fail to be widely deployed, due to the complete lack of guidance as to how to coexist with the current Internet architecture.

SDN (Software-Defined Networking) is a promising technology which facilitates flexible network management and control by separating network control and forwarding [6][17].Our work is partially inspired by SDN Fabric[17]. However, the model and methods proposed for evolving Internet is quite different from what is being pursued. NOX [18] presents network operating system to control and manage networks. Despite the flexible control that NOX achieves, the centralized controller in NOX may be a performance bottleneck.DIFANE [19] rearranges the job of controller and the bottom hardware switches to reduce controller’s load. Chen et al.[26] integrated networking, caching and computing in a systematic way to naturally support data retrieval and computing services. These two approaches are clean slate solutions and cannot inherit the existing Internet assets.

NVP (Network Virtualization Platform)[20], dedicated for enterprise network and data center network, allows easy and flexible network management. B4 [10] connects Google data center networks at the global area. The primary goal of B4 is load balancing and full bandwidth utilization. Neither NVP nor B4 provides a general solution to data communication on the Internet.

CDC mode demands that SDN networks are built on the edge of the Internet, which provide user applications, and IP network lies in the core of the network, which provides data transportation ability. This mode is different from “SDN islands in the tradition networks or the SDN with East/West-bound interface”.

Mukerjee et al. [21] explored the design space of deployment mechanisms and decouple this process into detailed functions.This work focuses on how a new architecture evolves and obtains incremental deployment,but does not involve how multiple architectures coexist. Vissicchio et al. [22] developed a general theory for coexisting centralized and distributed control planes, which mainly focuses on routing protocols. Different from these above efforts, we in this paper mainly propose a CDC framework which enables the coexistence of diverse network architecture on the Internet.

Network researchers can run their prototypes and experiments, as well as to set up novel architectures for the future Interneton SDN testbeds. Several large-scale SDN testbeds have been designed and developed. [25]Most of these testbeds are quite complex, thus the federation of these global SDN testbeds is a challenge. The compatibility with legacy network equipment is another issue.

III. ARCHITECTURAL MODES WITH SDN INTEGRATED INTO TCP/IP

The Internet architecture, with TCP/IP as its core and narrow waist, has encountered great challenges in scalability, mobility and security.Many efforts on the future Internet architecture aiming to solve the above problems, have gained limited deployment due to the architectural stability and rigidity of the current Internet. For example, deployment of IPv6 has been increasing slowly over the past two decades, even though the transition from IPv4 to IPv6 only relates to network address.

The future Internet like CCN/NDN [14][1],SOFIA [2], which are promising in solving the problems faced by the current Internet, could not be erected and verified due to the difficulty of deployment in the current Internet.Furthermore, even though these architectures are deployed, there is still a lack of knowledge as to how to coexist with the current Internet and enable the Internet architecture evolvable. These problems motivate us to study the evolvability of the Internet and propose a novel architectural mode which facilitates integrating the future Internet solutions into TCP/IP network.

3.1 Basic ideas

In order to support new services and enable evolvability of the Internet, some well-defined principles must be presented at the very beginning. Firstly, the development of the future network does not mean that the Internet should or must be abandoned. The reason is that the Internet has huge number of software, hardware legacies as well as various kinds of data resources; and that the Internet itself has become an indispensable part of human society and information infrastructure. Any attempt to replace it with new Internet architectures must inherit its existing legacies. Secondly, the reason to develop the future Internet architectures is the current Internet architecture’s inability to overcome the emerging challenges. If a new mechanism is introduced to invent the Internet architecture, both the current and the future network problems can be solved, and the new architecture undoubtedly will have more advantages. Thirdly, as the new proposed solutions could only partially solve the problems the current Internet faces, there may be a variety of different architectures which are accommodated in one framework and interconnect each other. Therefore, an architecture which complies with the following principles is called a well-defined future network architecture F.

Principle 1: Inheriting principle.The architecture F is considered supporting inheriting if the widely used TCP/IP architecture ArchTCP/IP∈F, in which ArchIPis the architecture supporting the packet transmission function TIPand ArchTCPis that supporting the information processing function PTCP. That said,ArchTCP/IPis one of the component of F, and all Appj(j=0,1,…) should use TIPto implement the wide area packet transmission function.

Table I. Comparative characteristics of the current Internet, the future Internet and the SDN-enabled network.

Principle 2: Evolvability principle.The architecture F is considered supporting evolution (E（F)) if it has the ability to solve the current or future problems by customizing certain kinds of optimized architecture Archiby making use of the essentialcomponents of the current architecture.

Principle 3: Consolidation principle.The architecture F is considered supporting consolidation (C（F)) if for any type of application Appj(j=0,1,…), we have Archj∈ F (here Archjis the network architecture that supports Appj).That is to say, F contains the sub-architectures that support different types of applications,C（F) displays variety of the sub-architecture to different applications, and it also supports the global communication of different Appj.

More generally, given an N with architecture F, the consolidation property C（F)requires ?i=0,1,…ArchiF, while the evolution property E（F) requires that there exists an ArchiF or a new Archjcan be developed to solve the network innovation problems. Finally, inheriting property I（F) requires F to be ArchTCP/IPcompatible, and Archiimplements the network function by interacting with ArchIP.To summarize, the ultimate scenario that various network architectures could coexist and evolve in the current Internet is illustrated as “”, in whichis TCP/IP network, andcould be any future Internet architecture, e.g. CCN/NDN, SOFIA. In other words, the networks following the three principles should have the ability of incremental deployment or migration, and they must be supported by specific network architectures.

In the following, we first compare the characteristics between different network architectures, and present CDC mode which satisfies all the above principles.

3.2 Abstraction of Internet architectures

Table 1 lists the aim, technical advantages and main disadvantages of the current Internet, the SDN-enabled networks and the future Internet architectures. From the table, the current Inter-net and the SDN-enabled network have complementary characteristics. On the one hand,the Internet can support application innovation and cover the globe, whereas SDN (e.g.OpenFlow) network just has a small quantity of applications and covers limited area. On the other hand, SDN has powerful ability to control the network and may have the potential to solve the security, mobility and the QoS guarantee problems in the Internet. As for the SDN-enabled networks and the future Internet architecture, they also have quite different properties. Dedicated to enabling network innovation, SDN-based network is easy to be deployed by keeping addressing and forwarding semantics in the current Internet unchanged;in contrast, the future Internet is difficult in deployment due to its clean-slate design of addressing semantics. Due to the centralized control property, SDN-enabled network is able to quickly develop and deploy new proposed solutions. This inspires us to think about such a question: can we take advantage of the existing complementarity of SDN-enabled network to build the new future network architecture?If this can be achieved, SDN can exert profound in fluence on the Internet development.In the following of this subsection, we analyze the characteristics of the current Internet and SDN-enabled network architectures and in next subsection we demonstrate that by careful combination of Internet architecture and SDN technology, it is possible to make the future Internet architecture satisfy all the principles above.

The Internet, with the TCP/IP architecture provides a means of connectionless communication between any two end hosts on the network, which mainly deals with communication resources. The routing tables are built in routers based on their distributed algorithms, and packets can be forwarded to the destination host only by matching the destination address with the routing tables. The most remarkable advantage of this distributed model is its scalability and simplicity. Whenever a router or link has been changed, the routers can automatically learn from each other and update their routing table, and a new equilibrium is reached after the convergence of the routing algorithm. This operating mode of TCP/IP architecture is called “D” (Distributed) mode.

On the other hand, SDN adopts a centralized way to control and manage the operation of the network. A unique controller makes decisions to indicate the switches the way to forward packets. Then, it delivers flow entries to the switches respectively to form network paths. Different from mode D, SDN has the following features. Firstly, even the switches are physically connected; they cannot forward packets before the corresponding flow entry is installed. Secondly, the flow entries can be used not only to manage the bandwidth resources but also to manage and control the storage and computing resources via redirection. Thirdly, the controller can monitor the state of the flows and is able to intervene and change their operations. Therefore, this centralized model enables the controller to control and manage the behaviors of the network to satisfy the changing requirements of the network security, performance, mobility and other aspects. This operating mode of SDN is called “C” (Centric) mode.

Fig. 1. Model of mode D.

Fig. 2. Model of mode C.

For the convenience of theoretical analysis, Directed Acyclic Graph (DAG) is needed to model mode D and mode C, and then the properties of the both will be studied. Figure 1 illustrated the model of mode D, in which the source host HS can send packets to the destination host HD via the core network Core.This model has four important properties: i.Any two points in the network (e.g. abstracted as HS and HD) are reachable by default. ii.There exists a path between the two points,which is determined by the Internet routing algorithm (abstracted as Core). iii.Any functions provided by an IP network must be fulfilled along this end-to-end path. iv. The coverage of IP network is up to the global. The Internet accords with this model.

The model of mode C is shown in figure 2, in which the premise that the source host HS can send packets to the destination host HD through the data plane DP is that it has obtained the permission from the controller C and the path is built according to the flow identification. The dashed line between DP and HD denotes that it is impossible to establish the resource supply chain without the access of the controller. Mode C has four important properties: i.Any two points in the network (e.g. abstracted as HS and HD) are disconnected by default and the path is established by the controller. ii.The controller C can control the network behaviors at the flow granularity through software programming(such as changing the flow path to provide different resources, or stop malicious flows, etc.),which can increase a lot of control ability and flexibility. iii.Once the flows enter the data plane, the controller C either ignores them or keeps monitoring and processes them if needed. iv. The network’s coverage is limited to a small area. OpenFlow network accords with this model.

Fig. 3. Model of mode CD.

Fig. 4. Model of mode DC.

3.3 Combining mode C with mode D

As discussed above, mode D and mode C have some complementary properties. In this subsection, DAG is used to analyze and discuss the nature of the combination models of mode C and mode D.

3.3.1 Mode CD

Figure 3 illustrates mode CD, in which the edge network in the side of end system HS uses mode C, and HD is directly connected with the core network which still uses mode D, so mode CD is obtained. In mode CD, if the end system HS wants to communicate with HD, the controller must give the green light first and build a path based on the flow identity, then packets are forwarded to the core network Core to form a flow.

Mode CD has the following important properties: i.It’s inherited the former three important properties of C mode. ii. It’s able to extend network coverage to the global. iii. The path is composed of two parts, and the sender plays a decisive role in the connection. Some of the data center networks that take advantage of the OpenFlow technology to manage the network are in line with this model.

3.3.2 Mode DC

The model of mode DC is shown in figure 4.Mode DC will be obtained when HS is directly connected with the core network while the edge network in the side of HD adopts mode C. In mode DC, the end system HS can directly reach the edge network in the side of HD through the core network, but it cannot communicate with HD until the controller C allows and manages it. After that, a flow can just be built and an end-to-end path can be formed.

The properties of mode DC is similar to those of mode CD and the mode has the following important properties: i. The first three important features of mode C are inherited.ii. The network coverage can be extended to the global. iii.The path is composed of two parts. One half is an IP connectionless path,and the other half is a flow-based path built by the controller in the destination side. In this connection the controller plays a decisive role.Some applications, which the hosts are directly connected to the Internet on one side, and the edge network uses OpenFlow technology on the other side, accord with this mode.

3.3.3 Mode CDC

The model of mode CDC is shown in figure 5. HS and HD respectively connect the edge networks using mode C, and then they are connected with the core network using mode D. In mode CDC, the host HS at the source edge network must obtain permission from the controller C1 before sending packets to the core network. When packets arrive at the destination edge network, it has to obtain permission from the controller C2 and establish a flow to HD before the packets in the flow are forwarded.

Mode CDC has the following important properties: i. The first three important features of mode C are inherited. ii.The network coverage can be extended to the global. iii.The path is composed of three parts, where the controller either in the source side or the destination side plays a key role in the resources sharing.A number of applications in data centers (e.g.Google’s B4[10]) accord with this mode.

3.3.4 Mode DCD

The model of mode DCD is shown in figure 6. Model of mode DCD, where HS and HD connect mode D network Core1 and Core2 respectively and then the Core1 connects the Core2 by a mode C network. In mode DCD, a flow from the HS must obtain the permission of controller C after it enters the Core1 network, and then a path is built and enters into the Core2 network. Finally, an end-to-end flow to the destination HD is formed.

Mode DCD has the following important properties: i.The first three important features of mode C are inherited. ii.The network coverage can be extended to the global. iii.The path is composed of three parts. The controller in the core network plays a key role in the resources sharing. The scene two IP networks connected through the BGP router controlled by a SDN controller accord with this mode.

After presenting all the possible combinations of mode D and C, Table 2 lists the pros and cons of these architectural modes, in which G stands for global, I for inhering, E for evolvability, and C for consolidation. From the table, the proposed Mode CDC has great potential for the well-defined future network architecture, which is explained in detail in next section.

IV. ANALYSIS OF THE CDC ARCHITECTURAL MODE

Fig. 5. Model of mode CDC.

Fig. 6. Model of mode DCD.

Table II. The pros and cons of possible architectural modes.

In the networks categorized as CDC mode,all the end systems are located in OpenFlow subnets, a source OpenFlow subnet connects an IP core network and then the IP network connects with a destination OpenFlow subnet along an end-to-end path. There is no change about the end system’s hardware or software in the edge networks, where commodity OS like GNU/Linux, Windows are still used, and applications and data resources can work without any changes. Moreover, the large number of IP routers and communication cables in the core network supporting packet transmission also remain unchanged. Compared with the original Internet, the only change is to replace the layer-2 switches at edge networks by OpenFlow-enabled switches and deploy a controller. Then the traditional IP network applications can work properly in the network with the CDC mode if a simple code runs in the controller. This indicates that the new mode can support TCP/IP architecture in the edge network while the core network can use the original IP infrastructure. Thus, the network with the CDC architecture can meet the inheriting principle.

If a newly proposed network architecture is to be deployed, SDN on both sides of the edge networks can be used to customize specific solutions to control the network resources by composing programs in the controller. In addition, extra control abilities for the network hardware and software can be provided by flow redirection function of SDN. Besides, the core network can provide the ability of packet transmission over the global. The above analysis indicates that there could be multiple architectures in the edge of the CDC network and a single IP architecture in the core of the CDC network, and so that the CDC network has the ability to evolve.

A natural requirement for the above multiple network architectures is that they should be consolidated in one framework, so that they can form multidimensional virtual service planes which in turn provide both logical isolation and interconnection. The multiple virtual service networks running over the edge of the CDC network can form through the IP core network, which satisfies the consolidating principle.

There are already proposals which combine SDN with TCP/IP being applied in some peculiar cases in the Internet. CDC mode is different from these techniques in the following aspects.Firstly, although such combination exists, no one has sublimated it into a network architecture mode and the proposed corresponding principles behind the architecture mode. Secondly, CDC mode makes all SDN networks lie in the edge of the network, which form an information space, while the IP network lies in the core of the new network, which forms a packet transmission space. The two spaces have essential difference and integrity functions.Thirdly, no matter which: NMS or AAA server in access networks, it involves little innovation of the edge of the Internet, while CDC mode provides good opportunities to change the architecture thoroughly, which involves serials of technical innovations of the network framework. CDC mode not only takes effect on the existing and new network applications, but also has in fluence on security mechanism, management mechanism and controller coordination mechanism etc., and this may lead to further study of such related topics.

V. PROTOTYPE AND EXPERIMENTAL DISCUSSION

By constructing a prototype system obeying CDC mode, this section verifies and discusses whether the proposed CDC-based network architecture can indeed fulfill the inheriting,evolvability and consolidation principles along with good potential for developing the future network architectures.

5.1 The prototype system

We have designed and implemented a CDC prototype system as shown in figure 7. The prototype system consists of 3 OpenFlow sub networks located at the edge and a core network composed of 3 IP routers. Each Open-Flow subnet consists of 4 OpenFlow switches,a controller and several Linux and Windows hosts. Among the switches, OFG1, OFG and OFG3 play the role as gateways connecting the OpenFlow networks to the IP network.

For the convenience of the experiments, all gateway switches are 64-bit Linux PCs with 5 Ethernet ports, running the OpenFlow 1.0.0 Stanford reference software implementation and others use Pica P3290 switches. The POX OpenFlow controller is used for manipulating flow entries of the OpenFlow switches. All the routers in the IP network are Cisco 2811,which use the IPv4 address scheme.

5.2 Inheriting traditional Internet applications

First, the control programs are running on the controller C1 in the ESN1: i.For the packets sent by the end systems in the local subnet, the corresponding flow entries are installed in the switches in the local subnet if the destinations of the packets belong to the local one, and then the communication can go on. ii.For the destinations of the packets that do not belong to the local one, the packets will be encapsulated by OFG1. The encapsulating method is that the source address is the ingress IP address of the router R-A, and the destination address is the egress IP address of the router connecting the subnet where the destination host is located. Next, controllers C2 and C3 in ESN2 and ESN3 respectively are deployed in the same way.

The experiments were conducted with the results that some typical Internet applications can run correctly and steadily in the environment, which adopt the C/S mode such as Web,email, FTP and so on. Moreover, other applications also can run normally in such case,which adopt the P2P mode such as BitTorrent.

Fig. 7. The prototype system.

Experimental analysis reveals the follow-ing: i.The edge network is changed a bit and the core network remains intact, and most of the Internet legacies can be inherited. ii.The policy “allowing all packets to pass through”is set actually on the involved controllers. If C1 does not permit, no host either in ESN1 or between the subnets can communicate with each other. Even C1 permits, the controller in the destination network may also manipulate it independently according to the policies. This indicates that the CDC network has powerful ability to control resources, and that it can provide brand new solutions to network security,network managementand mobile communication and so on. iii.The addressing scheme of the edge network may be different from that of the IPv4 in the Internet.

5.3 Supporting new Internet architecture applications

Information Centric Networking (ICN) [23]is a paradigm which implicitly exists in many newly proposed network architectures, like CCN/NDN[14][1], PURSUIT[24], and SOFIA[2]. ICN takes information as the thin waist of the Internet architecture and assign each piece of information a unique name for efficient retrieval, caching, and processing. In the following, we show how to enable ICN prototype to support new network functions such as content locating, nearest content serving, and optimal caching in the way of controlling resource flow. The steps of supporting ICN functions are as follows.

Step 1: In the edge network ESN1, the query for desired data resource FILM1 from a host is encapsulated in the packet header. The first packet of the flow is sent to controller C1 by the first OpenFlow switch since it does not match any flow entry. The judgment must be done first by C1 whether FILM1 the flow requested is located in ESN1, and C1 will install the flow entries in certain switches of ESN1 if it is, then the resource flow is forwarded. If FILM1 is not available in ESN1, C1 will send query messages to the controllers in other edge networks. If some of the controllers are aware of the location of FILM1, ACK messages with the location information will return, and the information includes the IP addresses of the server storing FILM1 and the corresponding OFG. Then host A1 sends a request to the source of FILM1 directly. If the flow passes across the edge networks, the packet is still encapsulated as described above.

Step 2: Some caching servers are deployed in the edge networks, e.g., host A2 is deployed in ESN1. At the moment, A1 demands to obtain FILM2 from other edge networks and FILM2 is estimated as a popular resource,so controller C1 arranges the resource flow to send to A1 while FILM2 is backed up in the caching server A2. As a result, FILM2 is cached in A2 and all stored resources are managed by LRU, and C1 also updates the resource list. As soon as a host such as A3 requests FILM2, C1 will locate the optimal resource position as A2, and thus A3 will retrieve FILM2 from A2.

Experimental analysis reveals that ICN application could be completely supported in CDC mode architecture: i.The requesting host in the experiments only expresses its interests towards the network, while the locating resources and optimally storing resources and other functions are done via the controller actually, which dispels the limitation that IP networks only transfer the packets, and the network functions are extended greatly, while network traffic decreases. This work makes use of the evolvability property of the CDC network. ii.Controller is essential because the storage and the computing resources in the edge networks could be only exploited and managed by the controller. Under this mode,no new network equipment and addressing schemes are demanded to be invented, so the advantage of the inheriting property of the CDC network is exerted. iii.The experiment as well as the one in previous subsection illustrates the advantage of the CDC network having consolidation property. iv. Controller coordination mechanisms are needed to help the SDN controllers in the edge networks to communicate with each other and share related data, which is left as future work.

5.4 Performance evaluation

To evaluate the performance, experiments have been made to compare between the CDC mode and the standard TCP/IP mode. We use RTT and TCP throughput as the metric.When measure the value of CDC mode, we use the same configurations as in §5.1. And then we replace the OpenFlow software switches (deployed in the OFSs and OFGs in figure 7) to a simple IP forwarding program to measure the value of TCP/IP mode.

We deploy UDP-ping client and server to the host A1 in ESN1 and the host B1 in ESN2 respectively. In each circumstance, 1000 samples are gathered. The result CDFs are shown in figure 8. As we can see, no matter small packet size or long packet size, there’s no distinct difference between these two modes.

The TCP throughput of the end-to-end system in the Gigabit wired linkage environment is also measured by using Iperf [27] which is a commonly used tool to measure bandwidth.Figure 9shows the throughput of TCP flows in the two circumstances. Same as the RTT comparison results, there’s no distinct difference between these two modes.

Summary: the CDC mode has little performance impact compared to TCP/IP mode while providing great flexibility.

5.5 Discussion

The prototype system we implemented, including both the traditional TCP/IP application subsystem and the ICN-like subsystem,is quite preliminary. However with these examples, we demonstrated that the CDC architecture mode which follows the three basic principles proposed in section 3 has the potential to solve the problems we must face when rebuilding the Internet: i.Inheriting problem:the new architecture should inherit precious legacy from the existing Internet applications and hardware (traditional application can be deployed on CDC); ii.Evolvability problem:the new architecture should adapt to the uncertain requirements of future applications,and does not need to reinvent the network architecture again and again (CDC mode can accommodate but not limited to ICN-like architectures); iii.Consolidation problem:heterogeneous architectures may coexist (the traditional TCP/IP architecture and the new ICN architecture coexisted in the same CDC prototype system); iv.Scalability problem: the CDC mode demands lots of SDN networks lie in the edge of the network, and each SDN network must accommodate limited hosts, so the scalability of CDC mode is excellent although the CDC edge networks face the same scalability problems as normal SDN does. It takes the advantage of processing flexibility of SDN and data transmission efficiency of IP to solve these problems, and thus proves the feasibility of the CDC mode. These demos can provide a useful reference when designing new network architectures. In future work, a large scale experiment environment should be constructed, and the performance of such architecture should be verified further.

Fig. 8. Round trip time comparisons.

Fig. 9. TCP throughput comparison.

VI. CONCLUSION

The existing schemes of the future networks lack an integrated direction of development and well defined network architectures, which seriously hinders the healthy development of the future networks. This paper fully takes advantage of the characteristics of both SDN and IP architecture, and integrates SDN into TCP/IP architecture carefully. We propose three principles that the future Internet should obey to be well-defined network architecture and argue that the CDC mode network can support the inheriting, evolvability and consolidation principles and excavate huge potential of SDN. As an ongoing work, we will focus on some particular mechanisms in CDC mode such as controller coordination mechanism,and study how CDC mode is applied in new mechanisms of network security, resource management and mobility and other aspects,to develop new network systems and equipment that better support scalability, security and mobility.

ACKNOWLEDGEMENT

This research was supported in part by the National Natural Science Foundation of China under Grant No. 61402521, Jiangsu Province Natural Science Foundation of China under Grant No. BK20140068, the China Post-Doctoral Science Foundation under Grant No.2017M610286.

[1] L. Zhang, A. Afanasyev, J. Burke et al, “Named data networking”, SIGCOMM Comput. Commun.Rev. 44 (3) (2014), pp. 66-73.

[2] Q.Wu, Z. Li, J. Zhou et al, “Sofia: toward service-orientedinformation centric networking”,Network, IEEE 28 (3) (2014), pp12-18.

[3] D. Han, A. Anand, F. Dogar et al, “Xia: Efficient support for evolvable internetworking”, Proc.NSDI, 2012, pp. 309-322.

[4] D. Raychaudhuri, K. Nagaraja, A. Venkataramani,“Mobilityfirst: A robustand trustworthy mobility-centric architecture for the future internet”,SIGMOBILE Mob. Comput. Commun. Rev. 16 (3)(2012), pp. 2-13.

[5] M. S. Blumenthal, D. D. Clark, “Rethinking the design of the internet:The end-to-end arguments vs. the brave new world”, ACM Trans.InternetTechnol. 1 (1) (2001), pp. 70-109.

[6] N. McKeown, T. Anderson, H. Balakrishnan et al,“Open flow: Enabling innovation in campus networks”, SIGCOMM Comput. Commun. Rev. 38 (2)(2008), pp. 69-74.

[7] P. Bosshart, G. Gibb, H.-S. Kim et al, “Forwarding metamorphosis: Fast programmable match-action processing in hardware for sdn”, Proc. SIGCOMM, 2013, pp. 99-110.

[8] N. Foster, R. Harrison, M. J. Freedman et al, “Frenetic: A network programming language”, Proc.ICFP, 2011, pp. 279-291.

[9] T. Koponen, M. Casado, N. Gude et al, “Onix: A distributedcontrol platform for large-scale production networks”, Proc. OSDI, 2010, pp. 1-6.

[10] S. Jain, A. Kumar, S. Mandal et al, “B4: Experience with a globally-deployed software defined wan”, Proc. SIGCOMM, 2013, pp. 3-14.

[11] International computer science institute activity report 2010. URL http://www.icsi.berkeley.edu/pubs/icsi/2010AnnualReport.pdf

[12] S. Ratnasamy, S. Shenker, S. McCanne, “Towards an evolvable internetarchitecture”, Proc. SIGCOMM, 2005, pp. 313–324.

[13] A. Ghodsi, S. Shenker, T. Koponen et al, “Intelligent design enables architectural evolution”,Proc. HotNets-X, 2011, pp. 3:1-3:6.

[14] Content centric networking.URL http://www.ccnx.org

[15] T. Koponen, M. Chawla, B.G. Chun et al. “Stoica,A data-oriented (and beyond) network architecture”, Proc. SIGCOMM, 2007, pp. 181-192.

[16] T. Koponen, S. Shenker, H. Balakrishnan et al,“Architecting for innovation”, SIGCOMM Comput.Commun. Rev. 41 (3) (2011), pp. 24-36.

[17] M. Casado, T. Koponen, S. Shenker et al, “Fabric:A retrospective on evolving sdn”, Proc. HotSDN,2012, pp. 85-90.

[18] N. Gude, T. Koponen, J. Pettit et al, “Nox: Towards an operating system for networks”, SIGCOMM Comput. Commun. Rev. 38 (3) (2008), pp.105–110.

[19] M. Yu, J. Rexford, M. J. Freedman et al, “Scalable flow-based networking with difane”, Proc. SIGCOMM, 2010, pp. 351-362.

[20] T. Koponen, K. Amidon, P. Balland et al, “Network virtualization in multi-tenant datacenters”, Proc.NSDI, 2014, pp. 203-216.

[21] M. K. Mukerjee, D. Han, S. Seshan et al, “Understanding tradeoffsin incremental deployment of new network architectures”, Proc. CoNEXT,2013, pp. 271-282.

[22] S. Vissicchio, L. Cittadini, O. Bonaventure et al,“On the co-existence of distributed and centralized routing control-planes”, Proc. INFOCOM,2015, pp. 469-477.

[23] Information-centric networking research group.URL https://irtf.org/icnrg

[24] N. Fotiou, P. Nik, D. Trossen et al, “Developing Information Networking Further: From PSIRP to PURSUIT”, Proc. International Conference on Broadband Communications, Networks and Systems, 2010, pp. 1-13.

[25] T. Huang, F. R. Yu, C. Zhang et al, “A Survey on Large-Scale Software Defined Networking(SDN) Testbeds: Approaches and Challenges”,IEEE Communications Surveys & Tutorials, vol.19, no. 2 2017, pp. 891-917.

[26] Q. Chen, F. R. Yu, T. Huang et al, “An Integrated Framework for Software Defined Networking,Caching, and Computing”, IEEE Network, vol. 31,no. 3 May/June 2017, pp. 46-55.

[27] Tirumala A, Qin F, Dugan J et al. “Iperf: The TCP/UDP bandwidth measurement tool”. 2005,http://dast.nlanr.net/Projects.