Browse Prior Art Database

Recreating connection when connection to controller fails in OpenFlow system Disclosure Number: IPCOM000236638D
Publication Date: 2014-May-07
Document File: 8 page(s) / 92K

Publishing Venue

The Prior Art Database


Controllers lose the connection with openflow switches could be a disaster in openflow based networking. This is a solution that openflow switch may possibly recover the connection between the switch and openflow controller by means of it's neighbors. It's a very ligth-weighted and low cost solution. Keywords: openflow, secure-channel, SDN.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 01 of 8

Recreating connection when connection to controller fails in OpenFlow system

In OpenFlow system, if connections between switch and controller interrupted (artificial port unplugged, port broken, wrongly operation cause port shutdown etc.), switch will enter "fail secure mode" or "standalone mode (OpenFlow specification v1.3.1) or "emergency mode" (OpenFlow specification v1.0). But all of these modes, switch cannot recovery the connection itself unless human interference. In complex and large scale networking system, this kind of connection loss may lead very serious problem.

We find a solution that switch may be possible recovery the connection by it's neighbors' help. No complex configuration needed and no human interference.


For simplifying our solution, we setup a simple Openflow environment: one controller and 3 Openflow switches.

Assume all of controller and switches can support Openflow specification 1.3.1 which is the latest and mature specification for OpenFlow. This solution is also based on that specification (Can support Openflow specification 1.0 as well after some minimal change).


Page 02 of 8


Page 03 of 8


Controller and switch (which encounter connection interruption, here is switch A) should update their software to support this feature. No hardware change or other changes required. But we don't need neighbors (here are switch B and switch C) to support this feature.

In case of connection between controller and switch A interrupted, the following are the detailed process:

Emergency neighbor tunnel creation:
Switch A send emergency_connection_requirement message to neighbors (all it's openflow data ports, here only port

P1, P2 are active data ports). Packet format: DA = BPDU mac, SA = switch MAC. Information included in payload: Controller IP address, Switch IP address that used to connect to controller, emergency_port=P1(to switch B) or P2 (to switch C), DPID.

Neighbors(B and C) received the messages. This message cannot match any flow entries that existed in switch, so

switch B and C will package it into packet-in message...