TY - JOUR
T1 - OpenFlow
T2 - Meeting carrier-grade recovery requirements
AU - Sharma, Sachin
AU - Staessens, Dimitri
AU - Colle, Didier
AU - Pickavet, Mario
AU - Demeester, Piet
PY - 2013/3/15
Y1 - 2013/3/15
N2 - OpenFlow, initially launched as a technology-enabling network and application experimentation in a campus network, has a disruptive potential in designing a flexible network, fostering innovation, reducing complexity and delivering the right economics. This paper focuses on fault tolerance of OpenFlow to deploy it in carrier-grade networks. The carrier-grade network has a strict requirement that the network should recover from the failure within a 50 ms interval. We apply two well-known recovery mechanisms to OpenFlow networks: restoration and protection, and run extensive emulation experiments. In OpenFlow, the controlling software is moved to one or more hardware modules (controllers) which can control many switches. For fast failure recovery, the controller must notify all the affected switches about the recovery action within ms interval. This leads to a significant load on the controller. We show that OpenFlow may not be able to achieve failure recovery within a 50 ms interval in this situation. We add the recovery action in the switches themselves so that the switches can do recovery without contacting the controller. We show that this approach can achieve recovery within 50 ms in a large-scale network serving many flows.
AB - OpenFlow, initially launched as a technology-enabling network and application experimentation in a campus network, has a disruptive potential in designing a flexible network, fostering innovation, reducing complexity and delivering the right economics. This paper focuses on fault tolerance of OpenFlow to deploy it in carrier-grade networks. The carrier-grade network has a strict requirement that the network should recover from the failure within a 50 ms interval. We apply two well-known recovery mechanisms to OpenFlow networks: restoration and protection, and run extensive emulation experiments. In OpenFlow, the controlling software is moved to one or more hardware modules (controllers) which can control many switches. For fast failure recovery, the controller must notify all the affected switches about the recovery action within ms interval. This leads to a significant load on the controller. We show that OpenFlow may not be able to achieve failure recovery within a 50 ms interval in this situation. We add the recovery action in the switches themselves so that the switches can do recovery without contacting the controller. We show that this approach can achieve recovery within 50 ms in a large-scale network serving many flows.
KW - Carrier-grade
KW - OpenFlow
KW - Protection
KW - Restoration
UR - http://www.scopus.com/inward/record.url?scp=84875210283&partnerID=8YFLogxK
U2 - 10.1016/j.comcom.2012.09.011
DO - 10.1016/j.comcom.2012.09.011
M3 - Article
AN - SCOPUS:84875210283
SN - 0140-3664
VL - 36
SP - 656
EP - 665
JO - Computer Communications
JF - Computer Communications
IS - 6
ER -