SDN stands for 'Software Defined Networking'. SDN separates control decisions from packet forwarding and exposes programmable interfaces between these functions. Forwarding can remain in hardware, while software applications control network behavior through an abstraction. The change concerns control and programmability, rather than replacing every network component with software.

Then you may ask 'which part of Network will be replaced by Software in SDN ?' How ? and Why ?

Just keep these questions in mind and follow along following sections and the answer gradually emerge.

• What is the typical structure of current network ?
• How do we configure (change configure) in conventional (non-SDN) network ?
• What is problem with the current (conventional) way  ?
• How do we configure (change configure) in SDN network ?
• What is to be done to realize SDN ?
• How does a packet cross an SDN network ?
• What happens when the controller or a link fails ?
• Reference

What is the typical structure of current network ?

Before we talk of the new system (SDN), let's briefly think of how we implement and configure the network in current (conventional) way. The useful distinction is between selecting forwarding behavior and applying that behavior to packets.

In a very simple representation, a network can be represented as a lot of switches (routers) connected together to form a fishing net or spider web like architecture.

Each componet (Switch in this case) is made up of roughly two parts. One part is for forwarding a packets from a port to another port and the other part is for setting up various information/configuration that directs how those packets should be forwarded.

This is very simple (oversimplified in some aspect) description of the networking with current (conventional, non-SDN) switches/routers. Getting into a little bit further details, followings are considered as characterisfics of the network based on conventional switch/routers. Most of these are targets to be improved in the new network called SDN.

• Limited network-wide abstraction : Conventional devices often expose configuration through device-specific interfaces. Standard protocols and data models also exist, so abstraction is not entirely absent.
• Control-plane extensibility varies : Routing software can be modular, but operators may lack access to its internal programming interfaces. Deploying a new control function can therefore depend on device support.

The enlarged switch separates Configuration/Control from Forwarding HW. Both functions belong to the device in this simplified model. A control decision changes the tables; forwarding then uses those tables for arriving packets. This separation of responsibilities also helps explain the SDN architecture that follows.

• Control selects behavior : A routing decision and the forwarding of a packet are separate operations.
• Hardware can remain : Programmable control does not require a software-only forwarding implementation.
• Interfaces determine access : An operator needs a supported interface to change device behavior reliably.

How do we configure (change configure) in conventional (non-SDN) network ?

Now let's suppose that we need to change the configuration of a network to optimize it for a specific purpose or specific use model. Engineers can configure each device remotely through a command-line interface or a management protocol such as NETCONF. Physical visits are not a requirement of conventional networking.

The engineer icons represent separate device configuration tasks, rather than mandatory visits to physical sites. Remote access removes travel, but it does not coordinate the meaning of those changes. A management client can automate configuration retrieval and edits through NETCONF. Devices advertise capabilities, so the client must check support before using optional operations. See [7].

Consider an illustrative change that permits one department to reach a new application server. An engineer might change an access rule on one device and routing configuration on another. The commands can both succeed while the service remains unreachable because another device still blocks traffic. The useful test therefore follows the complete service path, including the return direction.

• Remote access is already possible : Device-by-device configuration can use software without requiring an SDN architecture.
• A service spans devices : A successful command on one switch does not prove complete connectivity.
• Capabilities need checking : The management client must account for differences in supported device operations.

What is problem with the current (conventional) way  ?

If they are only a few switches/routers that you need to reconfigure, there wouldn't be much problem. Or even if you need to reconfigure much more of them (like hundreds or thousands), that may be tolerable if it happens very seldom (like once or twice a year), but there are many cases where these kind of manual/local reconfiguration become impractical or almost impossible. Some of these cases would as follows (Most of these items are based on Ref [4]):

