The Internet has led to the creation of a digital society, where (almost) everything is connected and is accessible from anywhere. However, despite their widespread adoption, traditional IP networks are complex and very hard to manage. It is both difficult to configure the network according to predefined policies, and to reconfigure it to respond to faults, load, and changes. To make matters even more difficult, current networks are also vertically integrated: the control and data planes are bundled together. Software-defined networking (SDN) is an emerging paradigm that promises to change this state of affairs, by breaking vertical integration, separating the network's control logic from the underlying routers and switches, promoting (logical) centralization of network control, and introducing the ability to program the network. The separation of concerns, introduced between the definition of network policies, their implementation in switching hardware, and the forwarding of traffic, is key to the desired flexibility: by breaking the network control problem into tractable pieces, SDN makes it easier to create and introduce new abstractions in networking, simplifying network management and facilitating network evolution. In this paper, we present a comprehensive survey on SDN. We start by introducing the motivation for SDN, explain its main concepts and how it differs from traditional networking, its roots, and the standardization activities regarding this novel paradigm. Next, we present the key building blocks of an SDN infrastructure using a bottom-up, layered approach. We provide an in-depth analysis of the hardware infrastructure, southbound and northbound application programming interfaces (APIs), network virtualization layers, network operating systems (SDN controllers), network programming languages, and network applications. We also look at cross-layer problems such as debugging and troubleshooting. In an effort to anticipate the future evolution of this new paradigm, we discuss the main ongoing research efforts and challenges of SDN. In particular, we address the design of switches and control platforms—with a focus on aspects such as resiliency, scalability, performance, security, and dependability—as well as new opportunities for carrier transport networks and cloud providers. Last but not least, we analyze the position of SDN as a key enabler of a software-defined environment.

https://publications.uni.lu/bitstream/10993/20596/1/survey_on_SDN.pdf

Software-Defined Networking: A Comprehensive Survey

Software-Defined Networking (SDN) is an emerging paradigm that promises to change this state of affairs, by breaking vertical integration, separating the network's control logic from the underlying routers and switches, promoting (logical) centralization of network control, and introducing the ability to program the network. The separation of concerns introduced between the definition of network policies, their implementation in switching hardware, and the forwarding of traffic, is key to the desired flexibility: by breaking the network control problem into tractable pieces, SDN makes it easier to create and introduce new abstractions in networking, simplifying network management and facilitating network evolution. In this paper we present a comprehensive survey on SDN. We start by introducing the motivation for SDN, explain its main concepts and how it differs from traditional networking, its roots, and the standardization activities regarding this novel paradigm. Next, we present the key building blocks of an SDN infrastructure using a bottom-up, layered approach. We provide an in-depth analysis of the hardware infrastructure, southbound and northbound APIs, network virtualization layers, network operating systems (SDN controllers), network programming languages, and network applications. We also look at cross-layer problems such as debugging and troubleshooting. In an effort to anticipate the future evolution of this new paradigm, we discuss the main ongoing research efforts and challenges of SDN. In particular, we address the design of switches and control platforms -- with a focus on aspects such as resiliency, scalability, performance, security and dependability -- as well as new opportunities for carrier transport networks and cloud providers. Last but not least, we analyze the position of SDN as a key enabler of a software-defined environment.

We present our experiences to date building ONOS (Open Network Operating System), an experimental distributed SDN control platform motivated by the performance, scalability, and availability requirements of large operator networks. We describe and evaluate two ONOS prototypes. The first version implemented core features: a distributed, but logically centralized, global network view; scale-out; and fault tolerance. The second version focused on improving performance. Based on experience with these prototypes, we identify additional steps that will be required for ONOS to support use cases such as core network traffic engineering and scheduling, and to become a usable open source, distributed network OS platform that the SDN community can build upon.

/pdf/onos-towards-an-open-distributed-sdn-os-25228im0dz.pdf

ONOS: towards an open, distributed SDN OS

Network slicing has been identified as the backbone of the rapidly evolving 5G technology. However, as its consolidation and standardization progress, there are no literatures that comprehensively discuss its key principles, enablers, and research challenges. This paper elaborates network slicing from an end-to-end perspective detailing its historical heritage, principal concepts, enabling technologies and solutions as well as the current standardization efforts. In particular, it overviews the diverse use cases and network requirements of network slicing, the pre-slicing era, considering RAN sharing as well as the end-to-end orchestration and management, encompassing the radio access, transport network and the core network. This paper also provides details of specific slicing solutions for each part of the 5G system. Finally, this paper identifies a number of open research challenges and provides recommendations toward potential solutions.

/pdf/network-slicing-and-softwarization-a-survey-on-principles-1kehpns3y8.pdf

Network Slicing and Softwarization: A Survey on Principles, Enabling Technologies, and Solutions

