Software Defined Networking (SDN)

• Software Defined Networking (SDN) emerged to enhance the programmability of computer networks, which are complex and challenging to manage.
• Complexity in computer networks arises from equipment diversity and proprietary technologies.

Diversity of Equipment

• Computer networks include a wide array of devices like routers, switches, firewalls, and intrusion detection systems, each needing specific software and protocols.

Proprietary Technologies

• Routers and switches often use proprietary software, causing configuration interface variations across vendors and products, complicating central management.
• SDN seeks to redesign networks for manageability, employing task separation.

SDN's Solution

• By dividing the network into two planes: control and data, SDN simplifies management and accelerates innovation.

A brief history of SDN

• SDN history can be divided into 3 phases: Active networks, Control and data plane separation, OpenFlow API and network operating systems.

Active Networks (Mid-1990s to Early 2000s)

• The increase in Internet applications led to the desire for new ways to improve network services.
• Standardization of new protocols by the IETF was slow.
• Active networks aimed to open up network control with a programming interface (network API). The API exposed network nodes/resources, which supported customized functions for packet subsets.
• Active networks conflicted with the Internet community belief that the simplicity of the network core was important for Internet success.
• In the early 1990s, networking was done through IP or ATM.
• Active networking became one of the first 'clean slate' approaches to network architecture.
• The 2 active networking programming models were the Capsule model, which carried code in data packets, and the programmable router/switch model, established by out-of-band mechanisms.
• Capsule model's code-carrying data packets introduced new data-plane functionality across networks, using caching for distribution efficiency.
• Programmable routers transferred the decision-making to the network operator.

Technology Push

• Computational cost reduction enabled increased network processing.
• Advancements in programming languages like Java allowed VM technology, code execution safety, and platform portability.
• DARPA funding aided interoperability among projects.

Use Pull: The needs driving active networking

• Service providers wanted to develop and deploy new network services faster.
• Third parties wanted to add value by having control at a more individualistic nature.
• Researchers were interested in networks that would support large-scale experimentation.
• Unified control over middleboxes was sought to replace diverse programming models.

Active networks made three major contributions to SDN

• Implementing programmable functions in the network to lower the barrier to innovation. Using programmable networks to overcome the slow speed of innovation in computer networking.
• Active networks focused on the programmability of the data-plane. This has continued independently.
• The concept of isolating experimental traffic from normal traffic emerged, which is heavily used in OpenFlow and other SDN technologies.
• Using network virtualization and the ability to demultiplex to software programs based on packet headers.
• A framework to describe a platform that would support experimentation with different programming models.
• Creating a unified architecture for middlebox orchestration.
• The idea of unified control over middleboxes was never fully realized in active networking's use of SDN.
• End users writing Java code was too far removed from reality, perceived as unsafe.
• Active networking focused on redesigning the architecture of networks, with little emphasis put on performance and security.
• Efforts were made to build high-performance active routers and address network security.
• Since there were no clearly defined short-term problems that active networks solved, there was no widespread deployment.
• Attempts were made to create a more focused scope to distinguish between control and data planes

Control and Data Plane Separation (2001-2007)

• Increased traffic volumes emphasized the need for network reliability, predictability, and performance.
• Network operators sought enhanced network-management functions such as control over paths to deliver traffic. Researchers explored short-term solutions using existing protocols.
• The challenge in network management can be identified as the way existing routers and switches tightly integrate the control and data planes.

Technology push

• Higher link speeds in backbone networks allowed vendors to implement packet forwarding directly in hardware, separating it from the control-plane software.
• ISPs had trouble meeting demands for greater reliability and struggled to manage their growing networks.
• Servers had more memory for easier management.
• Open-source routing software lowered the barrier for centralized routing controller prototype implementations.

SDN innovation

• Open interface between control and data planes
• Logically centralized control of the network

Use Pull (the needs addressed by the move to separate control and data planes)

• Network path selection based on traffic load.
• Minimizing disruptions when implementing routing changes
• Redirecting/dropping suspected attacks.
• Allowing customer networks more control over traffic flow
• Offering services of real value for private network customers
• A separation of the control and data planes gave rise to logically centralized control, as well as distributed state management.
• Many originally thought separating control and data planes was a bad idea, because these networks had no idea what to do if a controller failed.

OpenFlow API and network operating systems (2007-2010)

• This phase took place due to a desire for interest in network experimentation at scale.
• It was able to balance a vision of programmable networks and the practicability of ensuring real world deployment.
• OpenFlow was built on the existing hardware and enabled more functions than earlier route controllers.
• OpenFlow switch includes a table of packet-handling rules. Each rule includes a pattern, a list of actions, counter set, and a priority.
• When an OpenFlow switch receives a packet, it determines the highest priority matching rule, performs the action, and increments the counter.

Technology Push

• Switch chipset vendors had already started to allow programmers to control some forwarding behaviors.
• This allowed more companies to build switches without fabricating their own data plane.
• Enabling OpenFlow initially was as simple as performing a firmware upgrade.

Use Pull

