The document outlines the architecture and ecosystem of Software-Defined Networking (SDN), detailing the types of SDN switches, controllers, and their functionalities. It discusses migration plans for transitioning to SDN, security challenges associated with centralized control and programmability, as well as hands-on activities with the Ryu controller and Mininet. Key concepts such as topology discovery, controller redundancy, and the differences between imperative and declarative programming models in network management are also explored.

1. SDN Architecture and Ecosystem
S. Kingston Smiler
kingstonsmiler@gmail.com

2. Course Objective
SDN Architecture and Ecosystem
SDN switch Ecosystem
SDN Controller Ecosystem
Placement of Controller
SDN Migration Plan
SDN Security
Hands-On with RYU Controller

3. SDN Architecture Model

4. SDN Switch Ecosystem

5. Introduction to OpenFlow Switches
• Hardware-based OpenFlow Switches
– Commercial hardware switches with OpenFlow capability
• Network abstraction is realized by firmware upgrading
– Show high processing speed
– Have space limitation on saving the flow table entries
• Approximately store 1500 flow entries (due to expensive CAM)
– Not easy to upgrade
• Most switches only support OpenFlow up to version 1.0
• Software-based OpenFlow Switches
– OpenFlow enabled software switch (runs on x86 commodity computer)
– Performance is relatively low
– Store large amount of flow entries with bound (theoretically)
– Under active development, support most recent OpenFlow spec.
• Hybrid OpenFlow Switch
– Supports both openflow as well as traditional routing / switching
– Much faster than software-based switches

6. Hardware-based OpenFlow Switches

7. Software-based OpenFlow Switches (1/3)
• OpenvSwitch (OVS)
– Overview
• A virtual switch or Virtual Ethernet Bridge (VEB)
• User-space: configuration, control
• Kernel-space: datapath (included in main Linux kernel from v3.3)
– Features
• Support OpenFlow protocol
• Support multiple tunneling protocols
– VxLAN, Ethernet over GRE, IPsec, GRE over IPsec
• Fine-grained QoS
– Main components
• ovs-vswitchd: a daemon that implements the switch
• ovsdb-server: lightweight database server that ovs-vswitch queries to
• ovs-vsctl: a utility for querying and updating the config. of ovs-vswitchd
• ovs-dpctl: a tool for configuring and monitoring the switch kernel module
• ovs-ofctl: a tool for monitoring and administering OpenFlow switches
• ovs-controller: a simple OpenFlow controller reference implementation
• openvswitch.ko: OpenvSwitch switching datapath

8. Hybrid Switch Approaches

9. SIN – With Default Gateway

10. Hybrid Switch – OFNormal

11. Hybrid Switch based on Port + Vlan

12. SDN Controller Ecosystem & Anatomy

13. Controller Architecture
Imperative Declarative
Legacy Architecture Next-Gen Architecture

14. Imperative Vs Declarative
• Declarative : A programming paradigm that expresses the logic of a
computation without describing its control flow. Many languages
applying this style to minimize or eliminate side effects by describing
what the program should accomplish, rather than describing how to
go about accomplishing it
• Imperative : A programming paradigm that describes computation in
terms of statements that change a program state. Imperative
programs define sequences of commands for the computer to
perform

15. Imperative Controller Architecture
• Imperative is a top down approach
to managing the network
• where network state is held and
managed by the controller and
pushed down to the network
elements
• This may lead to scale limitations
for the controller as the network
grows
• Openflow is an example of an
implementation of the
imperative model

16. Declarative Controller Architecture
• Declarative model uses bottom up
approach to manage the network
• where the physical switches
handle the network state and the
state is defined by the policies
created by the controller
• The “Declarative” model scales
much better
• APIC controller is an example of
an implementation of the
Declarative model

17. Centralized vs De-centralized vs Distributed Models

18. Centralized vs De-centralized vs Distributed Models

19. Anatomy of SDN Controllers

20. Anatomy of SDN Controllers

