Huawei: Software-Defined Networking

Huawei: Software-Defined Networking

Executive Summary

Current core network devices, such as switches and routers, are complex and hard to configure. Network operators need to configure and issue vendor-specific commands in order to specify network policies. Moreover, the control plane (which makes decisions on how to handle traffic network) and the forwarding or data plane (which actually forwards data according to the control plane decisions) are bundled inside these network devices, reducing their flexibility [1]. Due to these features of current network devices, it is hard to innovate and perform relevant research on networking aiming to improve the Internet [2].

Software Defined Networking (SDN) is a new technology that aims to enable innovation and minimize vendor dependency in network core devices by separating data and control planes. With SDN, switches are just forwarding devices and all network decisions are taken by a centralized controller, external to the switches. Network devices communicate with controllers using APIs and specific protocols, such as OpenFlow. When the switch does not know how to handle a given packet it will ask to the controller, which can add or remove entries in the switches’ forwarding tables. The main benefits of SDN adoption are [9] centralized control of multivendor environments, reduced complexity through automation, higher rate of innovation, increase in network reliability and security, and more granular network control.

Several studies are ongoing in academia and industry due to the SDN potential in many computational areas [4–6]. Big players (such as Brocade, Cisco, Dell, Huawei, etc) are adopting SDN in their products, which indicates that SDN is a short-term trend for computer networks. Some of the main research areas in SDN are [9] are switch design, controllers platforms, resilience and scalability, performance evaluation, security and dependability, and SDN for telecom and cloud computing.

SDN can then be considered an extensible open source networking control system that allows applications to control the data plane composed of network hardware through a set of standard application programming interfaces (APIs). It effectively pulls network intelligence out of the network devices and places it in the hands of an external, centralized controller. SDN-based network operations thus promises to allow the control of networking resources via APIs. Benefits include, among others, a significantly simplified integration and automation of large-scale enterprise infrastructures.

A key use case for SDN is the joint orchestration of computing, storage and network resources on a globally distributed environment, by providing cloud-based services and virtualizing the network to more simply manage interconnections of resources installed either in a local area network or in distributed datacenters. The possibility of issuing such a joint orchestration is seen as one of the most important applications for an SDN-based network.

Figure 2 shows a broad view of the architecture we are planning to deploy. To enable the joint orchestration of computing, storage and network resources, we plan to interwork one or more SDN controllers (OpenDayLight and/or a newer one to be developed in the context of the project) with a cloud computing controller (OpenStack). OpenStack offers a networking module with a plugin mechanism to connect different network controllers. This cloud orchestration enables a dynamic interworking between three datacenters -- Unesp, Caltech, CERN -- and the WANs interconnecting them. This can be used to offer bandwidth on-demand services, large bulk data transfers between high-end storage servers (data transfer nodes in our terminology), or live transfer of virtual machines.

OpenDaylight is a Java-based SDN controller built to provide a comprehensive network programmability platform for SDN. It was created as a Linux Foundation collaborative project in 2013 and intends to build a complete framework for enabling innovation in SDN environment. Another component shown on Figure 2 is FlowVisor, a middleware between the OpenFlow controllers and the OpenFlow switches. FlowVisor can be used to creates slices of network resources and acts as the controlling proxy of each slice to different controllers. Slices may be switch ports, Ethernet addresses, IP addresses, etc, and they are isolated and cannot control other traffic. It can dynamically manage these slices and distribute them to different OpenFlow controllers, and enables different virtual networks to share the same physical network resources. FlowVisor is one of the early technologies to enable network virtualization in SDN. Its basic idea is to allow multiple logical networks share the same OpenFlow networking infrastructure.

Both OpenFlow and FlowVisor have their limitations in terms of network management, flexibility, isolation and QoS. OpenFlow offers common instructions, but lacks standard management tools. FlowVisor only has access to the data plane, so the control plane and network controllers have to be managed by the users of the infrastructure. In the same way, Neutron, the network component of OpenStack, still needs a series of improvements to work properly in this scenario.

There are thus a lot of strategic R&D opportunities that can be explored in this scenario, as there are many gaps in the current applications, protocols, and tools. An important aspect that should be considered in deploying such an SDN-based cloud orchestration system is interoperability, which can only be achieved by developing and using open and standardized APIs.

We plan to work together with leading Research & Education networks and network providers, including ANSP, RNP, AmLight, Internet2, and NorduNet (this later one peers with AmLight in Miami). By working with them we should be able to establish dynamic circuits and assign flows to them with bandwidth guarantees among the three sites with pre-defined priorities according to the experiment. We should follow closely the Caltech HEP engineering and development team and their partners like ESnet, Fermilab, StarLight/iCAIR and other key laboratories on the development of open-source products and methods in the SDN, virtualization and global system operation and optimization areas. The services to be developed are intended to interface seamlessly to the adaptive network operating system being developed by ESnet, Fermilab, Caltech and others, to ensure that authorized applications achieve full throughput.

[1] J. Turner and D. Taylor, “Diversifying the internet,” in Global Telecommunications Conference, 2005. GLOBECOM ’05. IEEE, vol. 2, pp. 6 pp.–760, Dec 2005.

[2] T. Anderson, L. Peterson, S. Shenker, and J. Turner, “Overcoming the internet impasse through virtualization,” Computer, vol. 38, pp. 34–41, April 2005.

[3] D. Kreutz, F. M. V. Ramos, P. Esteves Verissimo, C. Esteve Rothenberg, S. Azodolmolky, and S. Uhlig, “Software-defined networking: A comprehensive survey,” Proceedings of the IEEE, vol. 103, pp. 14–76, Jan. 2015.

[4] K. Govindarajan, K. C. Meng, H. Ong, W. M. Tat, S. Sivanand, and L. S. Leong, “Realizing the quality of service (qos) in software-defined networking (sdn) based cloud infrastructure,” in Information and Communication Technology (ICoICT), 2014 2nd Interna- tional Conference on, pp. 505–510, May 2014.

[5] S. Baucke, R. Ben Ali, J. Kempf, R. Mishra, F. Ferioli, and A. Carossino, “Cloud atlas: A software defined networking abstraction for cloud to wan virtual networking,” in Cloud Computing (CLOUD), 2013 IEEE Sixth International Conference on, pp. 895–902, June 2013.

[6] P. Rad, R. Boppana, P. Lama, G. Berman, and M. Jamshidi, “Low-latency software defined network for high performance clouds,” in System of Systems Engineering Conference (SoSE), 2015 10th, pp. 486–491, May 2015.