SDN Application Plane Architecture

 Hosts applications/services that define, monitor, and control network behavior.

 Interacts with the control plane via application-control interfaces.
 Uses an abstracted view of network resources from the control layer.
 Enables customized network behavior through programming and data models.
 The elements shown in the figure are analyzed through a bottom-up approach,
and subsequent sections provide detail on specific application areas.
SDN Application Plane Architecture
NORTHBOUND INTERFACE:
 Connects SDN applications to the control plane, hiding switch-level
details.
 Provides an abstract view of network resources.
 It can be:
 Local: App and controller run on same server.
 Remote: App connects via API/protocol to controller NOS.
 Example: REST API
 It supports both centralized and distributed application architectures.
NETWORK SERVICES ABSTRACTION LAYER:
 It as a layer that provides service abstractions that can be used by
applications and services.
 Several functional concepts are suggested by the placement of this
layer in the SDN architecture:
 Hides data plane details.
 Generalizes control plane functions across different NOS.
 Acts like a hypervisor, decoupling apps from OS/hardware.
 Enables network virtualization with multiple infrastructure views.
SDN Application Plane Architecture
NETWORK APPLICATIONS:

 Wide variety of applications possible in SDN environments.

 Different studies propose varied categories of SDN apps.

 As shown in Figure, it outlines six major categories covering most

SDN applications.

USER INTERFACE:

 Allows users to configure SDN application parameters and interact

with apps.

 Two interface types:

 Local: Direct access via server’s keyboard/display.
 Remote: Access over a network connection.

 Supports flexible management and control of SDN apps.

Network Services Abstraction Layer
Network Services Abstraction Layer
 Abstraction refers to the amount of detail about lower levels of the
model that is visible to higher levels.
 Abstraction Layer: Translates high-level requests to low-level
commands (e.g., APIs).
 Network Abstraction layer which models the entities like switches,
links, ports, and flows for easier programming.
 Goal is to focus on desired functionality but not implementation.
 Scott Shenker (ONF) defines SDN by 3 key abstractions:
 Forwarding
 Distribution
 Specification
FORWARDING ABSTRACTION:
 It enables control programs to define data plane behavior and hides
hardware details of underlying switches.
 It Provides vendor neutrality and flexibility in forwarding logic and
supports core data plane forwarding functions.
 Example: OpenFlow API
Network Services Abstraction Layer
DISTRIBUTION ABSTRACTION:
 This abstraction arises in the context of distributed controllers.
 Distributed controllers cooperate to manage network state and routing.
 Network state can be: Partitioned: Controllers exchange routing info
(OR) Replicated: Controllers maintain consistency.
 Goal: Hide distributed complexity, separate state management from
protocol logic.
 Provides a coherent global view of the network via an annotated graph
API.
 Examples: Network Operating Systems (NOS) like OpenDaylight,
Ryu.
SPECIFICATION ABSTRACTION:
 Builds on the distribution abstraction to offer a global network
view.
 Exposes just enough detail for applications to define goals (e.g.,
routing or security).
 Hides implementation details — focuses on what to achieve, not
how to achieve it.
Frenetic Architecture

 Frenetic: A programming language for network-wide configuration, simplifying network

operations.
 Solves Challenges: Works at the network level, unlike OpenFlow which configures
individual elements.
 Features:
 Embedded query language (similar to SQL) for reading network state.
 Supports selecting, filtering, splitting, merging, and aggregating packet streams.
 Queries can be composed with forwarding policies.
 Two Levels of Abstraction:
 Upper level: API for manipulating network traffic streams.
 Lower level: Run-time system that translates policies into OpenFlow flow rules.
Frenetic Architecture
 Example: Two Levels of Abstraction in Frenetic
 Problem: Intertwining forwarding and monitoring logic in OpenFlow
leads to complex code.
 Python Example: Manually installs forwarding rules and queries
switch statistics but changes affect both forwarding and monitoring
functions.
 With Frenetic:
 Forwarding and web monitoring functions are separated for
simplicity.
 Code Example:
 repeater(): Installs forwarding rules.
 web_monitor(): Polls for web traffic statistics.
 Benefits: Easy to modify or swap parts of the program without
affecting other components.
 Runtime System: Manages OpenFlow rules and ensures both
forwarding and monitoring functionalities work together.
Traffic Engineering
 Traffic Engineering: Dynamically analyzes and optimizes data flow to