• What if you need to change several thousands or even more (approaching almost million in worst case) of network components (e.g, switch, routers or local servers) ?
• What if you need to change those configuration very often ? Several times even in a single day ?
• What if those network components are from different vendors ? (Each vendor has its own way of configuration method, different parameter set, different tools for configuring those component. So you need different group of tech people with specialized in different vendor's product)

You can see a couple of examples of this kind of problem with conventional network in the video (Around 5 min at the beginning of Ref [5])

For example, a partial policy update can leave two switches enforcing different access rules. Automating the commands reduces repetitive work, but engineers must still define a consistent service outcome. This is why a network-wide policy model matters alongside the configuration interface. See [9].

• Scale includes coordination : Count the devices affected by one service change, as well as the commands.
• Frequency increases exposure : Repeated changes require repeatable validation of the resulting service.
• Automation needs a policy : A controller needs a defined outcome before it can select device changes.

How do we configure (change configure) in SDN network ?

Naturally, you would come up with a question. How do we cope with those issues listed above ? The new technology that came out to cope with these issue was SDN (Software Defined Networking). The fundamental idea on SDN can be illustrated as shown below. It is to setup a centeralized Control Center and hook up all the individual network components to the centeralized Control Center. And then, configure those individual components remotely with software technology.

The dashed orange links connect the Control Center to individual switches. The blue links still connect switches for forwarding traffic. The C-Plane label identifies control, while U-Plane identifies the forwarding function in the enlarged device. Ordinary user traffic does not need to pass through the Control Center.

An application expresses a network requirement through a northbound interface to the controller. The controller uses southbound interfaces to program devices and obtain information about them. These directions describe roles relative to the controller, rather than physical locations. Control and management interfaces can coexist, and their functions differ. See [6].

For an illustrative access policy, the application requests connectivity between an approved client group and a server. The controller must translate that request into device operations using the available topology and capabilities. A request cannot create an absent physical link or unsupported forwarding action.

• The controller coordinates policy : Applications request behavior that the controller translates into device operations.
• Switches forward the traffic : Control communication and the user traffic path serve different purposes.
• Resources constrain the result : A desired service must fit the actual topology and device capabilities.

What is to be done to realize SDN ?

It may sound good and easy. But 'sound easy' does not always mean 'easily doable'. There will be many things to be done first in order for SDN to be realized. Followings are a couple of things you have to consider first

• What kind of network topology (overall picture of a network) you want to form at the end ? This doesn't need to only one structure. There can be many different topolgies depending on use-model/business model ? It means you need to have some global view of a network.
• What kind of functionality and configuration should be included as part of this new control mechanism (Control Plane). To figure these out, you would need to list up all the possible configurations and functionality and identify those items that can commonly apply to all the switches/routers.
• Each of the network component (switch, router etc) has its own interface that can communicate with the centralized controller and understand the instruction from the controller.  
• Standardized C-Plane interfaces help controllers operate devices from different vendors. A deployment can use multiple interfaces or adapters, and it must still account for device capabilities.
• The controller needs suitable protocols and tools for its control functions. These can include existing protocols; SDN does not require every protocol to be new.

One best known control protocol and tools to handle these issue are OpenFlow (I will handle about OpenFlow in a separate page)

OpenFlow is one southbound control protocol; SDN does not require one universal protocol for every function. NETCONF provides configuration operations, while YANG defines data models for configuration and state. YANG itself does not transport requests. A model identifies the data structure; a protocol carries operations involving that data. See [7] and [10].

A shared model also needs compatible implementation support. YANG modules can define optional features and describe deviations from a model. Therefore, engineers should compare the actual supported modules and features before assuming identical behavior across devices.

• OpenFlow is one option : Choose interfaces for the control and management functions the deployment needs.
• Models and protocols differ : YANG describes data, while NETCONF carries management operations involving that data.
• Common syntax is insufficient : Interoperability also depends on supported models, features, and device behavior.

How does a packet cross an SDN network ?

A controller connection alone does not explain how a switch handles an arriving packet. Consider a small, illustrative network with one client, two switches, and one server on a single Ethernet segment.

Figure 1 separates the packet path from the controller connections for this example. Host A connects to S1, and Host B connects to S2. The controller has a control connection to each switch. The example assumes host addresses and attachment ports are already known; address discovery is outside its scope.

Figure 1. Installed forwarding rules carry the example traffic through S1 and S2 without traversing the controller.

Assume the controller installs a rule on S1 matching frames destined for Host B. Its action sends those frames toward S2. Another rule on S2 sends them to the port connected to Host B. The controller must also provide rules for the return direction if the service requires replies.

With proactive installation, these rules exist before the application sends traffic. A reactive design can send an unmatched packet to the controller through Packet-In, then install rules using Flow-Mod. However, an OpenFlow table miss does not automatically trigger Packet-In. Its configured behavior can instead discard the packet or continue processing in another table. See [8].

For this example, test both directions separately and observe counters on the intended rules. If S1 counts transmitted frames but S2 counts none, inspect the inter-switch link and port mapping. If both switches count traffic, inspect the destination port and Host B before changing controller policy.

• Define the example assumptions : Host discovery and return traffic need explicit treatment in a working deployment.
• Check miss behavior : A missing forwarding rule does not always produce a controller request.
• Follow the packet evidence : Rule counters help locate where the observed path differs from the intended path.

What happens when the controller or a link fails ?

An SDN design must specify behavior when control communication becomes unavailable during normal forwarding. A controller outage and a broken data link are different failures, so they need separate tests.

Logical centralization does not require one physical controller process. A deployment can distribute control functions, but it must address coordination and inconsistent information. Adding another controller instance alone does not define how competing updates are resolved. See [9].

In OpenFlow fail secure mode, installed entries continue operating and can expire through their configured timeouts. Traffic requiring an unavailable controller cannot receive a new decision. Fail standalone mode instead uses normal switching or routing behavior where supported. Its suitability depends on the required isolation policy. See [8].

A practical test extends the two-switch example. Disconnect the controller connection while leaving the S1-to-S2 link operational, then observe existing traffic and attempts to start another flow. Next, restore control connectivity and break the S1-to-S2 link. This topology has no alternate data path, so controller recovery alone cannot restore connectivity between the hosts.

Engineers should also compare requested configuration with operational state after recovery. The Network Management Datastore Architecture distinguishes intended configuration from operational state, including configuration actually in use. An accepted request therefore needs follow-up verification of the device state and service outcome. See [11].

• Test failures independently : Separate controller loss, forwarding-link loss, and rule expiration in the test plan.
• Redundancy needs coordination : Multiple controller instances require defined ownership and recovery behavior.
• Verify the recovered service : Restored management connectivity does not prove that the packet path works again.

Reference

[1]  Software-Defined Networking: The New Norm for Networks (ONF Whitepaper)  

[2]  SoftAir: A software defined networking architecture for 5G wireless systems

[3]  SDN and OpenFlow Overview - Open, API and Overlay based SDN (YouTube)

[4]  Stanford Seminar - Software-Defined Networking at the Crossroads : A Lecture from an early inventor of SDN

[5] Uncovering Software-Defined Networking (SDN) - Network of the Future Documentary, Part 3  (YouTube)

[6] RFC 7426 : Software-Defined Networking (SDN): Layers and Architecture Terminology; Selected passages in Sections 1, 3.2-3.4, 3.6-3.7, and 4.

[7] RFC 6241 : Network Configuration Protocol (NETCONF); Section 1.

[8] OpenFlow 1.5.1 : ONF - OpenFlow Switch Specification; Selected passages in Sections 5.4, 6.1, 6.3.5, and flow modification definitions.

[9] RFC 7149 : Software-Defined Networking: A Perspective from within a Service Provider Environment; Selected passages in Sections 2.4 and 3.

[10] RFC 7950 : The YANG 1.1 Data Modeling Language; Selected passages in Sections 1 and 5.6.

[11] RFC 8342 : Network Management Datastore Architecture (NMDA); Selected passages in Sections 4 and 5.