In this paper, we describe and experimentally evaluate the performance of our Network Link Outlier Factor (NLOF) for detecting soft-failures in communication networks. The NLOF is computed using the throughput values derived from NetFlow records. The flow throughput values are clustered in two stages, outlier values are determined within each cluster, and the flow outliers are used to compute the outlier factor or score for each network link. When sampling NetFlow records across the full span of a network, NLOF enables the detection of soft-failures across the span of the network; large NLOF scores correlate well with links experiencing failure.
Software Defined Networking (SDN) is a new networking paradigm, with a great potential to increase network efficiency, ease the complexity of network control and management, and accelerate the rate of technology innovation. One of the core concepts of SDN is the separation of the network's control and data plane. The intelligence and the control of the network operation and management, such as routing, are removed from the forwarding elements (switches) and are concentrated in a logically centralised component, i.e. the SDN controller. In order for the controller to configure and manage the network, it needs to have up-to-date information about the state of the network, in particular its topology. Consequently, topology discovery is a critical component of any Software Defined Network architecture. In this paper, we evaluate the efficiency of the de facto standard approach to topology discovery currently implemented by the major SDN controller frameworks, and propose simple and practical modifications, which achieve a significantly improved efficiency and reduced control overhead. We have implemented our new topology discovery approach on the widely used POX controller platform, and have evaluated it for a range of network topologies via experiments using the Mininet network emulator as well as a specific topology in the OFELIA SDN testbed. Our results show that our proposed modifications achieve an up to 40 reduction in controller load compared to the current state-of-the-art approach, while delivering identical discovery functionality. Although Software-Defined Networking and its implementation OpenFlow facilitate managing networks and enable dynamic network configuration, recovering from network failures in a timely manner remains non-trivial. The process of (a) detecting the failure, (b) communicating it to the controller and (c) recomputing the new shortest paths may result in an unacceptably long recovery time. In this paper, we demonstrate that current solutions, employing both reactive restoration or proactive protection, indeed suffer long delays. We introduce a failover scheme with per-link Bidirectional Forwarding Detection sessions and preconfigured primary and secondary paths computed by an OpenFlow controller. Our implementation reduces the recovery time by an order of magnitude compared to related work, which is confirmed by experimental evaluation in a variety of topologies. Furthermore, the recovery time is shown to be constant irrespective of path length and network size.  This whitepaper proposes OpenFlow: a way for researchers to run experimental protocols in the networks they use every day. OpenFlow is based on an Ethernet switch, with an internal flow-table, and a standardized interface to add and remove flow entries. Our goal is to encourage networking vendors to add OpenFlow to their switch products for deployment in college campus backbones and wiring closets. We believe that OpenFlow is a pragmatic compromise: on one hand, it allows researchers to run experiments on heterogeneous switches in a uniform way at line-rate and with high port-density; while on the other hand, vendors do not need to expose the internal workings of their switches. In addition to allowing researchers to evaluate their ideas in real-world traffic settings, OpenFlow could serve as a useful campus component in proposed large-scale testbeds like GENI. Two buildings at Stanford University will soon run OpenFlow networks, using commercial Ethernet switches and routers. We will work to encourage deployment at other schools; and We encourage you to consider deploying OpenFlow in your university network too