meet Service Level Agreement’s (SLAs) and QoS requirements.
 Benefits with SDN:
 Simplifies traffic engineering through a global network view and
powerful tools for managing switches.
 Facilitates dynamic routing and forwarding policies.
 Implemented SDN Traffic Engineering Functions:
 On-demand VPNs
 Load balancing
 Energy-aware routing
 QoS for broadband access
 Dynamic QoS routing (for multimedia apps)
 Fast recovery via fast-failover groups
 QoS policy management & enforcement
 Multiple packet schedulers
 Queue management for QoS
 Divide & spread forwarding tables.
PolicyCop
PolicyCop
PolicyCop: SDN-Based QoS Policy Enforcement
 PolicyCop is an automated QoS policy framework using
SDN/OpenFlow.
 Key Features:
 Dynamic traffic steering
 Flow-level control & aggregation
 Adaptive traffic classes
 Policy violation detection & response
 Architecture:
 11 modules + 2 databases across application and control planes.
 Monitors QoS compliance and dynamically reconfigures network
behavior.
 Control Plane Components:
 Admission Control: Manages resource requests.
 Routing: Determines paths using control rules.
 Device Tracker: Monitors switch/port status.
 Statistics Collection: Measures network performance.
 Rule Database: Stores control rules from high-level policies.
PolicyCop
PolicyCop: Application Plane Modules
 RESTful Northbound Interface connects control and application
planes.
 Two Main Components:
 Policy Validator: Detects policy violations.
 Policy Enforcer: Adjusts control rules based on conditions.
 Supported by a Policy Database (QoS rules from network manager)
 Application Plane Modules:
 Traffic Monitor: Selects monitoring scope, intervals, and metrics.
 Policy Checker: Detects violations using database inputs.
 Event Handler: Triggers enforcement or alerts network manager.
 Topology Manager: Maintains network view.
 Resource Manager: Tracks and manages resource allocation.
 Policy Adaptation: Executes tailored responses to policy violations.
 Resource Provisioning: Allocates/releases resources as needed.
Workflow in PolicyCop
Measurement and Monitoring
 Divided into two categories:
 Enhancing other networking services (E.g., broadband home networks)
 Adds dynamic monitoring & traffic demand analysis.
 Improving OpenFlow-based SDNs
 Uses sampling & estimation to minimize control plane load when
collecting data plane statistics.
 Goal: Improve responsiveness and reduce monitoring overhead in SDN
environments.
Security
Security Applications in SDN
 Two Main Goals:
 Secure SDN Architecture
 Protect against threats across application, control, and data planes.
 Secure inter-layer communication and distributed control.
 Enhance Network Security Using SDN
 SDN enables centralized, programmable security policies.
 Supports security controllers and orchestrated security services.
 Outcome: Stronger, more flexible network-wide security enforcement.
OpenDaylight DDoS Application – Defense4All
 Developed by Radware, integrated with the OpenDaylight Project
(2014).
 Defense4All is an open SDN security app for Distributed Denial of
service (DDoS) detection and mitigation.
 Leverages OpenDaylight SDN Controller to embed protection within
the network.
 Enables per-customer or per-segment DDoS protection for carriers
and cloud providers.
 Peacetime Learning: Builds traffic baselines using flow statistics.
 DDoS Detection: Flags 80%+ deviation from baseline as an attack.
 Mitigation via Access Management System (AMS) (e.g., Radware
DefensePro):
 Validates AMS, configures security policies.
 Diverts and scrubs suspicious traffic via OpenFlow.
 Reinjects clean traffic back to original destination.
 Monitors system logs from AMS to confirm attack status.
OpenDaylight DDoS Application – Defense4All

Defense4All Architecture & Operation:

 Runs over OpenDaylight Controller using Northbound API.
 Provides Command Line Interface or RESTful interface for network managers.
 Communicates with AMS for mitigation.
 Protects specified networks/servers (Protected Networks/Protected Objects).
 Installs traffic counters via SDN controller for each protocol.
 Monitors traffic in real time using OpenFlow.
 Declares DDoS attack if traffic deviates >80% from baseline.
OpenDaylight DDoS Application – Defense4All

Defense4All – Attack Mitigation Process:

1. Verifies AMS (e.g., DefensePro) is active and connected.

2. Configures AMS with security policy and normal traffic rates.

3. Monitors AMS system logs for attack alerts and continues traffic

diversion during alerts.

4. Maps AMS to affected link using OpenFlow.

