FASTER CLUSTER CONVERGENCE AND LIVELINESS DETECTION THROUGH HIERARCHAL BIDIRECTIONAL FORWARDING DETECTION

Techniques are described herein for hierarchal Bidirectional Forwarding Detection (BFD) to scale liveliness detection. Scalability of BFD sessions to Master and Standby nodes is a concern in current implementations. A fast detection mechanism such as BFD is required to support fast detection of liveliness of cluster nodes

PROXY MONITORING OF SESSION STATE FOR SHARED FATE ENTITIES

By using a general protocol that allows for sharing of bidirectional forwarding detection (BFD) state across a shared path between neighboring routers, scale, simplicity and flexibility in designs may be achieved with at least a 2:1 ratio compared to a traditional implementation. Each participating node hosts BFD sessions that monitor a locally attached link and then shares the state of the BFD sessions to other neighboring nodes, effectively proxying the BFD state for consumption by participating devices in an efficient manner

Management of DiffServ-over-MPLS Transit Networks with BFD/OAM in ForCES Architecture †

Abstract. This paper proposes a management of DiffServ-over-MPLS transit network with BFD(Bidirectional Forwarding Detection)/OAM (operation, administration and maintenance) in ForCES (Forwarding and Control Element Separation) architecture for QoS-guaranteed DiffServ-over-MPLS traffic engineering. The proposed BFD and ForCES functions are implemented on Intel 2400 network processor, where BFD/OAM packets for MPLS TE-LSP are exchanged every 5 ~ 10 ms interval for performance measurements and link failure detection. The operations of BFD/OAM-based fault detection and performance measurement are controlled via distributed control plane with ForCES (forwarding and control element separation) architecture for large scale IP/MPLS router using multiple network processors in each network interface card. We explain the implementation details of ForCES-based distributed control plane functions, hierarchical traffic grooming with label stacking, and BFD/OAM mechanisms. The link failure detection performance of BFD/OAM functions for MPLS TE-LSP is evaluated

Link failure testing project on a satellite SDN network using Bidirectional Forwarding Detection

This project focuses on implementing a variable grid topology network for simulating an inter-satellite links connection to evaluate link failure detection times in a satellite SoftwareDefined Networking (SDN) using the Bidirectional Forwarding Detection (BFD) protocol (RFC 5880). Today, there is significant growth and deployment of LEO satellite networks, and SDN technology is being successfully used in these LEO satellite constellation networks due to the flexibility that this technology offers in the face of dynamic variation in topology network, limited bandwidth and traffic variations. An important point for the correct operation of these networks is the reliability and stability of the links that interconnect the satellites of the constellation, since this constellation is in permanent motion, orbiting the earth. The work developed in this project is directly related to this topic and the BFD detection protocol has been used to determine the connectivity failures of the test network links. The BFD is a protocol which provides fast forwarding path failure detection times and it is independent from physical media, routing protocols and data protocols. The BFD protocol works in the forwarding plane and is well suited for use with SDN switches. The testbed has been built using the "ContainerNet" Python API to implement the network topology and link interconnection of each satellite node. The satellite switching service is implemented in a docker instance, using OpenVirtualSwitch (OVS) as the internal packet switch of each node. OpenVirtualSwitch is an SDN-compliant programmable switching network device that has support for the BFD protocol. A transmission scenario is built on this switching network. This scenario includes two nodes that work as communication endpoints. The nodes have been configured so that between the endpoints there are two separate alternative paths. In addition to the datapath configuration, the BFD protocol has been configured to monitor the status of each link. A software developed running in all intermediate nodes are able to notify a link failure upstream of the datapath until the end nodes. An then end nodes can switch to another path. The final results must determine which are the BFD parameters to achieve a compromise between the BFD packet signaling period and the bandwidth used to keep the VoIP communication parameters within the acceptable limits in the event of a link failure with a route update

SPIDER: Fault Resilient SDN Pipeline with Recovery Delay Guarantees

When dealing with node or link failures in Software Defined Networking (SDN), the network capability to establish an alternative path depends on controller reachability and on the round trip times (RTTs) between controller and involved switches. Moreover, current SDN data plane abstractions for failure detection (e.g. OpenFlow "Fast-failover") do not allow programmers to tweak switches' detection mechanism, thus leaving SDN operators still relying on proprietary management interfaces (when available) to achieve guaranteed detection and recovery delays. We propose SPIDER, an OpenFlow-like pipeline design that provides i) a detection mechanism based on switches' periodic link probing and ii) fast reroute of traffic flows even in case of distant failures, regardless of controller availability. SPIDER can be implemented using stateful data plane abstractions such as OpenState or Open vSwitch, and it offers guaranteed short (i.e. ms) failure detection and recovery delays, with a configurable trade off between overhead and failover responsiveness. We present here the SPIDER pipeline design, behavioral model, and analysis on flow tables' memory impact. We also implemented and experimentally validated SPIDER using OpenState (an OpenFlow 1.3 extension for stateful packet processing), showing numerical results on its performance in terms of recovery latency and packet losses.Comment: 8 page

In-band control, queuing, and failure recovery functionalities for openflow

In OpenFlow, a network as a whole can be controlled from one or more external entities (controllers) using in-band or out-of-band control networks. In this article, we propose in-band control, queuing, and failure recovery functionalities for OpenFlow. In addition, we report experimental studies and practical challenges for implementing these functionalities in existing software packages containing different versions of OpenFlow. The experimental results show that the in-band control functionality is suitable for all types of topologies. The results with the queuing functionality show that control traffic can be served with the highest priority in in-band networks and hence, data traffic cannot affect the communication between the controller and networking devices. The results with the failure recovery functionality show that traffic can be recovered from failures within 50 ms