Protocolo aplicado según técnicas de imagen

Handling failures in OpenFlow is a tricky task. Fast recovery can be achieved by separating the handling of failure in two consecutive steps:

1. A transient connectivity restoration performed by the switches themselves, pro- vided as a set of backup rules, allowing the traffic to be restored as fast as possible, possibly providing some policy guarantees;

2. A long-term optimization problem left for the controller, to compute the new network state given the current set of failed elements and the full network policies.

8.4. CONCLUSION 55

As OpenFlow encourages to have one single control-plane element it also introduces another source of service disruption. The controller, as any software, can contains bugs eventually leading to crashes, and the connection it maintains with each switches can fail. Protecting this aspect of the protocol requires the usage of distributed con- trollers cooperating. Furthermore, as that same controller is also globally visible to the switches, it is important to reduce to a minimum the interactions it has with them, in order to avoid overloading it.

These are the key principles currently driving failure handling in OpenFlow. Another important one introduced by [36] is the separation of concerns while writing the con- troller, by cleanly separating all failure recovery code from the policies managmement one.

Part III

Preserving connectivity in

Hybrid networks

Chapter 9

Design of a robust hybrid SDN

architecture

IBSDN is an hybrid architecture in which an IGP and a SDN collaborate, in order to provide programmability in the network as well as effective and scalable failure handling. It brings resiliency in SDN’s against an arbitrary number of failures, without causing any overhead on the controller.

On one hand, failure recovery in networks is a critical component that heavily influences its performance. As shown in the previous parts, this is a subject that has been heavily studied in distributed routing protocols, and as such is now well-understood and efficiently dealt with. However, failure handling in the SDN paradigm is more scarce. Operators are required to define by themselves recovery mechanisms, and the overall resulting robustness of the network is directly constrained by both the size of the memory on the switches as well as the desired reaction time.

On the other hand, existing real-world networks are all using distributed routing protocols, tightly integrated with hardware equipments. This implies that the deploy- ment of SDN technologies in current network is likely to require both paradigm to co-exist in so called Hybrid networks [8].

IBSDN leverages the fact that hybrid networks have both a control-plane using dis- tributed routing protocols, as well as a SDN control-plane. It then uses the best-suited paradigm for each task to be achieved in the overall resulting control-plane. It as- signs the responsibility of traffic engineering to the SDN control-plane, as it brings more powerful tools for that purpose due to the fine-grained control it has over the forwarding tables across the whole network, and lets the distributed control-plane deal with the preservation of connectivity. It thus benefits from the 30+ years of researches performed in distributed routing paradigm to achieve scalable and robust fault man- agement, while still enabling the new use-cases brought by the SDN approach.

This chapter will focus on the general principles behind IBSDN, as well as the guaran- tees brought by its architecture. The next ones will detail an implementation of such network, as well as evaluate its overall performance and assess how it fares against the two main practices in SDN, namely the reactive or proactive approaches.

60 CHAPTER 9. DESIGN OF A ROBUST HYBRID SDN ARCHITECTURE

Figure 9.1: A high level view of the architecture of an IBSDN network

9.1

Architecture

IBSDN establishes a strict separation of concern when managing the network. It decouples the overall process of achieving optimal forwarding, which is assigned to a SDN control-plane, from the handling of failures, which is performed by an auxiliary IGP. As it uses concurrently the two network management technologies for specific purpose, IBSDN thus qualifies as a service-based hybrid SDN architecture [8].

From an high-level point of view, as illustrated on Fig. 9.1, IBSDN has two main components:

1. Network nodes running at the same time an SDN control protocol and a local agent which act as routing daemon for an IGP. This is why the routers on the Fig. 9.1 are represented as an aggregation of two datapaths, with one of them exchanging routing messages between the routers.

2. An IBSDN controller, that is in charge of both programming the FIB’s of the nodes, as well as configuring the IGP daemons on each node.

Conceptually, an IBSDN network is used similarly by the network operators than a standard SDN, as depicted on Fig. 9.1. Network operators will first specify to the IBSDN controller the policies that should be enforced in the absence of failures. These policies are the backbone of SDN routing, as they allow operators to specify arbitrary forwarding behavior, e.g. forcing some paths to go through some middleboxes [68].

From these primary policies, the controller will then computes the required FIB entries that should be present in the switches forwarding tables, in order to meet said policies. The controller will then install these rules in the switches, either pro-actively (thus programming static routing entries across the whole network) or reactively to the traffic entering the network (thus reacting to switches querying it because they received unknown data), which will be called primary rules.

In parallel to that, the controller will also configure the IGP daemons running on each node in order to have them starting to exchanging routing information via a link-state protocol. This will allow the local agents to compute their shortest-path tree, thus to build their Routing Information Base, independently form the IBSDN controller. This RIB is then kept on each node, separated from the FIB containing the primary rules, as it contains the forwarding rules enforced by the IGP, which are