5. Installs high-priority flow rules to redirect & re-inject clean traffic.

6. Post-attack: Removes flow rules, stops monitoring, resets AMS

configure.
OpenDaylight DDoS Application – Defense4All
OpenDaylight DDoS Application – Defense4All
Defense4All Software Architecture – Key Components:
1. Web (REST) Server: Interface for network manager.
2. Framework Main: Starts, stops, resets framework.
3. REST Service: Handles user REST requests.
4. Management Point: Coordinates control/configuration commands.
5. Defense4All App: Core functionality (described separately).
6. Common Classes/Utilities: Shared codebase for all modules.
7. Repository Services: Stores durable state; supports
replication/distribution.
8. Logging & Flight Recorder: Logs & runtime metrics for developers.
9. Health Tracker: Monitors app health and triggers responses.
10. Cluster Manager: Manages multi-instance coordination.
OpenDaylight DDoS Application – Defense4All
Defense4All Application Module – Key Elements:
1. DF App Root: Main application module.
2. DF REST Service: Handles REST requests.
3. DF Management Point: Orchestrates control / configuration
commands.
4. ODL Reps: Interfaces with OpenDaylight Controller (ODC); manages
stats & traffic diversion.
5. SDN Stats Collector: Sets/reads OpenFlow counters for PNs; collects
traffic stats.
6. SDN-Based Detection Manager: Hosts detectors; identifies traffic
anomalies using stat reports.
7. Attack Decision Point: Manages attack lifecycle (detection →
resolution).
8. Mitigation Manager: Coordinates AMS-driven mitigation actions.
9. AMS-Based Detector: Monitors AMS activity.
10. AMS Rep: Interfaces with Attack Mitigation Systems.
OpenDaylight DDoS Application – Defense4All

Defense Flow: Advanced DDoS Protection:

 Defense Flow is Radware’s commercial version of Defense4All.

 Implements fuzzy logic-based detection algorithms.

 Key Benefit: Better distinguishes between DDoS attacks and

legitimate high-volume traffic.

 Reflects the complexity involved even in straightforward SDN

security applications
Data Center Networking

Data Center Requirements:

1. High bandwidth & low latency

2. Application-aware QoS

3. Resilience & energy-efficient resource use

4. Agile provisioning via virtualization & orchestration

SDN Benefits:

1. Simplifies configuration

2. Enhances responsiveness

3. Improves operational efficiency

Big Data over SDN
 Goal: Optimize data center networking for structured big data apps

 Approach: Application-aware networking via SDN

 Key Insights:

1. Big data apps have predictable computation patterns & centralized

control

2. SDN can react to these patterns by reconfiguring flows dynamically

 Optical Switching Advantage:

1. High data rates, lower cabling & energy use

2. Requires application-level traffic insight for optimal use

 Outcome: Better performance & resource utilization through SDN + big

data awareness
Big Data over SDN

 Architecture:
 OpenFlow-enabled Top of Rack (ToR) switches connect to Ethernet & Optical Circuit
Switch (OCS)
 SDN controller manages both optical paths & OpenFlow rules
 Integration:
 Connected to Hadoop Scheduler, HBase Master (database), and Mesos Cluster
Manager
 Functionality:
 SDN controller provides topology & traffic data to Mesos
 Accepts traffic demand input from Mesos
 Dynamically configures network based on big data traffic demands
 Outcome:
 Efficient, responsive data center network tailored to application needs
Cloud Networking over SDN
CloudNaaS – Cloud Networking as a
Service:
 Goal: Enables cloud customers to define
and control network functions (e.g.,
isolation, addressing, service quality,
middle boxes).
 Technology: Uses OpenFlow and high-
speed programmable network elements.
 Efficiency: Integrated directly into cloud
infrastructure for optimal performance.
CloudNaaS Operation Flow:
1. Customer defines network policies via a
simple language.
2. Cloud controller maps policies to a
communication matrix to optimize
Virtual Machines (VM) placement.
3. Matrix converted into network directives;
VMs are instantiated accordingly.
4. Directives are installed into network
devices using OpenFlow.
Cloud Networking over SDN
CloudNaaS: Abstract Network Model for Customers

 Customer View: VMs connected via virtual network segments.

 Policy Constructs:

 Address: Assign custom VM address.

 Group: Logically group VMs for simplified policy application.

 Middle box: Add/configure virtual middle boxes (e.g., IDS,

compliance tools).

 Network service: Attach services to virtual segments (e.g., QoS,

middle boxes, L2 domains).

 Virtual net: Connect groups of VMs; supports intra-group and inter-

