The SDN control plane

In Software-Defined Networking (SDN), forwarding decisions can use many packet header fields (from the link, network, and transport layers).

Because forwarding decisions can be based on arbitrary packet-header fields rather than only destination addresses, these forwarding devices are often referred to as SDN switches or packet switches rather than routers.

Characteristics of an SDN architecture

Characteristic	Description
Flow-based forwarding	SDN switches can forward packets based on multiple header fields in contrast, router-based forwarding primarily uses the destination IP address for forwarding decisions
Separation of data plane and control plane	data plane: consists of switches that forward packets according to "match plus action" rules control plane: consists of software and servers that create and manage those flow-table rules
Software-based network control	the SDN control plane is implemented in software this software runs on servers that are separate from the switches
Programmable network	network behavior can be changed through software rather than by manually configuring individual devices

SDN control plane

Components of the SDN control plane:

Component	Description	Image
Network-control applications	implement network policies and control logic use the APIs provided by the SDN controller to specify and control the data plane in the network devices
SDN controller (or network operating system)	maintains accurate network state information (links, switches, hosts, etc.) provides this information to network-control applications allows applications to monitor, configure, and control network devices

The SDN control plane is responsible for "the network's intelligence":

• computing flow-table entries
• updating flow tables when network conditions change (e.g., a link goes down)
• coordinating flow table entries at multiple switches to ensure consistent network-wide functionality

The switches execute the forwarding and packet-processing actions specified by those rules.

SDN controller

The SDN controller can be organized into three layers:

Layer	Details	Image
Northbound interface (APIs ans abstractions for network control apps)	exposes APIs to SDN network-control applications allows applications to query network state and specify policies or desired behavior supports event notifications when network state changes
Control plane core (network-wide distributed state management)	maintains a logically centralized view of network state includes the network state database / topology service tracks hosts, links, switches, topology, statistics, and other information needed for control decisions
Southbound interface (communication to/from controlled devices)	communication between the SDN controller and forwarding devices uses protocols such as OpenFlow, SNMP, NETCONF, gNMI, or P4Runtime devices report events and state information to the controller enables the controller to maintain an up-to-date view of the network

SDN controllers such as OpenDaylight and ONOS are logically centralized on purpose. They look like one central controller but are actually distributed across several machines, which makes them more scalable and reliable for network devices and control applications.

SDN vs. traditional per-router control

In SDN:

• components such as switches, controllers, and network control applications can be developed and provided by different vendors
• this contrasts with traditional networking, where each router contains all functionality in a single integrated product from one vendor

SDN enables greater flexibility and vendor independence:

• with SDN, an ISP can easily switch from least-cost routing to custom routing strategies: the controller only needs a software update to change forwarding behavior
• in traditional networks, similar changes require updating software on all routers, which can be difficult when routers come from different vendors

OpenFlow

The OpenFlow protocol is a southbound interface in Software-Defined Networking (SDN):

• it is used for communication between an SDN controller and a network switch (or other OpenFlow-capable device)
• it runs over a reliable TCP connection (default port 6653)

Important messages used by the controller to configure and control the SDN-controlled switch:

• configuration messages (OFPT_SET_CONFIG, OFPT_GET_CONFIG): read or modify switch configuration parameters
• flow modification (OFPT_FLOW_MOD): add, delete, or update flow table entries that define packet forwarding behavior
• statistics requests (OFPT_MULTIPART_REQUEST): retrieve flow, port, and switch statistics such as counters and state information
• packet out (OFPT_PACKET_OUT): instruct the switch to send a specific packet out of a selected port

Important messages used by the switch to report events or send packets to the controller:

• flow removed (OFPT_FLOW_REMOVED): indicates that a flow entry has been removed, typically due to timeout or replacement
• port-status (OFPT_PORT_STATUS): reports changes in port state, such as being added, deleted, or modified
• packet in (OFPT_PACKET_IN): sends packets from the switch to the controller when:
  1. no flow table entry matches the packet (table miss), so forwarding behavior is unknown
  2. a flow entry explicitly directs the switch to send matching packets to the controller (e.g., using the "send to controller" action)

Google has used SDN principles in its global infrastructure, including its private backbone network known as B4, which connects data centers worldwide. Early versions were influenced by OpenFlow concepts, although modern implementations extend beyond pure OpenFlow.