The Internet is evolving rapidly toward the future Internet of Things (IoT) which will potentially connect billions or even trillions of edge devices which could generate huge amount of data at a very high speed and some of the applications may require very low latency. The traditional cloud infrastructure will run into a series of difficulties due to centralized computation, storage, and networking in a small number of datacenters, and due to the relative long distance between the edge devices and the remote datacenters. To tackle this challenge, edge cloud and edge computing seem to be a promising possibility which provides resources closer to the resource-poor edge IoT devices and potentially can nurture a new IoT innovation ecosystem. Such prospect is enabled by a series of emerging technologies, including network function virtualization and software defined networking. In this survey paper, we investigate the key rationale, the state-of-the-art efforts, the key enabling technologies and research topics, and typical IoT applications benefiting from edge cloud. We aim to draw an overall picture of both ongoing research efforts and future possible research directions through comprehensive discussions.

Future Edge Cloud and Edge Computing for Internet of Things Applications

CORD is a new design of a telco central office that replaces closed and proprietary hardware with software running on commodity servers, switches, and access devices. It allows network operators to benefit from both the economies of scale (infrastructure constructed from a few commodity building blocks) and agility (the ability to rapidly deploy and elastically scale services) that commodity cloud providers enjoy today. This article introduces the CORD architecture and describes an open reference implementation of CORD that is available for evaluation.

Central office re-architected as a data center

Virtualized environments have been around for a long time, but until recently these have focused solely on compute virtualization and left the network behind. Network virtualization enables multiple tenants to share the same physical infrastructure by decoupling the physical network from the virtual network. In this paper, we introduce OpenVirteX, a Network Virtualization Platform which provides virtual Software Defined Networks (vSDNs). Each vSDN is customizable in terms of topology as well as addressing scheme. Introduction. Techniques for virtualizing network infrastructure have lagged behind that of compute resource virtualization. This has hampered the ability of operators to provide full virtualization that extends down to the network. In the ideal case, operators would be able to provide networks whose topologies, management schemes, and use cases are under the full control of their tenants. Realization of this scheme requires the ability to construct virtual networks that are not only logically isolated, but also have fully configurable topologies and properties akin to virtual machines, e.g., can be created, destroyed, snapshotted, and migrated on demand. Such a mechanism would provide operators with the ability to give a tenant the illusion that they have full control of topology, addressing, and management of the infrastructure despite sharing it with other tenants. Here we present OpenVirteX, a network hypervisor that enables operators to provide this form of network virtualization to their customers. We leverage the growing focus on Software Defined Networks (SDN) amongst infrastructure providers aiming to simplify and add flexibility to the process of provisioning networks. In specific, OpenVirteX builds on OpenFlow [1] as the SDN medium, and our experiences with FlowVisor [2] for design. Like FlowVisor, OpenVirteX functions as a proxy within the control channel, presenting OpenFlow networks to tenants, while controlling the underlying physical infrastructure via the southbound OpenFlow interface. Figure 1 depicts this architecture. By exposing OpenFlow networks, OpenVirteX allows tenants to use their own network OS (NOS) to control the network resources corresponding to their virtual network. In other words, OpenVirteX creates multiple virtual software defined networks out of one. Unlike FlowVisor, which simply slices the entire flowspace amongst the tenants, OpenVirteX provides each tenant with a fully virtualized network featuring a tenant-specified topology and a full header space. Motivation. OpenVirteX offers a pragmatic approach to meeting the requirements of both operators and tenants in increasingly common computing situations: • Cloud: OVX facilitates the migration of an enterprise to a Cloud Infrastructure. Each customer can request an exact copy of his/her physical network, with the same address scheme and topology of the current network. The level of abstraction offered by OpenVirteX creates the illusion that the Cloud physical infrastructure fits exactly the client requirements, in terms of isolation, topology and addressing scheme. • Provider: Similarly, in a WAN scenario, virtualization is essential, e.g. to allow multiple enterprises to connect their remote sites. With OVX, this could be done easily, spawning virtual networks that provide inherited traffic isolation, security, and flexibility. Moreover, with OpenVirteX, the tenant can still control how traffic is forwarded inside his network through a NOS and can apply policies (e.g. firewall, load balancer) that in a standard network are completely managed by the ISP. The remainder of this abstract describes the virtualization approach taken by OpenVirteX, and its current state. Topology Virtualization. OpenVirteX maintains internal representations of the physical and virtual networks as a collection of software switches, links, and end hosts. The physical topology representation is the basis upon which virtual networks are mapped. Tenants can request a topology by supplying a mapping between the elements in the physical topology and their desired virtual network. Virtual topologies can range from an exact copy or subset of the physical network, over a giant virtual switch that abstracts away all physical switches and links, to any custom topology as described by the tenant. The ability to control topology abstraction allows tenants to simplify their NOS, or operators to implement policies in the network. For example, a tenant may forego loop resolution in their NOS by requesting a loop-free topology, or an operator can require traffic to pass through chosen nodes by modifying the connecting path of a virtual link or between the ports of a giant switch. The mapping between virtual and physical elements are stored in a global map, but otherwise kept separate. This allows tenant networks to be reconfigured, halted, and re-initialized by simply modifying this mapping, i.e. pointing keys to different values. Finally, since virtual topologies need not correspond to the physical network, resilience can be enabled in the former Fig. 1: Network virtualization with OpenVirteX. Fig. 2: The address virtualization process. by allowing tenants to specify multiple backup paths for any virtual links between switches, or within giant switches, between ports. Address Virtualization. OpenVirteX grants tenants the ability to choose address assignments for their end hosts, allowing multiple, potentially-overlapping IP address blocks to exist in the same physical network. To differentiate hosts, OpenVirteX generates globally unique tenant IDs for each tenant, and for each host, a physical IP addresses that encodes the host’s membership using the tenant ID. Collisions of addresses are avoided by installing flow rules to rewrite addresses at the edge switches of the network, from tenant-assigned address to physical IP address at the ingress edge, and vice-versa at the egress edge. The translation process is illustrated in Figure 2. Importantly, this procedure is invisible to a tenant’s NOS or hosts, implying that a NOS used to control a virtual network created by OpenVirteX doesn’t need to be modified in any way to properly function. In addition to preventing address aliasing in a transparent way, the mapping created by the procedure is used by OpenVirteX to demultiplex northbound control messages so that they reach the correct tenant networks. Control Function Virtualization. Each virtual network may run its own NOS to program the virtual switches. OpenVirteX makes this possible by mapping various control functions for the virtual network on to the corresponding physical network resources. The translations can get complex, since an operation for one virtual switch may map onto multiple switches and links in the physical network. OpenVirteX leverages its position as proxy that allows it to intercept and manipulate the control packets before they reach their intended destination, which OpenVirteX also determines based on its virtual-physical mapping. Implementation. We have implemented a preliminary version of OpenVirteX in Java. This version currently supports OpenFlow 1.0, and supports the creation of custom topologies under overlapping IP address spaces, the ability to start and stop virtual networks and their components, and persistent storage using Mongo DB. Backup paths for resilient links and giant switches can be manually configured, or automatically generated with a simple SPF algorithm. A JSONRPC API is provided to enable configuration and monitoring of both tenant and infrastructure networks. This API has been used for an implementation of a GUI, as well as a topology embedder that generates virtual-physical mappings as configurations to OpenVirteX. Currently on-going work includes the addition of features such as virtual network snapshotting and migration, dynamic configuration of virtual networks, and external and inter-tenant connectivity. In the future topics such as HA and scalability may be explored.