21. Anatomy of SDN Controllers
• SDN-enabled Applications
– Communicate their requirements/polices to the network
– Can monitor network state and adapt accordingly
• SDN Network Controller
– Controller translates from app requirement to low-level rules
– Controller summarizes the network state for applications
• SDN Datapath
– Programmatic low-level control of all fwd’ing and configuration
– API for Capabilities advertisement and publishing statistics
– No resource contention with other entities
– Controller “owns” this device, subject to capabilities advertisement /
negotiation

22. Controller Redundancy
• Single Switch can be controlled by more than one controller for load
balancing or redundancy purpose
• The controller takes anyone of the following role
– Master
– Slave
– Equal

23. Controller Redundancy
Master Equal Master - Slave

24. Controller Topology Discovery

25. Topology Discovery Protocols
OFDP LLDP
OpenFlow Discovery Protocol
• Implemented by most SDN
controllers and de facto
standard
• OFDP leverages the packet
format of LLDP
• OFDP operates completely
differently
Link Layer Discovery Protocol
• IEEE 802.1AB
• Used in traditional Ethernet
network devices

26. Topology Discovery Operations
OpenFlow Discovery Protocol
• Controller injects LLDP
packets (Link Layer
Discovery Protocol)
• Switches flood them to all
ports

27. Topology Discovery Operations
OpenFlow Discovery Protocol
• Other switches receive
packets and report packet-
in to controller.
• Controller learns topology
from information about
incoming ports

28. Topology Discovery Operations

29. SDN – North Bound Interface

30. SDN – First Stage

31. SDN – Second Stage

32. SDN – Third Stage

33. Intent Based SDN

34. Controller Placement – Who Cares

35. SDN Controller Placement Considerations
Single
Controller /
Multiple
Controllers?
Redundant /
Load Sharing?
Cluster /
Independent?
Inband / Out
of Band

36. Challenges in SDN
Scalability
Reliability
Inter-operability
Fault Tolerance

37. Controller Scalability – Handling Multiple Switches

38. Controller Scalability – Handling Multiple Switches
• Is it really a problem?
– Nox can handle more than 30k requests / sec with multicore CPU
– This is fine for decent size enterprise, however for data center this is a
problem.
• Solution
– Multiple Controllers with auxiliary connections
– Proactive programming of Flow table entries
– Deploy hybrid switch with locally scoped application / protocol in the switch
itself
– Keep the controller close to the switch network.

39. Controller Scalability – Handling Flow Events from Switch

40. Controller Scalability – Handling Flow Events From Switch
• Is it really a problem?
– Performance of first three step depends on the capability and positioning of
controller
• When the controllers are placed on close proximity it is negligible
– Performance of last step depends on the Switch
• OVS is capable of installing Tens of thousands of flows per second
• Most of the hardware supports few thousands of flows per second
• Solution
– Proactive programming of Flow table entries
– Keep the controller close to the switch network.

41. Controller Reliability

42. Fault Tolerance

43. Fault Tolerance – Link Failure
• Is it really a problem?
– Takes 5 steps to detect and recover from the link failure
– Traditional network devices detects the link failure very fast. However the
link failure event is flooded across the network via some protocols.
– In SDN network it is not required.
– The failure recovery process in SDN is no worse than in traditional network.
• Solution
– Proactive programming of Flow table entries
– Keep the controller close to the switch network.

44. In-Band Vs Out-of-Band
• Out-of-Band: Separate network / link for controller switch
connections
• In-Band: Attaching controller to a switch in a data plane

45. SDN Migration Plan

46. Key Questions to be asked
• What are my goals for migrating to open SDN?
• What are the initial steps I should take to achieve my goals for
SDN?
• What are my migration options?
• How have others performed the migration , and how different
from their strategies is my current SDN migration plan?

47. Key Steps for Migration
• Identify and prioritize the core requirements of the target
network
• Prepare the starting network for migration
• Implement a phased network migration
• Validate the results

48. Migration Approaches: Greenfield

49. Migration Approaches: Mixed

50. Migration Approaches: Hybrid

51. Migration Approaches: Hierarchical

