Advanced Computer Networking
ITec5114/CoSc5111
Semester I
2025-26
Chapter 04
Software Defined Networks(SDN)
• SDN and OpenFlow
• Data Plane
• Control Plane
• Application Plane
Evolving Network Requirements
As networks face an ever-increasing volume and variety of traffic, traditional architectures
struggle to meet the demands of Quality of Service (QoS) and Quality of Experience (QoE).
This challenge arises due to several driving factors:
Demand Drivers
• Big Data: Massive datasets generated and consumed globally require high-throughput,
low-latency networks.
• Cloud Computing: Scalable and reliable connectivity is crucial for remote data centers and
service hosting.
• IoT: The growth of smart devices adds to the complexity and diversity of network traffic.
• Mobile Traffic: Smartphones and mobile applications increase the need for flexible, high-
capacity networks.
Supply Enhancers
• 4G and 5G Networks: These technologies offer higher bandwidth, lower latency, and
better support for diverse applications.
• Fast Routers and Switches: Advanced hardware accelerates data transmission and
improves traffic management.
Challenges in Traditional Network Architectures
• Two-Level End System Addressing (MAC): Fixed and hierarchical addressing schemes
lack flexibility for modern traffic patterns.
• Routing Based on Destination (IP): Static routing is inefficient for dynamic and highly
diverse traffic.
• Distributed, Autonomous Control: Traditional decentralized control struggles with rapid
scaling and complex policy implementations.
• Traffic Complexity: Increasingly irregular and application-specific traffic patterns make
static configurations obsolete.
The Need for Adaptability and Scalability
To address these challenges, modern networks must become:
• More Adaptable: Capable of reconfiguring dynamically to accommodate changing
demands.
• More Scalable: Able to support the exponential growth of devices and data.
Key Enabling Technologies
• Software Defined Networking (SDN)
• Centralized control plane.
• Programmable networks enabling dynamic policy implementation.
• Efficient management of complex traffic patterns.
• Network Functions Virtualization (NFV)
• Decoupling network functions from dedicated hardware.
• Virtualized services for agility and cost-effectiveness.
• Faster deployment and scaling of network services.
4.1 Software Defined Networking (SDN)
• SDN is to replace the traditional networking model.
• It provides an enhanced level of flexibility and customizability to meet the
needs of newer networking and IT trends such as cloud, mobility, social
networking, and video.
• Centralized Control in SDN
• Control Plane (Routing, Monitoring, Traffic)
• Data Plane(Forwarding Packets)
• Application Plane (Policy, Analyze Traffic, Services(QoS))
SDN Key Characteristics
• Separation of data and control plan.
• Control plane is implemented in controller(s)
• SDN controller has a centralized view of the network.
• Open interfaces are defined between the control plane (controller) and
data plane (network devices).
• The network is programmable by applications
4.2 SDN Data Plane
• Also Known as Resource layer
• Also referred as Infrastructure layer
• Network forwarding devices perform the transport of packet and
processing of data packet
• Data plane network elements are switches
• According to decisions made by the SDN control plane. These devices
perform a simple forwarding function
Data Plane Functions
Data plane network elements or devices are switches
Data Plane Functions
A. Control support function:
• Interacts with the SDN control layer to support programmability via resource
control interfaces.
• The switch communicates with the controller and the controller manages the
switch via the Open Flow switch protocol.
B. Data forwarding function:
• Accepts incoming data flows from other network devices and end systems
and forwards them along the paths that have been computed and established
according to the rules defined by the SDN applications.
OpenFlow:
To implement SDN, two key requirements are:
1. A common logical architecture in network devices (switches/routers)
managed by the SDN controller.
2. A standard, secure protocol for communication between the controller
and devices.
OpenFlow addresses these needs as both a protocol for controller-device
communication and a specification for the logical structure of switch
functionality.
OpenFlow Environment
OpenFlow Switch
Physical port:
• Corresponds to a hardware interface of the switch. For example, on an Ethernet
switch
Logical port:
• Does not correspond directly to a hardware interface of the switch.
• Logical ports are higher-level abstractions that may be defined in the switch using
non-OpenFlow methods
Reserved port:
• Defined by the OpenFlow specification.
• It specifies forwarding actions such as sending to and receiving from the controller,
flooding, or forwarding using non-OpenFlow methods, such as “normal” switch
processing.
The OpenFlow specification defines three types of tables in the logical switch
architecture.
Flow Table:
• Matches incoming packets to specific flows.
• Defines actions to be taken on matching packets (e.g., forwarding, dropping,
modifying).
• Can be organized in a pipeline for sequential processing.
Group Table:
• Can be referenced by flow table rules.
• Triggers actions on multiple flows simultaneously (e.g., load balancing, multicast).
Meter Table:
• Monitors traffic flow and triggers actions based on performance metrics (e.g., rate
limiting, policing).
Flow Table Structure
Match fields: Used to select packets that match the values in the fields.
Priority: Relative priority of table entries. This is a 16-bit field with 0
corresponding to the lowest priority. In principle, there could be 216 = 64k
priority levels.
Counters: The OpenFlow specification defines a variety of counters.
Instructions: Instructions to be performed if a match occurs.
Timeouts: Maximum amount of idle time before a flow is expired by the
switch. Each flow entry has an idle_timeout and a hard_timeout associated
with it.
Cookie: 64-bit data value chosen by the controller. May be used by the
controller to filter flow statistics, flow modification and flow deletion; not
used when processing packets.
Flags: Flags alter the way flow entries are managed; for example, the flag
OFPFF_SEND_FLOW_REM triggers flow removed messages for that flow
entry
Ingress port: The identifier of the port on this switch on which the packet arrived. This
may be a physical port or a switch-defined virtual port.
Egress port: The identifier of the egress port on this switch on which the packet exit from
the device.
Ethernet source and destination addresses: Exact address are checked.
Ethernet type field: Indicates type of the Ethernet packet payload(0x0800 (IPv4): Indicates
an IPv4 packet).
IP: Version 4 or 6.
IPv4 or IPv6 source address, and destination address: Each entry can be an exact
address, a subnet mask value.
TCP source and destination ports: Exact match
Group identifier: A 32-bit unsigned integer uniquely identifying the group.
A group is defined as an entry in the group table.
Group type: To determine group semantics, as explained
subsequently(ALL, SELECT, INDIRECT).
Counters: Updated when packets are processed by a group.
Action buckets: An ordered list of action buckets, where each action bucket
contains a set of actions to execute and associated parameters
4.3 SDN Control Plane
• The SDN control layer maps application layer service requests into specific commands
and directives to data plane switches
• Supplies different applications with information about data plane topology and
activity. Example: Network Monitoring Application
• The control layer is implemented as a server or cooperating set of servers known as
SDN controllers.
• Network Operating System (NOS)provides essential functions(Services), and common
application programming interfaces (APIs)
Control Plane Functions
Shortest path forwarding: Uses routing information collected from switches to
establish preferred routes.
Notification manager: Receives, processes, and forwards to an application events,
such as alarm notifications, security alarms, and state changes.
Security mechanisms: Provides isolation and security enforcement between
applications and services.
Topology manager: Builds and maintains switch interconnection topology
information.
Statistics manager: Collects data on traffic through the switches.
Device manager: Configures switch parameters and attributes and manages flow
tables
SDN Controller Implementaion
A number of different initiatives both commercial and open source, have resulted in
SDN controller implementations.
• OpenDaylight
• Open Network Operating System (ONOS)
• POX
• Beacon
• Floodlight
• Ryu
• Onix
SDN Controller Interface
Southbound Interface
• The southbound interface provides the logical connection between the SDN controller
and the data plane switches
• Some support only a single southbound protocol.
• A more flexible approach supporting multiple southbound APIs.
• Most commenly implemented Southbound API is OpenFlow protocol
• Some other SouthBound Interfaces:
• Open vSwitch Database Management Protocol
• Forwarding and Control Element Separation (ForCES)
• Protocol Oblivious Forwarding (POF)
Northbound Interface
The northbound interface enables applications to access control plane functions
and services without needing to know the details of the underlying network
switches.
REpresentational State Transfer (REST)
• An architectural style used to define APIs.
• Standard way of constructing northbound APIs.
• Six constraints that an API must follow to be RESTful.
• Client-server
• Stateless
• Cache
• Uniform interface
• Layered system
• Code on demand
Client-Server Constraint:
• Interaction between application and server in the client-server request/response style.
Stateless Constraint:
• The stateless constraint dictates that each request from a client to a server must contain
all the information necessary to understand the request and cannot take advantage of
any stored context on the server.
• Similarly, each response from the server must contain all the desired information for
that request. One consequence is that any “memory” of a transaction is maintained in a
session state kept entirely on the client.
• REST typically runs over Hypertext Transfer Protocol (HTTP), which is a stateless
protocol
Cache Constraint:
• The cache constraint requires that the data within a response to a request be implicitly
or explicitly labeled as cacheable or noncacheable.
• If a response is cacheable, then a client cache is given the right to reuse that response
data for later, equivalent requests.
• Therefore, subsequent requests for the same data can be handled locally at the client,
reducing communication overhead between client and server, and reducing the
server’s processing burden.
Uniform Interface Constraint:
• REST emphasizes a uniform interface between components
To obtain a uniform interface, REST defines four interface constraints:
• Identification of resources: Individual resources are identified using a resource
identifier (for example, a URI).
• Manipulation of resources through representations: Resources are represented in a
format like JSON, XML, or HTML.
• Self-descriptive messages: Each message has enough information to describe how the
message is to be processed.
• Hypermedia as the engine of the application state: A client needs no prior knowledge
of how to interact with a server, because dynamically provided by the server.
Layered System Constraint:
• The layered system constraint means that a given function is organized in layers, with
each layer only having direct interaction with the layers immediately above and below.
Code-on-Demand Constraint
• REST allows client functionality to be extended by downloading and executing code in
the form of applets or scripts.
• This simplifies clients by reducing the number of features required to be pre-
implemented.
• Allowing features to be downloaded after deployment improves system extensibility
Cooperation and Coordination Among Controllers
• A key architectural design issue is to decide:
• Whether a single centralized controller or a distributed set of controllers will be used.
• A centralized controller is a single server that manages all the data plane switches.
• Large enterprise divides the whole network into a number of nonoverlapping SDN
domains, managed by distributed controllers.
Centralized Versus Distributed Controllers
Reasons for using SDN domains
Scalability: The number of devices an SDN controller can feasibly manage is limited.
Therefore, a reasonably large network may need to deploy multiple SDN controllers.
Reliability: The use of multiple controllers avoids the risk of a single point of failure.
Privacy: A carrier may choose to implement different privacy policies in different SDN
domains. For example, an SDN domain may be dedicated to a set of customers who
implement their own highly customized privacy policies
Incremental deployment: A carrier’s network may consist of portions of legacy and
nonlegacy infrastructure. Dividing the network into multiple individually manageable
SDN domains allows for flexible incremental deployment.
SDN Application Plane
Core SDN Applications
Data Center Networking
• Handles virtual networks, cloud resources, routing inside data centers.
Mobility & Wireless
• Supports handovers, wireless access control, QoS for mobile users.
Information-Centric Networking (ICN)
• Provides content-based routing and efficient content distribution.
Traffic Engineering
• Optimizes routing paths to reduce congestion and improve throughput.
Measurement & Monitoring
• Collects real-time network statistics and provides analytics.
Security & Dependability
• Enforces security policies, authentication, anomaly detection, and failover.
Network Services Abstraction layer
• Its available between the control and application planes
Several functional concepts suggested by the placement of this layer in the SDN architecture:
• This layer could provide an abstract view of network resources that hides the details of the
underlying data plane devices.
• This layer could provide a generalized view of control plane functionality, so applications
could be written that would operate across a range of controller network operating
systems.
• This functionality is similar to that of a hypervisor or virtual machine monitor
• This layer could provide a network virtualization capability that allows different views of
the underlying data plane infrastructure.
