UNIT 1

1. Introduction to SDN
In the last few decades, computer networks have become an essential part of modern life.
However, the explosive growth of internet traffic, adoption of cloud computing, IoT
devices, and virtualization technologies have created new challenges for traditional
networking approaches.

In traditional networks, the control plane (decision-making) and the data plane (forwarding)
are tightly integrated into the same device, such as routers and switches. This makes networks
complex, vendor-dependent, and hard to scale.

Software Defined Networking (SDN) is a modern networking paradigm designed to address

these challenges by separating the control plane from the data plane and introducing
programmability into the network.

SDN breaks this dependency by moving the control logic to a centralized SDN controller and
allowing network devices to act as simple packet-forwarding hardware. The controller
communicates with these devices through standardized protocols like OpenFlow.
Limitations of Traditional Networks

1.​ Complex Configuration​

○​ Each device needs to be configured manually using vendor-specific CLI

commands.​

○​ Configuration errors are common and hard to troubleshoot.​

2.​ Vendor Lock-in​

○​ Hardware and software are tightly coupled to specific vendors.​

○​ Upgrading or integrating devices from different vendors is expensive.​

3.​ Lack of Automation​

○​ No central point of control; automation is limited.​

○​ Responding to network changes is slow.​

4.​ Poor Scalability​

○​ Adding or changing services requires reconfiguration of multiple devices.​

○​ Not suitable for large-scale data centers or cloud environments.​

5.​ Security Challenges​

 ○​ Decentralized control makes enforcing security policies difficult.​

○​ Threat detection and mitigation are slow.​

How SDN Solves These Problems

●​ Centralized Control: The SDN controller manages the entire network from a single
point.​

●​ Programmability: Network behavior can be changed via software applications.​

●​ Vendor Independence: Uses open standards like OpenFlow, making devices from
different vendors interoperable.​

●​ Automation: Policies can be deployed instantly across all devices.​

●​ Dynamic Adaptation: Real-time monitoring and adjustments improve performance and

security.​
SDN Architecture
The SDN architecture is generally divided into three planes:

4.1 Application Plane

●​ What it is:​
The topmost layer where network applications and business logic run.​

●​ Examples: Network monitoring, firewall policies, load balancing, intrusion detection,

QoS (Quality of Service) management.​

●​ Role: Sends requirements to the control plane using Northbound APIs.​

4.2 Control Plane

●​ What it is:​
The brain of the SDN — the SDN controller.​

●​ Function:​
 ○​ Translates application requirements into network instructions.​

○​ Maintains a global view of the network.​

○​ Sends forwarding rules to data plane devices via Southbound APIs.​

●​ Examples of Controllers: OpenDaylight, ONOS, Ryu, Floodlight.​

4.3 Data Plane

●​ What it is:​
The physical or virtual network devices (switches, routers) that forward traffic.​

●​ Role:​

○​ Follow the rules sent by the control plane.​

○​ Forward, drop, or modify packets based on instructions.​

●​ Key Protocol: OpenFlow is the most common protocol for control-data communication.
●​
APIs in SDN
●​ Northbound APIs:​
Connect the application plane to the control plane. They allow applications to request
services from the controller (e.g., REST API).​

●​ Southbound APIs:​
Connect the control plane to the data plane. They send instructions to switches/routers
(e.g., OpenFlow, NETCONF).

Advantages of SDN
1.​ Centralized network management.​

2.​ Reduced operational costs.​

3.​ Easier scalability and flexibility.​

4.​ Faster innovation and deployment.​

5.​ Better policy enforcement.​

 6.​ Vendor independence.​

8. Disadvantages of SDN
1.​ Controller is a single point of failure.​

2.​ Potential scalability issues for very large networks.​

3.​ Security risks if controller is compromised.​

4.​ Migration complexity from traditional systems.

5.​

Evolution of Networking and Challenges of Traditional Networks

Introduction to Networking Evolution

Networking is the process of connecting multiple computing devices to exchange data, share
resources, and enable communication. Over the last few decades, networking has evolved from
simple, static point-to-point connections to highly dynamic, software-controlled architectures that
power modern applications such as cloud computing, IoT, and AI.
Understanding the Data Plane

Definition​
The Data Plane (also called the Forwarding Plane) is the part of a network device responsible
for actually moving user traffic (data packets) from one interface to another based on the
rules and instructions set by the Control Plane.

Introduction to the SDN Data Plane

