Software Defined Networking (SDN) - Architecture and role of OpenFlow
In our previous article, we had a good overview of SDN as a technology, why it’s needed, and how IT industry is adopting it. Now, let’s get a layer deeper, and understand SDN’s architecture and the role of the Openflow protocol in the implementation of the technology.
SDN broadly consists of three layers:
- Application layer
- Control layer
- Infrastructure layer
Let us try and understand these layers in bottom-to-up approach.
Infrastructure layer is composed of various networking equipment which forms underlying network to forward network traffic. It could be a set of network switches and routers in the data centre. This layer would be the physical one over which network virtualization would be laid down through the control layer (where SDN controllers would sit and manage underlying physical network).
Control layer is the land of control plane where intelligent logic in SDN controllers would reside to control network infrastructure. This is the area where every network vendor is working to come up with their own products for SDN controller and framework. Here in this layer, a lot of business logic is being written in controller to fetch and maintain different types of network information, state details, topology details, statistics details, and more.
Since SDN controller is for managing networks, so it must have control logic for real world network use-cases like switching, routing, L2 VPN, L3 VPN, firewall security rules, DNS, DHCP, and clustering. Several networking vendors and even open source communities are working on the implementation of these use-cases in their SDN controllers. Once they get implemented, these services expose their APIs (typically REST based) to the upper layer (Application layer), something which makes life easy for network administrators who then use apps on top of SDN controllers to configure, manage and monitor underlying network. Control layer lies in middle and it exposes two types of interfaces – Northbound and Southbound.
- Northbound interface: is meant for communication with upper, Application layer and would be in general realized through REST APIs of SDN controllers. Southbound interface: is meant for communication with lower, Infrastructure layer of network elements and would be in general realized through southbound protocols – Openflow, Netconf, Ovsdb, etc.
Application layer is open area to develop as much innovative application as possible by leveraging all the network information about network topology, network state, network statistics, etc. There can be several types of applications which can be developed like those related to network automation, network configuration and management, network monitoring, network troubleshooting, network policies and security. Such SDN applications can provide various end-to-end solutions for real world enterprise and data centre networks. Network vendors are coming up with their set of SDN applications. For example, Brocade has following very useful applications:
- Brocade Flow Optimizer
- Brocade Virtual router
- Brocade Network advisor
HPE is also one vendor having SDN App store which contains many SDN apps from different companies as well. For example:
- HPE Network Optimizer
- HPE Network protector
- HPE Network visualizer
- NEC UNC for HP SDN VAN Controller
- Aricent SDN Load balancer
- TechM smart flow steering
- TechM server load balancer
As we briefly touched Openflow in previous article, we would now cover details of southbound communication from control layer to infrastructure layer (network switches) through Openflow protocol.
Openflow has been instrumental in the revolution of SDN in the sense that it has been key to show-case separation of control plane from data plane. Openflow is the standard specification provided by Open Networking Foundation (ONF), and is evolving over the time with support for various requirements of current world networking. Current version of the Openflow protocol is 1.5.1.
Openflow is a protocol which gives standard specification for communication between SDN controller and network equipment (typically switches). It allows routing decisions to be taken by SDN controllers and let forwarding rules, security rules being pushed on switches in underlying network.
SDN controller and switches need to implement Openflow specifications so that they can understand common language of Openflow messages. To control network switches, SDN controller will push rules into switches so that they can take decision when network traffic hits them. Switches need to maintain such rules in Openflow table. As per Openflow, such rules are called ‘flows’ and they are stored in ‘flow tables’.
Broadly, flows carry three types of information:
- Match fields: they will define criteria to match packets based on their header fields – L2 (source destination ethernet addresses, VLAN ID, VLAN priority, etc.), L3 (IPv4/IPv6 source destination address, protocol type, DSCP, etc.), L4 fields (TCP/UDP/SCTP source destination port), ARP fields, ICMP fields, MPLS fields, etc.
- Actions: they will define what to do with a packet if it matched the criteria. Actions would be like drop, forward on some port of switch, modify packet (push/pop VLAN ID, push/pop MPLS label, increment/decrement IP TTL), forward to specific queue of port, etc.
- Counters: to keep track how many packets matched the flow
To be specific, flows contain some more information which can be checked further in Openflow specifications.
Openflow channel or connection is a setup between switch and controller so that controller can communicate with switch to configure, manage, and monitor it. As per Openflow spec, Openflow runs on TCP or TLS connection and controller listens for connection on 6653 port. Switch is expected to initiate the connection and should send connection request to controller.
Optionally, connection can be initiated from controller side as well, and for this case, switch will be in passive mode to listen for connection. Be it from any side, it would be normal TCP or TLS connection setup, once it is established, Openflow messages are exchanged over TCP or TLS connection. For example, below is command of open source Openflow virtual switch (OpenVswitch) to initiate TCP connection with controller:
ovs-vsctl set-controller <sampleBridgeName> tcp:192.168.56.101:6653
Here, 192.168.56.101 is controller IP and 6653 is controller port on which it would be listening for connection.
Openflow defines various messages to enable communication between switch and controller, including connection setup messages, configuration messages, get switch statistics messages, keep-alive messages, asynchronous events messages, error messages, experimenter messages, and more.
Let us understand briefly about Openflow messages:
- Once TCP connection is made, Openflow HELLO message is exchanged between both entities to negotiate Openflow version on which further communication will take place. It is needed as it may be possible that switch and controller are running on different Openflow version. Both will agree on highest version supported.
- After version negotiation is done, controller first sends Openflow Feature request message to mainly get the datapath ID of switch in response message and to determine what features switch supports.
- To configure switch to handle network traffic, Openflow messages like flow entries can be sent from controller. These are maintained in flow tables inside switches.
- To group flow entries, groups can be configured by controller through group messages that can be stored into group tables inside switches.
- To get statistics details from switch, Openflow messages like flow stats, port stats, queue stats, group stats, table stats, etc. can be sent from controller.
- To check connection aliveness, echo request and reply Openflow messages can be sent from either controller or switch.
- Asynchronous Openflow messages like flow rule removal from switch, configuration apply fail error from switch, port up/down status from switch, etc. can be sent from switch to update controller.
Till now, we have gone through SDN architecture, its layers and role of Openflow to realize SDN core principle to separate control plane from data plane. Now we need to see how controller would be able to use Openflow to configure and manage underlying network.
Basically, controller would need to implement some plugin code of Openflow by which it can send, receive and understand Openflow messages to and from Openflow switches in underlying network.
To configure Openflow switches, controller needs to push flow rules into Openflow tables of switches based on which the latter can handle network traffic hitting them. Openflow message for flow entries has large set of tuple fields for matching criteria (L2, L3, L4 fields, etc.) of packets coming from network, which altogether would help in configuring ACL rules, security policy rules, QoS rate limiting bandwidth rules, routing rules, port mirroring rules, and packet modification rules.
To monitor Openflow switches, Openflow provides various request and response messages to fetch switch and network statistics information and events messages to update controller about manual changes or failures occurred at switch side, including flow removed event, port status UP/DOWN changes, and more.
To perform some vendor specific tasks on Openflow switches, Openflow provides experimental messages wherein vendors have freedom to define message body and exchange custom information between controller and switches. That is how Openflow is being used by many SDN applications to provide solutions for easy network control and management.
This article is co-authored by Tarun Thakur.
References:
