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

The idea of programmable networks has recently re-gained considerable momentum due to the emergence of the Software-Defined Networking (SDN) paradigm. SDN, often referred to as a ''radical new idea in networking'', promises to dramatically simplify network management and enable innovation through network programmability. This paper surveys the state-of-the-art in programmable networks with an emphasis on SDN. We provide a historic perspective of programmable networks from early ideas to recent developments. Then we present the SDN architecture and the OpenFlow standard in particular, discuss current alternatives for implementation and testing of SDN-based protocols and services, examine current and future SDN applications, and explore promising research directions based on the SDN paradigm.

/pdf/a-survey-of-software-defined-networking-past-present-and-6tt309ed7r.pdf

A Survey of Software-Defined Networking: Past, Present, and Future of Programmable Networks

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.

Mininet is a system for rapidly prototyping large networks on the constrained resources of a single laptop The lightweight approach of using OS-level virtualization features, including processes and network namespaces, allows it to scale to hundreds of nodes Experiences with our initial implementation suggest that the ability to run, poke, and debug in real time represents a qualitative change in workflow We share supporting case studies culled from over 100 users, at 18 institutions, who have developed Software-Defined Networks (SDN) Ultimately, we think the greatest value of Mininet will be supporting collaborative network research, by enabling self-contained SDN prototypes which anyone with a PC can download, run, evaluate, explore, tweak, and build upon

/pdf/a-network-in-a-laptop-rapid-prototyping-for-software-defined-27edokofdp.pdf

A network in a laptop: rapid prototyping for software-defined networks

Summary) The abstract should follow the structure of the article (relevance, degree of exploration of the problem, the goal, the main results, conclusion) and characterize the theoretical and practical significance of the study results. The abstract should not contain wording echoing the title, cumbersome grammatical structures and abbreviations. The text should be written in scientific style. The volume of abstracts (summaries) depends on the content of the article, but should not be less than 250 words. All abbreviations must be disclosed in the summary (in spite of the fact that they will be disclosed in the main text of the article), references to the numbers of publications from reference list should not be made. The sentences of the abstract should constitute an integral text, which can be made by use of the words “consequently”, “for example”, “as a result”. Avoid the use of unnecessary introductory phrases (eg, “the author of the article considers...”, “The article presents...” and so on.)

/pdf/ministry-of-education-and-science-of-the-russian-federation-7m2jn0xnm1.pdf

Ministry of Education and Science of the Russian Federation

Today's networks typically carry or deploy dozens of protocols and mechanisms simultaneously such as MPLS, NAT, ACLs and route redistribution. Even when individual protocols function correctly, failures can arise from the complex interactions of their aggregate, requiring network administrators to be masters of detail. Our goal is to automatically find an important class of failures, regardless of the protocols running, for both operational and experimental networks.

To this end we developed a general and protocol-agnostic framework, called Header Space Analysis (HSA). Our formalism allows us to statically check network specifications and configurations to identify an important class of failures such as Reachability Failures, Forwarding Loops and Traffic Isolation and Leakage problems. In HSA, protocol header fields are not first class entities; instead we look at the entire packet header as a concatenation of bits without any associated meaning. Each packet is a point in the {0,1}L space where L is the maximum length of a packet header, and networking boxes transform packets from one point in the space to another point or set of points (multicast).

We created a library of tools, called Hassel, to implement our framework, and used it to analyze a variety of networks and protocols. Hassel was used to analyze the Stanford University backbone network, and found all the forwarding loops in less than 10 minutes, and verified reachability constraints between two subnets in 13 seconds. It also found a large and complex loop in an experimental loose source routing protocol in 4 minutes.

/pdf/header-space-analysis-static-checking-for-networks-18uxbiwn8q.pdf

Header space analysis: static checking for networks

Network state may change rapidly in response to customer demands, load conditions or configuration changes But the network must also ensure correctness conditions such as isolating tenants from each other and from critical services Existing policy checkers cannot verify compliance in real time because of the need to collect "state" from the entire network and the time it takes to analyze this state SDNs provide an opportunity in this respect as they provide a logically centralized view from which every proposed change can be checked for compliance with policy But there remains the need for a fast compliance checker

