92 4 Software-Defined Networks Principles and Applications
controller and no changes to the other switches in the network. In the
following, we describe our design choices and the protection metrics
in detail.
With the high requirements on network reliability, we need a
mechanism to improve the resilience of the connectivity between
the controller and the switches in a split architecture network. The
mechanism should meet the following requirements:
• The protection should resume the forwarding after a failure as
soon as possible. The existing IGP protocols such as OSPF and
IS-IS typically take several seconds to converge, which cannot meet
the sub-50 ms level of failure recovery time. One option is to rely
on the controller to detect the failures in switches or links using
some implicit mechanisms, for example, when hello messages are
not received by the controller from a switch. This method will
introduce a large delay in the network for failure detection and
service restoration.
• The decision of protection should be made locally and independently. Different from traditional network, the forwarding element
does not have a complete topology of the network. It only receives
forwarding rules from the controller. When losing the connectivity to the controller, the switch has to make the decision of failover
independently without any instructions from the controller. In other
words, there will only be a local change in the outgoing interface of
the affected switch. All other connections in the network will remain
intact.
• We should keep the forwarding element, that is, the switch, as simple as possible.
We denote a network of switches by a graph G = (V , E), where V
is the set of nodes (switches) in the network and E the set of bidirectional edges (links) between nodes. With this given topology, we want
to know at which node the controller should be deployed.
Our first assumption is that the network controller is in the same
physical network as the switches. That is, we want to use the existing
infrastructure of the network (i.e., existing links and switches) to connect the controller to all the switches in the network, as opposed to
using a separate infrastructure (by adding new links and switches in
the network) to connect the controller to the switches.
controller and no changes to the other switches in the network. In the
following, we describe our design choices and the protection metrics
in detail.
With the high requirements on network reliability, we need a
mechanism to improve the resilience of the connectivity between
the controller and the switches in a split architecture network. The
mechanism should meet the following requirements:
• The protection should resume the forwarding after a failure as
soon as possible. The existing IGP protocols such as OSPF and
IS-IS typically take several seconds to converge, which cannot meet
the sub-50 ms level of failure recovery time. One option is to rely
on the controller to detect the failures in switches or links using
some implicit mechanisms, for example, when hello messages are
not received by the controller from a switch. This method will
introduce a large delay in the network for failure detection and
service restoration.
• The decision of protection should be made locally and independently. Different from traditional network, the forwarding element
does not have a complete topology of the network. It only receives
forwarding rules from the controller. When losing the connectivity to the controller, the switch has to make the decision of failover
independently without any instructions from the controller. In other
words, there will only be a local change in the outgoing interface of
the affected switch. All other connections in the network will remain
intact.
• We should keep the forwarding element, that is, the switch, as simple as possible.
We denote a network of switches by a graph G = (V , E), where V
is the set of nodes (switches) in the network and E the set of bidirectional edges (links) between nodes. With this given topology, we want
to know at which node the controller should be deployed.
Our first assumption is that the network controller is in the same
physical network as the switches. That is, we want to use the existing
infrastructure of the network (i.e., existing links and switches) to connect the controller to all the switches in the network, as opposed to
using a separate infrastructure (by adding new links and switches in
the network) to connect the controller to the switches.