Definition​
In Software-Defined Networking (SDN), the Data Plane (also called the Forwarding Plane)
is the component responsible for forwarding packets according to rules provided by the
centralized SDN controller.​
Unlike in traditional networks—where the control and data planes are integrated into each
device—SDN separates them, placing decision-making (control) in a central controller and
leaving the data plane to focus purely on high-speed packet handling.
Key Role in SDN

●​ Executes the instructions sent from the SDN Control Plane via standardized protocols
such as OpenFlow.​

●​ Works without making independent routing decisions; all logic comes from the controller.​

●​ Handles forwarding, dropping, flooding, or modifying packets based on predefined

flow rules.​

●​

Characteristics of SDN Data Plane

1.​ Programmable Behavior​

○​ Flow tables can be updated dynamically by the controller without manual device
CLI configuration.​

2.​ Stateless Operation​

○​ Data plane devices (often called SDN switches) do not run complex routing
algorithms; they just follow installed flow rules.​

3.​ Centralized Decision Dependency​

○​ Relies on the SDN controller for decision-making, improving consistency across

the network.​

4.​ High-Speed Forwarding​

○​ Still uses hardware acceleration (ASICs) or software-optimized engines to

process traffic at line rate

Components Inside an SDN Data Plane Device

●​ Flow Table – Stores match-action rules installed by the controller.​

●​ Packet Processing Engine – Matches incoming packets to flow table entries.​

●​ Counters – Record statistics like packet count, byte count, and flow duration,
reported back to the controller.​
 ●​ Ports & Interfaces – Physical or virtual connections to send/receive traffic.

How the SDN Data Plane Works

Step-by-Step Operation Example

1.​ Packet Arrival​

○​ A packet enters an SDN-enabled switch.​

2.​ Flow Table Lookup​

○​ The data plane checks if there is a matching flow entry for the packet
(based on IP, MAC, VLAN, TCP port, etc.).​

3.​ Match Found → Action Taken​

○​ Action could be forward to a specific port, modify a header, drop the

packet, or send it to another network segment.​

4.​ No Match → Controller Involvement​

○​ The packet (or just its header) is sent to the SDN controller for a decision.​

○​ The controller installs a new rule into the switch’s flow table.​

○​ The packet is processed accordingly.​

5.​ Statistics Update​

○​ The data plane updates counters for traffic monitoring

Introduction to the SDN Control Plane

Definition​
In Software-Defined Networking (SDN), the Control Plane is the component responsible
for making decisions about how network traffic should flow.​
It determines the routing, forwarding, and security policies for data packets, then
communicates these decisions to the Data Plane for execution.

Difference from Traditional Control Plane

●​ Traditional Networks: Control Plane logic (e.g., routing protocols like OSPF, BGP)
runs inside each switch or router individually.​
 ●​ SDN: Control Plane is centralized in a software-based SDN Controller, which has a
complete view of the entire network.​

Key Features

●​ Centralized View: Single point of decision-making.​

●​ Programmability: Controlled via APIs (e.g., REST APIs in OpenDaylight, ONOS).​

●​ Flexibility: Can integrate with applications like firewalls, load balancers, or

monitoring tools.​

●​ Global Network Knowledge: Knows the state of every device, link, and flow.

How the SDN Control Plane Works

Workflow Example

1.​ Device Discovery​

○​ Controller connects to all SDN switches and learns topology.​

2.​ Traffic Event Detection​

○​ A switch receives a new type of packet with no matching flow rule.​

3.​ Packet-In Message​

○​ Switch sends packet header info to the controller via OpenFlow.​

4.​ Decision Making​

○​ Controller determines the correct forwarding path and any necessary

packet modifications.​

5.​ Flow Installation​

○​ Controller pushes a flow rule to the switch’s Data Plane.​

6.​ Continuous Monitoring​

○​ Collects statistics (packet counts, byte counts, link usage) for analytics and
optimization.​
Introduction to the Management Plane

Definition​
The Management Plane is the part of a network device or architecture responsible for
network administration, configuration, monitoring, and control operations.​
While the Control Plane decides where traffic goes and the Data Plane moves it, the
Management Plane is where network administrators interact with and manage devices.

Key Functions

1.​ Configuration Management​

○​ Setting up VLANs, IP addresses, routing protocols, and security rules.​

2.​ Monitoring & Logging​

○​ Collecting device performance metrics, link utilization, and error logs.​

3.​ User Authentication & Access Control​

○​ Managing admin accounts and permissions for network devices.​

4.​ Software & Firmware Updates​

○​ Pushing updates to improve security, fix bugs, or add features.​

5.​ Policy Management​

○​ Defining global network policies (e.g., security rules, QoS) and distributing
them to devices.​

Communication Methods in Management Plane

●​ CLI (Command-Line Interface) – SSH, Console, Telnet (legacy).​

●​ GUI (Graphical User Interface) – Vendor-specific web interfaces or dashboards.

Security in the Management Plane

●​ Since it gives full control over devices, it’s a high-value attack target.​

●​ Best practices:​
○​ Use encrypted protocols (SSH, HTTPS) instead of Telnet/HTTP.​

○​ Implement role-based access control.​

○​ Restrict management access to secure subnets (out-of-band networks).

UNIT 2

Functions of the SDN Data Plane and its Associated

Protocols

Introduction to Software-Defined Networking (SDN)

Software-Defined Networking (SDN) is a networking paradigm that separates the control

plane (decision-making) from the data plane (packet forwarding).

●​ Control Plane: Determines where traffic is sent. Managed by the SDN Controller.​

●​ Data Plane: Forwards packets according to the rules given by the Control Plane.​

In traditional networks, these two planes are tightly integrated into the same device (like
a router or switch). In SDN, the data plane becomes a programmable forwarding layer,
making the network more flexible, dynamic, and easy to manage.

What is the SDN Data Plane?

The SDN Data Plane (also known as the forwarding plane) is the physical or virtual
networking hardware responsible for handling and forwarding packets according to flow
rules sent by the controller.

Key roles of the Data Plane:

●​ Receive packets from incoming interfaces.​

●​ Match packet headers to flow table entries.​

●​ Apply actions (forward, drop, modify headers, send to controller).​

●​ Maintain forwarding performance at high speeds.​

Examples of Data Plane devices:

●​ OpenFlow switches (hardware or software-based)​

●​ Virtual switches like Open vSwitch (OVS)

●​
OpenFlow Protocol

OpenFlow is the first standard communication interface defined between the control
plane and the data plane of a Software Defined Network (SDN).​
It allows network controllers to determine the path of network packets across a network
of switches.

In traditional networks:

●​ The control plane (routing decisions) and data plane (forwarding of packets) are
located inside the same network device.​

●​ This makes networks less flexible and harder to automate.​

In SDN:

●​ Control plane is centralized in an SDN controller.​

●​ Data plane remains in network switches, which simply forward packets as

●​ Instructed.

First — What Does “Reactive” Mean in SDN/OpenFlow?

In SDN (Software-Defined Networking) using OpenFlow, a reactive flow is created only
when the first packet of a new flow arrives at the switch, and the switch doesn’t know
what to do with it.

How it works (Reactive flow setup):

1.​ A packet arrives at the switch.​

2.​ The switch looks into its flow table — no matching entry is found.​

3.​ The switch sends a Packet-In message to the SDN controller.​

4.​ The controller decides what to do (e.g., forward, drop, modify) and sends a
Flow-Mod message to install a new rule in the switch.​

5.​ The switch applies the action to the current packet and stores the rule for future
packets of the same flow.​

Pros:

●​ Saves memory: rules are only installed when needed.​

●​ Adapts dynamically to unknown traffic.​

Cons:

●​ Slower for the first packet (extra delay while controller decides).​

●​ Higher controller load for many new flows.​

9+
2. What Does “Proactive” Mean in SDN/OpenFlow?
A proactive flow is created before any packet arrives, usually during network initialization
or based on known traffic patterns.

How it works (Proactive flow setup):

1.​ Controller already knows what kinds of flows will be common (e.g., ARP, DNS,
HTTP traffic).​

2.​ At startup or periodically, it pushes Flow-Mod messages to switches to install

these rules in advance.​

3.​ When packets arrive, the switch matches them instantly without contacting the
controller.​

Pros:

●​ No delay for the first packet.​

●​ Lower controller load during traffic bursts.​

Cons:

●​ Uses more switch memory (installing rules that might not be used).​

●​ Less flexible for completely unexpected traffic.

Flow Table in OpenFlow

In Software-Defined Networking (SDN), the flow table is the core structure inside the data
plane (switch) that stores rules on how packets should be handled.​
Each entry in the flow table is called a flow entry and typically consists of:

1.​ Header Fields – Define which packets match this flow.​

2.​ Counters – Track statistics about packets that match this flow.​

3.​ Actions – Specify what should be done with packets that match.​
1. Header Fields
Header fields define the matching criteria for incoming packets.​
When a packet arrives, the OpenFlow switch compares the packet’s header values
against the flow entries' header field values to find a match.​
These fields can be exact matches, wildcarded (ignored), or partially masked.

Counters
Counters store statistics for each flow entry. They are automatically updated by the
OpenFlow switch hardware/software whenever packets match the flow.

Purpose of Counters

●​ Monitoring network performance – Administrators can check traffic volume.​

●​ Debugging & troubleshooting – Detect anomalies or unexpected traffic patterns.​

●​ Flow aging – Decide when to remove inactive flows based on byte/packet counts.

Actions
Actions define what to do with packets that match the header fields.

In an OpenFlow-based Software-Defined Networking (SDN) environment, communication

between the controller (control plane) and the switch (data plane) is defined using
standard message types. These messages are exchanged over a secure TCP/TLS
channel, and they can be classified into three categories:

1.​ Symmetric Messages – Can be sent by either controller or switch at any time.​

2.​ Controller-to-Switch Messages – Sent by the controller to configure, instruct, or

request data from the switch.​

3.​ Asynchronous Messages – Sent by the switch to inform the controller of events or
changes.​
Each category serves a unique role in maintaining a smooth, programmable, and
responsive SDN network

Symmetric Communication
Definition:​
Symmetric messages are bidirectional, meaning both the controller and the switch can
send them at any time without a prior request. They help in connection management,
health monitoring, and vendor-specific operations.

Controller-to-Switch Communication
Definition:​
These messages are always initiated by the controller and are used to query the switch,
configure parameters, or modify the switch state. They give the controller direct control
over how the switch handles network traffic.

Asynchronous Communication
Definition:​
Asynchronous messages are initiated by the switch to inform the controller about
network events, state changes, or statistics updates without the controller explicitly
asking for them.

How These Three Work Together

An OpenFlow session typically involves all three types of communications working in
coordination:

●​ Symmetric messages start the connection (Hello) and keep it alive (Echo).​

●​ Controller-to-switch messages push down the network policies and rules.​

●​ Asynchronous messages notify the controller about events so it can adjust

policies dynamically.
Northbound APIs in SDN – Detailed Explanation
1. Introduction to Northbound APIs

In Software Defined Networking (SDN), the Northbound API (Application Programming

Interface) acts as the bridge between the SDN control plane (specifically the SDN
Controller) and applications or network services that run above it.​
Without the Northbound API, application developers would have to directly interact with
the complex, low-level networking commands of the underlying infrastructure. This
would make network automation, orchestration, and service provisioning very
complicated.

2. Purpose of Northbound APIs

The primary purpose of the Northbound API is to:

 ●​ Allow applications to request network information from the SDN controller.​

●​ Enable applications to send instructions or policies to the SDN controller for

enforcement.​

●​ Abstract the hardware complexity so application developers focus on service

logic instead of networking internals.

Advantages of Northbound APIs

●​ Faster Service Deployment – No need to manually configure devices.​

●​ Vendor Independence – Applications work across multiple hardware platforms.​

●​ Business Alignment – Network behavior can align with business objectives (e.g.,
SLAs).​

●​ Innovation – Developers can create new networking apps without touching the
infrastructure.​
Southbound Interface in SDN
The Southbound Interface (SBI) is a critical component of Software-Defined Networking
(SDN) that connects the SDN controller with the network devices such as switches,
routers, and access points. It allows the controller to communicate with, manage, and
program the data plane of these devices dynamically. Essentially, the Southbound
Interface acts as the bridge between the control plane and the data plane, enabling
centralized network control and programmability, which are the hallmarks of SDN.

Purpose and Functionality

In traditional networks, each network device has its own control and data planes, which
leads to distributed decision-making, manual configurations, and challenges in network
management. SDN decouples the control plane from the data plane:

1.​ Control Plane: Located in the SDN controller, it makes global decisions about
traffic flow, routing, and policies.​

2.​ Data Plane: Located in the network devices, it is responsible for forwarding
packets according to instructions from the control plane.​

The Southbound Interface is the mechanism through which these instructions are
transmitted. It enables the controller to:

●​ Program network devices dynamically – modifying flow tables, setting routing

rules, and applying policies without manual intervention.​

●​ Monitor device status – gather statistics, check link health, and detect failures in
real-time.​

●​ Enforce policies consistently – ensure network-wide compliance with security,

quality of service (QoS), and traffic engineering requirements.​

●​ Support network virtualization – allows abstraction of physical network devices to

create virtual networks for tenants or applications.​

Without a robust Southbound Interface, the benefits of SDN, including flexibility, agility,
and automation, cannot be fully realized.
Ryu SDN Framework
Ryu is an open-source software framework designed for building Software-Defined
Networking (SDN) applications. It is written in Python, making it highly accessible,
extensible, and developer-friendly. Ryu provides a set of libraries and APIs that allow
network programmers to control and manage network devices from a centralized SDN
controller. Its modular architecture supports multiple protocols, enabling integration with
a variety of switches, routers, and other network devices.

Purpose of Ryu
In traditional networking, network devices operate independently, each maintaining its
own control and data plane. This leads to challenges such as:
 ●​ Manual configuration of devices​

●​ Lack of real-time network visibility​

●​ Inconsistent policy enforcement​

Ryu addresses these challenges by acting as an SDN controller framework, offering:

1.​ Centralized control: The controller manages multiple devices from a single
location.​

2.​ Network programmability: Developers can write Python applications to

dynamically manage traffic, routes, and network policies.​

3.​ Protocol support: Ryu natively supports SDN protocols like OpenFlow, and can
integrate with NETCONF, OF-Config, and others.​

4.​ Rapid prototyping: Its Python base allows fast development of SDN applications
and network services.​

Key Features of Ryu

1.​ OpenFlow Support: Ryu fully supports OpenFlow versions 1.0 to 1.5, enabling
granular control of network flows.​

2.​ Python-based Development: Python’s readability allows quick development and

testing of SDN applications.​

3.​ Modularity: Applications can be added, removed, or modified without affecting the
core controller.​

4.​ Extensibility: Developers can extend Ryu to support new protocols or custom
devices.​

5.​ Event-driven Architecture: Reacts to network changes in real-time, providing

dynamic control.​

6.​ Rich API: Simplifies interaction with network devices, including packet
manipulation, flow installation, and statistics collection.​
 7.​ Community Support: Ryu has active community contributions and documentation,
making it easier for developers to adopt and troubleshoot.​

Working of Ryu SDN Controller

1.​ Device Discovery: Ryu detects OpenFlow-enabled switches when they connect to
the controller.​

2.​ Event Handling: Devices generate events (e.g., packet-in when no matching flow
exists).​

3.​ Application Logic: Ryu applications process these events and determine the
network behavior, such as routing or dropping packets.​

4.​ Flow Installation: The controller sends flow-mod messages to switches to update
their forwarding tables.​

5.​ Monitoring: Ryu periodically collects network statistics for traffic analysis and
policy enforcement.​

This workflow ensures centralized, programmable, and dynamic control over network
devices.

Advantages of Using Ryu

●​ Ease of use: Python-based framework is easy to learn and implement.​

●​ Rapid prototyping: Developers can test SDN applications quickly.​

●​ Protocol flexibility: Supports multiple SDN protocols for diverse environments.​

●​ Event-driven programming: Enhances network responsiveness and real-time

management.​

●​ Open-source: Freely available, widely used, and supported by the SDN

community.​
Use Cases
1.​ Dynamic routing: Adjusts paths based on network conditions.​

2.​ Traffic engineering: Optimizes network resource utilization.​

3.​ Load balancing: Distributes traffic efficiently across multiple servers.​

4.​ Network virtualization: Creates virtual networks on top of physical infrastructure.​

5.​ Security enforcement: Implements firewalls, intrusion detection, and packet

filtering dynamically.​

Conclusion
Ryu is a powerful, flexible, and Python-friendly SDN controller framework that provides
centralized network control, programmability, and rapid prototyping for network
applications. Its modular architecture, rich protocol support, and event-driven design
make it ideal for research, development, and real-world deployment in SDN
environments. By leveraging Ryu, organizations can transform traditional networks into
agile, automated, and intelligently managed networks, achieving the full potential of SDN.

he architecture in the figure is divided into three main sections:

1.​ Northbound Interfaces (Top part – interaction with applications and operators)​

2.​ Ryu SDN Framework (Middle part – main controller logic)​

3.​ Southbound Interfaces (Bottom part – communication with OpenFlow switches)​

2. Northbound Interfaces
These are the entry points for applications, operators, or orchestration systems to
interact with the controller.

a. Operator

●​ What it is:​
This represents a human network administrator who manages and monitors the
network through Ryu’s RESTful management API.​

●​ Why it is used:​

○​ To configure network behavior (e.g., setting flow rules, viewing topology).​

○​ To manage policies without directly touching switches.​

○​ To monitor real-time network statistics.​

b. OpenStack Cloud Orchestration

●​ What it is:​
This is integration with OpenStack, a popular cloud infrastructure management
platform. Ryu works with OpenStack via REST API for Quantum (now called
Neutron in modern OpenStack versions).​

●​ Why it is used:​

○​ Allows automated network provisioning in cloud environments.​

○​ Provides on-demand creation of virtual networks for tenants.​

○​ Enables seamless orchestration between virtual machines and the network.​

c. User Applications

●​ What it is:​
Custom applications developed by users to control or monitor the network. These
applications can communicate with Ryu via:​
 ○​ REST API – Simple, stateless HTTP calls.​

○​ RPC – Remote Procedure Calls for more complex or persistent interactions.​

●​ Why it is used:​

○​ To create specialized network functionalities (e.g., load balancing, intrusion

detection).​

○​ To gather network statistics and adapt policies dynamically.​

3. Ryu SDN Framework (Core Controller)

This is the heart of the architecture. It processes requests from northbound applications
and translates them into OpenFlow commands for southbound devices.

a. Built-in Apps

●​ Examples: Tenant isolation, L2 switch.​

●​ Purpose:​

○​ Tenant Isolation: Ensures that multiple tenants (clients) sharing the same
physical infrastructure remain logically separated for security and privacy.​

○​ L2 Switch: Basic layer-2 forwarding application built into Ryu to handle

Ethernet frame switching without needing a separate application.​

●​ Why it is used:​

○​ Provides out-of-the-box functionality so developers don’t always have to

code basic features from scratch.​

○​ Serves as templates for creating more advanced applications.​

b. Libraries
 ●​ Examples: OpenFlow (OF) REST, topology discovery, firewall.​

●​ Purpose:​

○​ OF REST: A REST-based interface for managing OpenFlow rules.​

○​ Topology Discovery: Discovers network topology by identifying switches,

links, and hosts dynamically.​

○​ Firewall: Implements security rules and traffic filtering.​

●​ Why it is used:​

○​ Libraries save development time.​

○​ Provide reusable components for multiple applications.​

c. Protocol Parsers

This section of the framework translates protocol messages between devices and the
controller.

i. OpenFlow Protocols Parser

●​ Supports multiple OpenFlow versions (1.0, 1.2, 1.3, and OF-config 1.1).​

●​ Why it is used:​

○​ To ensure compatibility with different switch models and firmware

versions.​

○​ To interpret flow-mod messages, packet-ins, stats requests, and other

OpenFlow messages.​

ii. Non-OpenFlow Protocols Parser

●​ Examples: Netconf, VRRP, NetFlow, PacketLib.​

●​ Purpose:​
 ○​ Netconf: Network configuration protocol for device management.​

○​ VRRP: Virtual Router Redundancy Protocol, used for failover between

routers.​

○​ NetFlow: Cisco-developed protocol for collecting IP traffic information.​

○​ PacketLib: A packet manipulation library for custom protocol handling.​

●​ Why it is used:​

○​ Ryu isn’t limited to OpenFlow – it can handle multiple protocols for greater
flexibility.​

○​ Supports hybrid SDN environments where OpenFlow is not the only

protocol.​

4. Southbound Interfaces
These are the protocols used by the Ryu controller to communicate with the actual
network devices.

OpenFlow Switch

●​ What it is:​
A hardware or software-based network switch that supports OpenFlow protocol.​

●​ Why it is used:​

○​ Executes the forwarding rules installed by the controller.​

○​ Sends Packet-In messages to the controller for unknown flows.​

○​ Provides network statistics and status updates.

OpenDaylight (ODL) SDN Controller
OpenDaylight (ODL) is a widely used, open-source Software-Defined Networking (SDN)
controller platform. It is designed to provide centralized, programmable control of
network devices and enable the creation of dynamic, automated, and scalable networks.
OpenDaylight is part of the Linux Foundation’s networking projects and focuses on
creating a flexible and modular platform that supports multiple protocols, vendors, and
network applications.

Purpose of OpenDaylight
Traditional networks are limited by:

●​ Device-centric control with no central management​

●​ Manual configuration, prone to errors​

 ●​ Slow adaptation to changing network conditions​

OpenDaylight addresses these limitations by acting as a centralized control plane. It

abstracts the underlying network infrastructure and provides programmable interfaces
for network applications. Key purposes of ODL include:

1.​ Centralized Network Control: Provides a single platform to manage multiple

network devices, reducing complexity.​

2.​ Network Programmability: Offers APIs for developers to create custom network
applications.​

3.​ Protocol Agnosticism: Supports multiple southbound protocols like OpenFlow,

NETCONF, BGP-LS, PCEP, and OVSDB, allowing integration with diverse devices.​

4.​ Service Orchestration: Facilitates network virtualization, traffic engineering, and

policy enforcement.​

Architecture of OpenDaylight
OpenDaylight follows a modular and layered architecture that separates control logic,
network applications, and protocol handling. Its main components include:

1. Southbound Plugins

Southbound plugins are responsible for communicating with network devices. These
plugins implement protocols such as:

●​ OpenFlow: For flow control in switches​

●​ NETCONF: For configuration and management of network devices​

●​ BGP-LS & PCEP: For path computation and routing​

●​ OVSDB: For managing virtual switches​

These plugins abstract the device-specific details and provide a unified view of the
network to the controller.
2. Controller Core

The controller core is the heart of ODL. It provides:

●​ Network topology management: Maintains a global view of all devices and links.​

●​ Data store services: Stores network state, policies, and configurations.​

●​ Event handling: Processes asynchronous events from network devices.​

The controller core enables SDN applications to operate without worrying about
device-specific complexities.

3. Northbound APIs

ODL exposes northbound REST APIs and RESTCONF interfaces that allow network
applications and orchestration platforms to interact with the controller. Through these
APIs, applications can:

●​ Query network topology​

●​ Configure flows and routes​

●​ Monitor traffic statistics​

●​ Enforce policies dynamically​

Northbound APIs provide a programmable interface for developers to build network

automation solutions.

4. Network Applications

ODL supports a wide range of network applications that run on top of the controller,
including:

●​ Dynamic routing applications: Automatically manage routes and paths​

●​ Traffic engineering applications: Optimize bandwidth utilization​

●​ Network virtualization applications: Create isolated virtual networks on the same

physical infrastructure​
 ●​ Security applications: Implement firewalls, access controls, and intrusion
detection​

Applications can be added, removed, or modified without disrupting the underlying

network, thanks to ODL’s modular design.

Working of OpenDaylight
1.​ Device Discovery: Southbound plugins detect and register devices such as
switches, routers, or virtual switches.​

2.​ Topology Construction: The controller builds a global network topology map.​

3.​ Application Interaction: Network applications request or modify network behavior

through northbound APIs.​

4.​ Flow Installation: The controller programs the forwarding rules to devices using
southbound protocols like OpenFlow.​

5.​ Monitoring & Feedback: Network devices send statistics and event updates to the
controller, enabling real-time adaptation.​

This workflow ensures that ODL can dynamically control the network, optimize traffic,
enforce policies, and respond to failures in real time.

Key Features of OpenDaylight

1.​ Modularity: Components can be independently developed and integrated.​

2.​ Protocol Support: Handles multiple southbound protocols for diverse networks.​

3.​ Extensibility: Developers can write custom applications using northbound APIs.​

4.​ High Scalability: Can manage large-scale networks efficiently.​

5.​ Community-driven: Open-source project with active community support and

frequent updates.​
 6.​ Service Abstraction: Provides abstract services like topology, device inventory,
and policy management for easier application development.​

Advantages of OpenDaylight
●​ Multi-vendor support: Works with devices from various vendors due to protocol
standardization.​

●​ Centralized network management: Reduces operational complexity.​

●​ Programmability: Enables network automation, reducing manual configuration

errors.​

●​ Dynamic policy enforcement: Supports real-time adjustments for traffic and

security.​

●​ Integration with NFV: Works seamlessly with Network Functions Virtualization

(NFV) platforms for cloud and data center networks.​

Use Cases of OpenDaylight

1.​ Data Center Automation: Automates virtualized network provisioning and load
balancing.​

2.​ Service Provider Networks: Optimizes routing and resource allocation.​

3.​ Campus Networks: Provides centralized control over switches, access points, and
security devices.​

4.​ Network Security: Implements dynamic firewalls, ACLs, and intrusion detection
systems.​