Our paper introduces a real time policy checking tool called NetPlumber based on Header Space Analysis (HSA) [8] Unlike HSA, however, NetPlumber incrementally checks for compliance of state changes, using a novel set of conceptual tools that maintain a dependency graph between rules While NetPlumber is a natural fit for SDNs, its abstract intermediate form is conceptually applicable to conventional networks as well We have tested NetPlumber on Google's SDN, the Stanford backbone and Internet 2 With NetPlumber, checking the compliance of a typical rule update against a single policy on these networks takes 50-500µs on average

/pdf/real-time-network-policy-checking-using-header-space-4k85i69m18.pdf

Real time network policy checking using header space analysis

1 SLICED PROGRAMMABLE NETWORKS OpenFlow [4] has been demonstrated as a way for researchers to run networking experiments in their production network Last year, we demonstrated how an OpenFlow controller running on NOX [3] could move VMs seamlessly around an OpenFlow network [1] While OpenFlow has potential [2] to open control of the network, only one researcher can innovate on the network at a time What is required is a way to divide, or slice, network resources so that researchers and network administrators can use them in parallel Network slicing implies that actions in one slice do not negatively affect other slices, even if they share the same underlying physical hardware A common network slicing technique is VLANs With VLANs, the administrator partitions the network by switch port and all traffic is mapped to a VLAN by input port or explicit tag This coarse-grained type of network slicing complicates more interesting experiments such as IP mobility or wireless handover Here, we demonstrate FlowVisor, a special purpose OpenFlow controller that allows multiple researchers to run experiments safely and independently on the same production OpenFlow network To motivate FlowVisor’s flexibility, we demonstrate four network slices running in parallel: one slice for the production network and three slices running experimental code (Figure 1) Our demonstration runs on real network hardware deployed on our production network at Stanford and a wide-area test-bed with a mix of wired and wireless technologies

/pdf/carving-research-slices-out-of-your-production-networks-with-5aa0xzozdu.pdf

Carving research slices out of your production networks with OpenFlow

Networks are getting larger and more complex; yet administrators rely on rudimentary tools such as ping and traceroute to debug problems. We propose an automated and systematic approach for testing and debugging networks called "Automatic Test Packet Generation" (ATPG). ATPG reads router configurations and generates a device-independent model. The model is used to generate a minimum set of test packets to (minimally) exercise every link in the network or (maximally) exercise every rule in the network. Test packets are sent periodically, and detected failures trigger a separate mechanism to localize the fault. ATPG can detect both functional (e.g., incorrect firewall rule) and performance problems (e.g., congested queue). ATPG complements but goes beyond earlier work in static checking (which cannot detect liveness or performance faults) or fault localization (which only localize faults given liveness results).We describe our prototype ATPG implementation and results on two real-world data sets: Stanford University's backbone network and Internet2. We find that a small number of test packets suffices to test all rules in these networks: For example 4000 packets can cover all rules in Stanford backbone network while 54 is enough to cover all links. Sending 4000 test packets 10 times per second consumes less than 1% of link capacity. ATPG code and the data sets are publicly available1[1].

/pdf/automatic-test-packet-generation-52qvn7goho.pdf

Automatic test packet generation

Embodiments relate generally to network hardware, network software and methods for network management and testing. In some embodiments, state information (e.g., configuration data, forwarding states, IP tables, rules, network topology information, etc.) can be received from devices in a network. The state information can be parsed and used to generate a network model, which describes how data is processed by the network. Using the model, possible flow paths of data through the network can be identified and used to analyze the network and identify network behavior, such as types of traffic, frequency of rule matches, what kind of transformation occurs as traffic flows through the network, and where the traffic gets dropped, etc. Policies can be verified against the network model to ensure compliance, and in the event of non-compliance, a report or interface can indicate the cause and/or allow a user to explore specific details about the cause.

Peyman Kazemian

Papers

Header space analysis: static checking for networks

Real time network policy checking using header space analysis

Carving research slices out of your production networks with OpenFlow

Automatic test packet generation

Systems and methods for network management