52. Migration Approaches: Hierarchical

53. SDN Migration Case Study (Google)

54. Key Questions to be asked
• What are my goals for migrating to open SDN?
• What are the initial steps I should take to achieve my goals for
SDN?
• What are my migration options?
• How have others performed the migration , and how different
from their strategies is my current SDN migration plan?

55. Two Kind of Networks
To improve scalability, flexibility, and agility in managing the Internet-facing
WAN fabric to enhance Google’s user-based services, including Google+,
Gmail, YouTube, Google Maps, and others
Internet
-facing
user traffic
Internal
traffic between
Google’s global data
centers

56. Starting Network
Fully distributed monolithic control and data plane hardware architecture to
a physically decentralized (though logically centralized) control plane
architecture

57. Phased deployment
A subset of the nodes in the network were OpenFlow-enabled and controlled
by the logically centralized controller utilizing Paxos, an OpenFlow controller,
and Quagga open source routing stack that Google adapted to its
requirements

58. Complete OpenFlow
All nodes were OpenFlow-enabled. In the target network, the controller controls the
entire network. There is no direct correspondence between the data center and the
network. The controller also has a TE server that guides the traffic engineering in the
network.

59. Final Deployment

60. SDN Security Challenges

61. Threat Challenges
Centralized Control
Programmability
Cross Domain
Connection
Challenge of Integrating
Legacy Protocols

62. Centralized Control
• Exposes a high-value asset to attackers
• Attackers may attempt to manipulate the common network
services or even control the entire network by tricking or
compromising a controller
• Unauthorized Access to centralized controller using Password
Brute-Forcing or Password-Guessing Attacks
• Unauthorized Access Using Remote Application Exploitation
Attacks

63. Programmability
• Traffic and resource isolation
• Trust between third party
applications and the
controller
• Interface Security protection
across controllers

64. SDN Threat Models
Generic network
infrastructure threats
SDN specific Threats
Network Virtualization
Threats

65. Generic network infrastructure threats
Generic Threats
Physical threats
Damage/loss.
Failures/malfunctions
Outages / Disaster / Legal

66. Generic network infrastructure threats
Traffic
diversion
DOS
Data
forging
Flooding
attack
Side
channel
attack
Software
exploits
API
exploita
tion
Identity
spoofing
Traffic
sniffing
Memory
scraping

67. SDN Reference Architecture Threats

68. Hands-on

69. Course Objective
How to run RYU Controller
How to run RYU features
Creating a network with Mininet
Programming a flow entry with RYU
Ping and test the Network

70. How to start RYU Controller
 Run the given VM in
Virtual Box
 Goto
/home/ubuntu/ryu
 cd /home/ubuntu/ryu
 Run ./bin/ryu-manager
ryu/app/simple_switch.
py ryu/app/ofctl_rest.py
 Run ./bin/ryu-manager ryu/app/simple_switch.py ryu/app/ofctl_rest.py

71. Mininet
 Mininet creates a realistic OpenFlow network, running real
kernel, switch and application code, on a single machine (VM,
cloud or native), in seconds, with a single command
 sudo mn --topo single,3 --mac --switch ovsk --controller remote
 sudo ovs-ofctl -O OpenFlow13 dump-flows s1
 sudo ovs-vsctl show

72. Postman
 Postman is a most popular HTTP Request composer that makes
it easy to call web services.
 Search postman firefox in google. There will be a link for
Firefox addon.
 Install that link and open the window.
 You will get a window similar to this

73. Postman
 To add a flow in the switch
 http://127.0.0.1:8080/stats/flowentry/add
{
"dpid": 1,
"cookie": 42,
"priority": 45000,
"match": {
"in_port": 3
},
"actions": []
}

74. Postman
 To add a flow in the switch
 http://127.0.0.1:8080/stats/flowentry/delete_strict
{
"dpid": 1,
"actions": [],
"idle_timeout": 0,
"cookie": 42,
"hard_timeout": 0,
"priority": 45000,
"table_id": 0,
"match": {
"in_port": 3
}
}

75. Thank you