|
E. Loop Detection Problem
The routing loops make packets never reach the final desti-
nation. In [110] it presents a dynamic algorithm which is built
on header space analysis, and allows the detection of loops
in SDNs. There the network model has been illustrated as a
directed graph. Hence, concepts of header space analysis has
been translated into the language of graph theory. Rule graphs
and the dynamic loop detection problem are studied in [110].
They have shown how to model a network as a directed graph.
By analyzing the reachability and connectivity of the topology
graph, a node-to-node, no-loop path can always be found. A
dynamic strongly connected component algorithm is proposed
in [110] to allow us to keep track of edge insertions and dele-
tions. It can also be used to detect loops in a routing path.
A comparison of all the above SDN security schemes is
presented in the tabular form below:
F. SDN Safety Issue: Failure Recovery
In order to build a trustworthy SDN, we need to make a SDN
resistant to both external failures (security issues) and internal
failures (safety issues) [146]. Here, external failures refer to ex-
ternal, intentional attacks by adversaries. The above discussed
security solutions aim to detect and overcome external attacks.
The internal failures refer to natural faults due to some system-
related shortcomings or unintentional human factors. We regard
those internal failures as safety issues. For example, a SDN
could fail if the communication link between the controller and
the switches has outages due to bandwidth unavailability. Thus
all controllers’ commands cannot be delivered to the switches’
flow tables. If the switch-to-switch path has link failure, many
packets can get lost. Therefore, some type of link quality
monitoring and path recovery schemes are needed to overcome
the link failure.
There could be many of other safety issues in a SDN. For
example, the controller may not be able to synchronously
update all switches’ flow tables due to schedule management
failure. The switch may not be able to timely report traffic
delivery status to the controller (thus the controller may not
update the flow table for quite a while). When using multiple
controllers in a SDN, the controllers may not be able to keep the
consistent control due to communication delay. In the following
discussion, we will illustrate some existing schemes that aim to
address the SDN safety issues.
In [104] a fast failure recovery scheme is proposed for
OpenFlow networks. It investigated the switch-over frequency
and packet loss rate in its evaluation. It uses NOX software to
recover services.
2198
IEEE COMMUNICATION SURVEYS & TUTORIALS, VOL. 16, NO. 4, FOURTH QUARTER 2014
In OpenFlow network we can immediately or proactively
add a flow entry to the table after a failure occurred. The total
recovery time is determined by the lifetime of the flow entries.
In [104] two values of timeouts are defined, one is called idle
timeout, which means the time interval that a flow entry should
be removed if not used for certain time (that is, no packet for
that type of flow entry is passing through a switch); the other
one is hard timeout, which is the maximum time interval that
a flow entry can stay. No matter which timeout occurs, it will
trigger the failure recovery.
Note that the system cannot be recovered if the controller has
no idea on what type of failure occurred. The controller may
just randomly add a flow entry in the table if the failure type
is not recognized. In [104] NOX has been used to implement
L2-learning scheme for failure detection. It is written in C++
(called L2-lerarning switch) or in Python (it is called L2-
learning Pyswitch).
If a failure occurs, the incorrect flow entries should be erased
from all switches, and new entries should be immediately added
to each switch. The controller should have robust schemes to
detect the failure, and find new routing path to deliver the flows.
The controller will check the old routing path associated with
the failed links. If the old path is still usable, it will not establish
a new path. Otherwise, new path needs to be added to the flow
entries and old entries should be removed immediately.
In [104] Ubuntu 9.04 is used to install Open vSwitch 1.1.0
and NOX 0.9.0. Over 10 K ping packets were sent out at
the pace of one packet every 10 ms. The packet loss rate is
calculated by counting the number of received ping packets.
Hard timeout is set to 20 seconds, and idle timeout is 10 s. The
routing loops are avoided by using spanning tree algorithms.
The path reestablishment scheme in [104] is faster than con-
ventional MAC re-convergence or ARP. It only uses 12 ms to
recover from a link failure.
In [105] a scheme is called Operations, Administration, and
maintenance (OAM) tool is used to re-establish a new path. To
minimize the path switching time, it uses a proactive approach,
that is, a backup path is pre-stored in the flow table in case
a path fails. This scheme makes path recovery time less than
50 ms. In addition, some probing packets are periodically sent
in the network. If it is not received by a node, the system knows
that a path failure occurs. If it takes a long time to receive the
probing packet, a failure is also detected. Thus [105] provides
an efficient way to recover from path failure.
VII. O
PEN
F
LOW FOR
W
IRELESS AND
O
PTICAL
N
ETWORKS
A. Overview
Do'stlaringiz bilan baham: | 