group connections. Can include EXTERNAL group for outside-
cloud communication.
Cloud Networking over SDN
CloudNaaS Architecture Overview
 Key Components:
 Cloud Controller: Manages VM
lifecycle, programmable virtual
switches, and interprets user network
policies.
 Network Controller: Configures
virtual/physical switches using a
communication matrix from the cloud
controller.
 Process Flow:
 User submits VM + network service
requests.
 Cloud Controller builds communication
matrix.
 Network Controller:
 Configures data plane switches.
 Manages VM placement (via
placement optimizer).
 Monitors traffic/performance and
adjusts resources via the network
provisioner.
 Outcome: Users can define and manage
virtual networks with control over QoS,
middle boxes, and service isolation.
Mobility and Wireless
SDN in Wireless Networks
 Challenges in Wireless Networks:
1. Spectrum management
2. Efficient handovers
3. Load balancing
4. QoS/QoE support
5. Security and interoperability
 SDN Advantages:
1. Seamless mobility & dynamic handovers
2. On-demand virtual access points
3. Intelligent downlink scheduling
4. Dynamic spectrum allocation
5. Intercell interference coordination
6. Resource block management (per client/base station)
7. Simplified administration & heterogeneous network management
 Trend: Rapid growth of SDN-based wireless applications
Information-Centric Networking (ICN)
 ICN Overview:
 Focus on content rather than host-to-host communication
 Information is named & retrieved independently of location
 Separates identity from location
 Key Benefits:
 Efficient content retrieval
 Native support for caching & replication
 Routing based on information names, not host addresses
 Challenges:
 Requires ICN-compatible routing hardware
 Changes from host-to-user to content-to-user delivery
 Needs new forwarding and control separation
 SDN as Enabler:
 Programmable forwarding planes
 Supports ICN via enhanced OpenFlow or abstraction layers
 Proposed Integration Approaches:
 OpenFlow protocol extensions
 Hash-based name-to-IP mapping
 Using IP option headers for names
 Abstraction layer with OF switch + ICN router (e.g., via CCNx)
CCNx
 Developed by: PARC (Open Source)
 Communication Model:
 Interest Packets: Request named content
 Content Packets: Satisfy matching Interests
 Content can be cached and served by any CCN node
 Core Components of CCN Node:
 Content Store: Cached content
 Forwarding Info Base (FIB): Routes Interest packets
 Pending Interest Table (PIT): Tracks outstanding requests
 Networking via “Faces”:
 Connection points with specific attributes (latency, bandwidth, etc.)
 Caching Strategy:
 In-Path Caching: Caches content along delivery path.
 Off-Path Caching: Deflects traffic to optimized, distributed
caches→ Increases hit ratio and reduces bandwidth use.
ICN over SDN: Abstraction Layer Approach
 Challenge:
 ICN routes by content name, OF switches
route by IP/port fields
 Solution:
 Use a wrapper (abstraction layer) to connect
CCNx to OF switches
 Hashes content names into fields (e.g., IP
address) that OF can process
 OF switch forwards based on hashed values,
unaware of actual content
 Key Modules in SDN Controller:
 Measurement: Tracks content popularity via
OF flow stats
 Optimization:
 Ensures popular content cached at only
one node
 Avoids cache overflow & link congestion
 Deflection:
 Builds mapping from hashed content
name to interface
 Installs mappings in OF switches for
efficient routing
 Benefit:
 Enables CCN on existing SDN hardware
without modifying OF switches
ICN Packet Flow with Wrapper Abstraction Layer
 Flow Direction: From OF Switch to
CCNx (Shown in Part a Figure):
 OF switch sets Type of Service (ToS)
= incoming port ID, forwards packet
to wrapper.
 Wrapper maps ToS to CCNx face,
forwards Interest to face.
 If content found, CCNx returns
Content to wrapper.
 If not, Interest sent to special face W.
 Flow Direction: From CCNx to OF
Switch (Shown in Part b Figure):
 Wrapper hashes content name, sets it
as source IP
 Sets ToS = output port (for Content),
ToS = 0 (for Interest)
 Forwards packets to OF switch
 Content returned to requester via
stored Pending Interest Table (PIT)
entry
 Key Point:
 Wrapper enables ICN functionality
using unmodified OpenFlow switches
& CCNx modules