Analyzing the Openflowplugin Handshake Process in Opendaylight

With the rise of cloud computing, terms like SDN, NFV, and OpenFlow appear frequently, yet deep technical explanations are scarce. The author, a senior developer at NetEase Games, shares an in‑depth analysis of the Openflowplugin (version 0.6.2) handshake process used in Opendaylight.

Opendaylight serves as the underlying framework for the SDN control plane, supporting south‑bound plugins such as OpenFlow, NETCONF, OVSDB, and BGP. The Openflowplugin connects OpenFlow forwarding nodes to the controller.

Handshake Process Overview

When the SwitchConnectionProviderImpl.startup method runs, a Netty‑based TCP server is started. The server creates a Bootstrap / EventLoopGroup and sets a channel initializer ( TcpChannelInitializer.initChannel ).

Upon a switch connecting to the controller’s listening port (6633/6653), Netty invokes TcpChannelInitializer.initChannel , which performs the following steps:

Creates a ConnectionAdapterImpl that wraps the SocketChannel .

Calls ConnectionManagerImpl.onSwitchConnected , which registers three listeners on the ConnectionAdapterImpl : ConnectionReadyListenerImpl (handles connection readiness and triggers the handshake). OpenflowProtocolListenerInitialImpl (processes initial OpenFlow messages such as onHelloMessage ). SystemNotificationsListenerImpl (handles idle and disconnect events).

Sets up the Netty pipeline with appropriate ChannelHandler s.

Invokes ConnectionAdapterImpl.fireConnectionReadyNotification() to start the handshake.

The fireConnectionReadyNotification method launches a new thread that calls connectionReadyListener.onConnectionReady() . This method changes the connection context state to HANDSHAKING and creates a HandshakeStepWrapper that runs HandshakeManagerImpl.shake() .

Hello Exchange

If TLS is not present, the controller sends a Hello message via ConnectionAdapterImpl.hello() . The switch replies with its own Hello, which is processed by OpenflowProtocolListenerInitialImpl.onHelloMessage . Depending on whether the switch’s Hello contains a version bitmap, the handshake proceeds with either bitmap‑based or step‑by‑step version negotiation.

Feature Request and Barrier

After version negotiation, the controller requests switch features using the get‑features RPC (implemented by ConnectionAdapterImpl.getFeatures ). The response includes datapath ID, buffers, tables, capabilities, etc. Once features are obtained, HandshakeListenerImpl.onHandshakeSuccessful updates the connection context to WORKING , creates a DeviceInfoImpl , and sends a Barrier message to ensure all prior commands have been executed.

The Barrier’s successful callback triggers ContextChainHolderImpl.deviceConnected , which creates the ContextChainImpl for the switch, marking the end of the handshake and the beginning of the switch’s lifecycle within Openflowplugin.

Conclusion

The article demonstrates how the TCP channel initialization, listener registration, Hello exchange, version negotiation, feature retrieval, and Barrier message collectively establish a reliable OpenFlow handshake, with ConnectionAdapterImpl acting as the core abstraction for communication with the switch.