/pdf/openvirtex-a-network-hypervisor-2yf5a7qvq1.pdf

OpenVirteX: A Network Hypervisor

Summary
Network virtualization (NV) technologies have attracted a lot of attention as an essential solution for future networking infrastructure. The NV enables multiple tenants to share the same physical infrastructure and to create independent virtual networks (VNs) by decoupling the physical network in terms of topology, address, and control functions. One feasible way to realize full NV involves considering solutions based on the software-defined networking (SDN) paradigm using its programmability. The SDN contributes many benefits to both network operations and management including programmability, agility, elasticity, and flexibility. There are several SDN-based NV solutions; however, they suffered from a lack of scalability, high availability. Also, they have high latency between control and data plane because of proxy-based architecture. In this thesis, we introduce a new NV platform, named Open Network Hypervisor (ONVisor). The design objectives include, among the features, (1) multitenancy, (2) scalability, (3) flexibility, (4) isolated VNs, and (5) VN federation. ONVisor was designed and implemented by extending Open Network Operating System, an open-source SDN controller. The main features of ONVisor are (1) isolated control and data plane per VN, (2) support of distributed operations, (3) extensible translators, (4) on-platform VN application development and execution, and (5) support of heterogenous SDN data-plane implementations. Several experiments are conducted on various test scenarios in different test environments in terms of control and data plane performance compared to nonvirtualized SDN network. The results show that ONVisor can provide VNs a little bit lower control plane performance and similar data plane performance.

ONVisor: Towards a scalable and flexible SDN-based network virtualization platform on ONOS

Several Network Operating Systems (NOS) have been proposed in the last few years for Software Defined Networks; however, a few of them are currently offering the resiliency, scalability and high availability required for production environments. Open Networking Operating System (ONOS) is an open source NOS, designed to be reliable and to scale up to thousands of managed devices. It supports multiple concurrent instances (a cluster of controllers) with distributed data stores. A tight requirement of ONOS is that all instances must be close enough to have negligible communication delays, which means they are typically installed within a single datacenter or a LAN network. However in certain wide area network scenarios, this constraint may limit the speed of responsiveness of the controller toward network events like failures or congested links, an important requirement from the point of view of a Service Provider. This paper presents ICONA, a tool developed on top of ONOS and designed in order to extend ONOS capability in network scenarios where there are stringent requirements in term of control plane responsiveness. In particular the paper describes the architecture behind ICONA and provides some initial evaluation obtained on a preliminary version of the tool.

William Snow

Papers

ONOS: towards an open, distributed SDN OS

Central office re-architected as a data center

OpenVirteX: A Network Hypervisor

ONVisor: Towards a scalable and flexible SDN-based network virtualization platform on ONOS

ICONA: Inter Cluster ONOS Network Application