5.​ Traffic Engineering: Dynamically adjusts routing paths to maximize bandwidth and
reduce congestion.​
Conclusion
OpenDaylight is a powerful, modular, and versatile SDN controller that enables
centralized network management, programmability, and automation. Its support for
multiple protocols, rich northbound APIs, and modular architecture makes it suitable for
a wide range of environments, including enterprise, data center, and service provider
networks. By providing real-time visibility, dynamic control, and flexibility, ODL
transforms traditional static networks into intelligent, automated, and highly scalable
SDN ecosystems, fulfilling the core promise of software-defined networking.

ONOS (Open Network Operating System)

SDN Controller
ONOS is an open-source, carrier-grade Software-Defined Networking (SDN) controller
designed to provide high availability, scalability, and performance for large-scale
networks. Developed primarily for service provider networks and critical infrastructures,
ONOS emphasizes distributed control, fault tolerance, and modular architecture,
enabling operators to manage complex networks in a centralized yet resilient manner.

Purpose of ONOS
Traditional networking suffers from:

●​ Decentralized control with limited visibility​

●​ Complex manual configurations​

●​ Difficulty in scaling and managing large networks​

ONOS addresses these challenges by providing a centralized, programmable control

plane while maintaining distributed functionality for reliability and scalability. Its key
purposes include:

1.​ Centralized Network Intelligence: Provides a global view of the network to manage
traffic, topology, and devices.​

2.​ Programmability: Offers APIs for developers to create custom SDN applications.​
 3.​ High Availability: Designed to remain operational even if one or more controller
nodes fail.​

4.​ Scalability: Supports large-scale networks through a distributed controller

architecture.​

5.​ Vendor Neutrality: Works with multiple device types and protocols, enabling
multi-vendor deployments.​

Working of ONOS
1.​ Device Discovery: ONOS detects network devices and establishes control via
southbound protocols like OpenFlow.​

2.​ Topology Construction: Each node in the ONOS cluster maintains a consistent
view of the network topology.​

3.​ Event Handling: Devices generate events such as packet-in, link failure, or port
change, which ONOS processes in real time.​

4.​ Flow Installation: The controller programs switches with forwarding rules to
achieve desired traffic behavior.​

5.​ Monitoring and Feedback: ONOS continuously collects statistics and health
information from devices to adapt network behavior dynamically.​

The distributed cluster design ensures that the network continues operating smoothly
even if some ONOS nodes fail, providing fault tolerance and resilience.

Key Features of ONOS

1.​ Distributed Architecture: Supports multiple controller nodes for scalability and
high availability.​

2.​ High Performance: Optimized for carrier-grade and large-scale networks.​

 3.​ Modular and Extensible: Applications can be added, removed, or updated without
affecting core services.​

4.​ Protocol Flexibility: Supports OpenFlow, NETCONF, OVSDB, BGP-LS, and more.​

5.​ Real-Time Network Control: Event-driven design allows ONOS to respond

instantly to network changes.​

6.​ Northbound API Support: Provides REST, gRPC, and Java APIs for application
integration.​

7.​ Fault Tolerance: Distributed data store ensures consistency and resilience against
node failures.​

Advantages of ONOS
●​ Carrier-grade reliability: Designed for service providers and large networks.​

●​ Centralized control with distributed resilience: Combines programmability with

fault tolerance.​

●​ Multi-vendor support: Can manage heterogeneous devices from different vendors.​

●​ Dynamic policy enforcement: Real-time adjustments to traffic, security, and QoS.​

●​ Support for network virtualization: Enables flexible, isolated virtual networks for
tenants or applications.​

Use Cases
1.​ Service Provider Networks: High scalability and fault-tolerant operation for ISPs
and telecom networks.​

2.​ Data Center Networking: Automates flow management, traffic engineering, and
virtual networks.​
 3.​ Campus and Enterprise Networks: Centralized control over switches, wireless
access points, and security devices.​

4.​ Network Security: Implements dynamic firewalls, access policies, and intrusion
detection.​

5.​ Research and Experimentation: Provides a platform for SDN research and testing
innovative network applications.​

Conclusion
ONOS is a powerful, scalable, and resilient SDN controller tailored for large-scale
networks, especially in service provider and enterprise environments. Its distributed
architecture, modular design, protocol support, and programmable APIs make it ideal for
managing complex, heterogeneous networks. By enabling centralized intelligence,
dynamic policy enforcement, and real-time monitoring, ONOS transforms traditional
networks into flexible, automated, and fault-tolerant SDN environments, fulfilling the core
promises of software-defined networking.