• OpenFlow came up to meet the need of conducting large scale experimentation on network architectures.
• OpenFlow testbeds were deployed across many campuses to show its capability on networks and wide area backbone networks.
• OpenFlow was useful in managing network traffic at large-scale data-center networks.
• Companies started investing more in programmers, and less in proprietary switches. Allowing smaller players to become competitive in the market.

Key effects of OpenFlow

• Generalizing network devices and functions.
• Introducing the vision of a network operating system.
• Implementations of distributed state management techniques.

Why Separate Data and Control Planes

• Reasons for this are independent evolution and development and control from high-level software program.

Independent Evolution and Development

• Traditionally, routers handled both routing and forwarding, which meant hardware upgrades were needed frequently.
• By having routers focus solely on forwarding, this can allow innovation to proceed independently of other routing considerations.
• Routing algorithms can improves without affecting the existing routers.

Control from High-Level Software

• In SDN, forward tables are computed and then software is used to control the direction behavior of routers. Decoupling these functions makes debugging and checking the behavior of the network easier.
• Separation of the control and data planes enable the independent evolution and development of both.
• The controller can implement routing security easier this way.
• SDN facilitates more effective data center management.
• SDN allows research networks to coexist with production networks.

Control Plane and Data Plane Separation

• Two important functions of the network layer are forwarding and routing.

Forwarding

• Forwarding is an important function of the network layer. When a router at its input link receives a packet, it must determine which output link the packet should be sent through.
• The process involves blocking a paket, or duplicating the packet and sending it along multiple output links.
• Because forwarding is a function that takes place on nanosecond timescales, it is usually implemented in the hardware itself and a function of the data plane.

Routing

• Routing involves determining the path from the sender to the receiver across the network.
• Routers rely on routing algorithms for this purpose.
• It is an end-to-end process for networks, that takes place in seconds and is implemented in the software. As such, it is a function of the control plane.
• In the traditional approach, routing algorithms are closely coupled. Routers run and participate in the routing algorithms and are able to construct the forwarding table.

SDN Architecture

• In the SDN approach, a remote controller computes and distributes the forwarding tables to be used by every router. This controller could be located in a remote data center.
• Routers are solely responsible for forwarding while remote controllers are solely responsible for computing and distributing the forwarding tables.
• The controller is implemented in software and is software-defined. Software implementations are open and publicly available.
• The functions of the network has been separated, with routers solely responsible for forwarding and the remote controller for computing forwarding tables.
• SDN-controlled network elements (infrastructure layer) forwards network traffic with rules by the SDN control plane.
• The SDN controller, is a logically centralized entity that works as an interface between the network elements as well as the network-control applications.
• The network-control applications manage the underlying network.

Four defining features in an SDN architecture

• Rules for forwarding packets in the SDN-controlled switches can be computed based on any number of header field values in various layers.
• This differs from the traditional approach where only the destination IP address determines the forwarding of a packet.

Separation of Data Plane and Control Plane

• SDN-controlled switches operate on the data plane and only execute rules. The rules are installed on separate servers.

Network Control Functions

• The SDN control plane running on multiple servers increased performance and availability.
• The controller and the network applications compose the SDN control plane.
• Network state is kept up to date about the network devices and elements by the controller, and it provides this information to the network-control applications.
• Used for managing the network, network-control applications are the "brain” of the SDN control plane.

The SDN Controller Architecture

• An SDN controller acts as an interface between the network elements and the network-control applications.
• It can be split into 3 layers: the communication layer, the network-wide state management layer and the interface to the network-control application layer.

Communication Layer

• Consists of a protocol for communicating between the network controlled elements and the SDN controller.
• Using this protocol can allow devices to send locally observed events to the SDN controller, resulting in a current view of the network state.
• The communication between SDN controller and the controlled devices is known as the "southbound" interface such as OpenFlow.

Layer for Network-Wide State Management

• This layer is about the network-state that is maintained by the controller.
• Copies of the flow tables of the switches and any info about the states goes here.

Interface to the Network-Control Application Layer

• The north bound gives the controller its interface with network-control applications.
• To read/write the network application state, network-control applications use this layer. In addition, the SDN controller can notifiy what is happening in the state of the network.
• It is a centralized service by external devices and applications.
• It is implemented through distributed servers, to achieve fault tolerance, high availability and efficiency.
• Synchronizing server issues have been solved by modern controllers like OpenDayLight and ONOS, as they provide highly scalable services.

The OpenDayLight controller architecture

• A look at the southbound and northbound interfaces, and how the SDN controller uses them to interact with all components.

The Southbound interface

• Used by the controller for communicating with network devices.
• The interface also supports third-party protocols like openflow, netflow, netconf etc.

The Northbound Interface

• An "upward" bound interface so that SDN applications can talk to the controller platform underneath.

The Model Driven Service Abstraction Layer (or MD-SAL)

• This layer lets developers add new services or protocol drivers by integrating them together.
• This contains a shared datastore, which has a config datastore to manage and sanity check, and an operation datastore to reflect a data store of the managed network elements.