This document provides an overview of network programmability and Software Defined Networking (SDN). It discusses the evolution from traditional networks to SDN, including early concepts like active networking and separating the control and data planes. OpenFlow is introduced as an SDN protocol that enables an external controller to program the forwarding behavior of network switches. Key benefits of SDN like network programmability, innovation, and direct control over the data plane are covered. The roles of the SDN controller and OpenFlow switches are described. Examples of SDN applications and components like controllers are also mentioned.

1. Network Programmability: an Overview
Aymen Hasan Alawadi
aymen@tmit.bme.hu
University of Kufa
Faculty of Education, Department of Computer Science
Budapest University of Technology and Economics
Faculty of Electrical Engineering and Informatics
Department of Telecommunications and Media Informatics

2. NICK MCKEOWN
2
 A professor in the Electrical
Engineering and Computer
Science departments at
Stanford University.
 Father of OpenFlow
protocol.

3. AGENDA
 We are going to summarize and discuss two significant papers addressing the rise of network
programmability.
1. The Road to SDN: An Intellectual History of Programmable Networks.
Feamster, N., Rexford, J., & Zegura, E. (2013). The road to SDN. Queue, 11(12), 20-40.
2. OpenFlow: Enabling Innovation in Campus Networks.
McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford, J., ... & Turner, J. (2008). OpenFlow: enabling innovation in campus networks. ACM
SIGCOMM Computer Communication Review, 38(2), 69-74.
3. Some of the hands-on experiment on OpenFlow protocol.
3

4. 1. NETWORKING BASICS
4
Traditional network defenses are composed
of the following products:
1. Switches.
2. Router access lists
3. Firewalls.
4. Intrusion Detection Systems (IDS)
5. Virtual Private Networks (VPNs).
……etc.

5. 2. SDN ERA
 Software Defined Networking (SDN) is an exciting technology that enables innovation in
how we design and manage networks.
 Three are three periods before SDN era.
 Active networking
 Control and data plane separation
 OpenFlow and network Oses
5
1995 2001 2007
Active Networking Data and control plane
separation
OpenFlow and Network OS

6. 3. WHY SDN IS IMPORTANT
 How to separating control plane from data plane
 Control plane: is the part of a network that carries signaling traffic and is responsible for
routing (How to handle the traffic).
 Data plane: forwards traffic based on the decisions that the control plane made
Consolidates the control plane.
3. A single software program controls “multiple” data-plane elements.
4. Direct control over the data-plane element’s state via well-defined API (e.g., OpenFlow).
6

7. 3.1 SDN IS A HOT TOPIC
 Many interesting applications
 Dynamic access control, server load balancing, network virtualization, energy-
efficient networking, VM migration, etc.
 Many big Internet companies show interest.
 Open Networking Foundation (ONF).
 Open Daylight Initiative.
7

8. 4. ACTIVE NETWORKING 1990 - 2000
 Make each networking node
programmable
 Capsule mode: code to execute is
carried in-band in data packets
 Programmable router/switch model:
code to execute is established by out-
of-band mechanisms. (Simple
Network Management Protocol).
 First “clean-slate” approach to
network architecture.
8

9. 4.1 ACTIVE NETWORKING
Experiments we’d like to do new
 Network-wide energy management
 Network access control
 It’s too slow/hard to develop and deploy new services on the network (network ossification).
Problem with the network
 Paths are fixed
 IP-only
 Addresses dictated by DNS, DHCP, etc
 No means to add our own processing
9

10. 5. SEPARATING CONTROL AND DATA PLANES 2001 - 2007
 The Internet grows rapidly.
 Increasing traffic volumes and a greater emphasis on network reliability.
 Conventional routers/switches embody a tight integration between the control and data planes
 Debugging configuration problems is hard.
 Predicting/controlling routing behavior is hard.
Why not separate control and data planes?
These researchers made a near-term approaches base either standards-driven or imminently deployable
using existing protocols.
10

11. 5.1 SEPARATING CONTROL AND DATA PLANES
Compared to Active Networking:
 Focused on pressing problems in network management.
 By and for network administrators.
 Programmability in the control plane (rather than data plane).
 Network-wide visibility and control (rather than device-level
configuration).
11

12. 5.2 SEPARATING CONTROL AND DATA PLANES
 Technology push
 Packet forwarding implemented in hardware
 Servers have more memory and processing
power than control-plane processors in a router
 Open interface between the control/data planes
 ForCES (Forwarding and Control Element
Separation).
 Netlink interface in Linux.
 Logically-centralize control of the network
 Routing Control Platform (RCP)
12
BGP (Border Gateway Protocol)

13. 5.3 SEPARATING CONTROL AND DATA PLANES - PROBLEMS
 Criticism:
 Logically-centralized route control could fail independently from forwarding devices.
 Centralized route control: each router has a purely local view of the “outcome” of the
route selection.
 However, traditional distributed route selection also violates the principle
 Moving packet forwarding to hardware means that the control plane software could fail
independently from the data plane.
13

14. 6. SOFTWARE DEFINED NETWORKING (SDN) - ARCHITECTURE
 SDN broadly consists of three layers:
1. Application layer: Network
applications that leveraging all the
network information about network
topology, network state, network
statistics, etc.
2. Control layer: SDN controller and
framework.
3. Infrastructure layer: composed of
various networking equipment which
forms underlying network.
14

15. 7. OPENFLOW AND NETWORK OSES
 In a conventional switch, packet forwarding
(the data plane) and high-level routing (the
control plane) occur on the same device.
 SDN controller makes high-level routing
decisions to OpenFlow switches.
1. better link utilization.
2. better load balancing.
3. better monitoring.
4. development of new services and ideas all in
software on the SDN controller,
15

16. 7.1 OPENFLOW AND NETWORK OSES
 OpenFlow faces trade-offs
 Fully programmable vs. pragmatic real-world
deployment
 Enabling more functions than route
controllers.
 Building on commodity switches (limited
flexibility).
 OpenFlow API followed by NOX controller
1. Each rule has a pattern (matches bits on
header).
2. A list of actions (drop, flood, forward, modify a
header field, send the packet to controller)
3. Counters and priority
16

17. 7.2 OPENFLOW’S GOAL
 Put an open platform
 researchers/students to test new ideas at scale through production
networks
 without requiring vendors to expose internal workings
 Bring Future Internet to legacy Internet
 An open development environment for all researchers.
17

18. 7.3 WHAT IS OPENFLOW AND OPENFLOW SWITCH?
 The controller manages the switch via the
OpenFlow switch protocol over SSL/TCP
channel.
 OpenFlow switch is an OpenFlow-
enabled data switch that communicates
over OpenFlow channel to an external
controller.
 The controller extracts from the hardware
devices and communicates back to the
SDN Applications with an abstract view
of the network.
18

19. 7.4 OPERATION STEP
Controller
PC
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
Switch
New
function!
If header = x, send to port 4
If header =y, overwrite header with z,
send to ports 5,6
If header = ?, send to me
Flow
Table
Flow
Table
Flow
Table
Flow
Table
19

20. 7.5 OPENFLOW PROCESSING
 OpenFlow SW’s Packet Processing
 Search a matched entry of flow table with arriving packet’s information
20
Packet
in from
Network
Flow lookup
Send to secure
channel
Apply actions
No match
Match

21. 7.6 FLOW TABLE STRUCTURE
 Exploit flow table in switches, routers, and chipsets
21

22. 7.7 FLOW TABLE ENTRY
Switch
Port
MAC
src
MAC
dst
Eth
type
VLAN
ID
IP
Src
IP
Dst
IP
Prot
TCP
sport
TCP
dport
Rule Action Stats
1. Forward packet to port(s)
2. Encapsulate and forward to controller
3. Drop packet
4. Send to normal processing pipeline
+ mask
Packet + byte counters
22

23. 7.8 OPENFLOW FLOW TABLE
 In every OpenFlow switch, A flow table entry is identified by its match fields and priority.
 The match fields and priority taken together identify a unique flow entry in a specific flow
table.
23
#sudo ovs-ofctl -O OpenFlow13 dump-flows s1
cookie=0x0, duration=3.933s, table=0, n_packets=238752, n_bytes=11069190464,
priority=1,tcp,nw_src=192.168.1.2,nw_dst=192.168.1.1,tp_src=37304,tp_dst=5001 actions=output:"s1-eth1"
cookie=0x0, duration=3.906s, table=0, n_packets=192421, n_bytes=12699810,
priority=1,tcp,nw_src=192.168.1.1,nw_dst=192.168.1.2,tp_src=5001,tp_dst=37304 actions=output:"s1-eth2"
cookie=0x0, duration=31.495s, table=0, n_packets=43, n_bytes=4309, priority=0
actions=CONTROLLER:65535

24. 7.9 FLOW TABLE ENTRY EXAMPLES
(OPENFLOW IS BACKWARD COMPATIBLE)
Switch
Port
MAC
src
MAC
dst
Eth
type
VLAN
ID
IP
Src
IP
Dst
IP
Prot
TCP
sport
TCP
dport
Action
* * 00:1F:. * * * * * * * port6
Switch
Port
MAC
src
MAC
dst
Eth
type
VLAN
ID
IP
Src
IP
Dst
IP
Prot
TCP
sport
TCP
dport
Action
* * * * * * 5.6.7.8 * * * port6
Switch
Port
MAC
src
MAC
dst
Eth
type
VLAN
ID
IP
Src
IP
Dst
IP
Prot
TCP
sport
TCP
dport
Action
* * * * * * * * * 22 drop
Ethernet Switching
IP Routing
Application Firewall
24

25. 7.10 OPENFLOW CONTROLLER
 Centralized Intelligential agency for entire OpenFlow network.
 NOX is an open-source OpenFlow Controller.
 Researchers can insert their software code into NOX controller for
testing their idea.
Nox Controller
OpenFlow SwitchOpenFlow Switch OpenFlow Switch
25

26. 8. SDN APPLICATIONS
 No more hardware appliances needed to
deploy new services.
 The new service can be written as an
application inside one central SDN
controller.
 SDN achieves: Virtualization,
Orchestration, Programmable,
Dynamic Scaling, Performance, Service
Integration.
 BUT there is a problem!
26

27. 9. SDN ECOSYSTEMS
27

28. 10. SDN COMPONENTS : CONTROLLERS
OpenFlow Compliant (1.0-1.4) Controller
1. POX: (Python) Pox as a general SDN controller that supports OpenFlow. It has a high-level SDN API
including a queriable topology graph and support
2. for virtualization.
3. NOX: (C++/Python) NOX was the first OpenFlow controller.
4. Floodlight: (Java) The Floodlight controller is Java-based OpenFlow Controller. It was forked from the
Beacon controller, originally developed by David
5. Ryu: (Python) Ryu is an open-sourced Network Operating System (NOS) that supports OpenFlow.
6. Ovs-controller (C) Trivial reference controller packaged with Open vSwitch.
28

29. 11. MYTHS ABOUT SDN
1. First packet of the traffic will go to the
Controller.
2. The controller must be physically
centralized.
3. OpenFlow = = SDN
29

30. DEMONSTRATIO
N
LAB
30

31. OBJECTIVES
1. Basics of Mininet (Network emulator) in a virtual machine.
2. Explore OpenFlow, which is an open interface for controlling the network.
3. Run the Ryu controller with a sample application.
4. Use some commands to gain experience with OpenFlow.
31

32. NEEDED TOOLS
Tools Rule
1. Ubuntu 16.04 LTS OS
2. Mininet Virtual network emulator
3. Ryu Controller SDN controller
4. Openvswitch Multilayer virtual switch
5. Iperf Network performance measurement
32

33. TOOLS INSTALLATION
33
#sudo git clone git://github.com/mininet/mininet
cd mininet
git tag git checkout 2.2.2
cd ..
mininet/util/install.sh -n
2. Mininet installation
sudo apt-get install git gcc python-dev libffi-dev libssl-dev libxml2-dev libxslt1-dev zlib1g-dev python-pip
1. Install some needed python dependencies

34. TOOLS INSTALLATION
34
sudo apt-get install openvswitch-switch
4. Openvswitch
pip install ryu
git clone git://github.com/osrg/ryu.git
cd ryu; python ./setup.py install
3. Install Ryu controller
5. Iperf
sudo apt-get install iperf

35. DEMO NETWORK TOPOLOGY
35
Controller
OvSwitch
Port 1
Port 2 Port 3
Port 4
Host 1 Host 2 Host 3

36. KEY TAKE-A-WAYS
 OpenFlow is a protocol to program the data plane (OVswitches) forwarding table from a
central controller.
 We can handle the incoming packet-in as required by the application.
 It is not a wise decision to handle every network packet by the controller. (Proactive and
Reactive flows)
 Flows can be defined depending on the desired applications.
 Remember, the number of the flow entries can be installed on the switches is limited.
 Each Flow element maintains counters of bytes and packets.
36

37. CONCLUSION
 SDN is a successful network management paradigm isolate the data plane and control
plane.
 OpenFlow one of the main SDN protocols to communicate with data plane devices
(OpenFlow switches).
 OpenFlow switches developed based on legacy router for better automation.
 OpenFlow main goal was to open development environment for all researcher to program
the network.
37

38. Thank you!
Questions?

39. 39K-4 Fat tree data center Topology

40. REFENCES AND USEFUL GUIDES
1. RYU SDN Crash Course – Book : https://learning.knetsolutions.in/docs/ryu/
2. Mininet Walkthrough: http://mininet.org/walkthrough/
3. Iperf : https://openmaniak.com/iperf.php
4. Computer networks Course: https://www.youtube.com/playlist?list=PLDcmCgguL9rzuMGpIXktVEBb-abFd0CoZ
5. Ryu Whetting Your App: https://ryu.readthedocs.io/en/latest/writing_ryu_app.html
6. SDN Crash Course with RYU SDN Controller: https://github.com/knetsolutions/learn-sdn-with-ryu
7. Multipath Routing with Load Balancing using RYU OpenFlow Controller:
https://wildanmsyah.wordpress.com/2018/01/13/multipath-routing-with-load-balancing-using-ryu-openflow-controller/
8. The Road to SDN:
https://www.youtube.com/watch?v=dkUDUb9GtH0&list=PLpherdrLyny8YN4M24iRJBMCXkLcGbmhY
9. SDN Training Online: https://www.youtube.com/channel/UCTD6X9_oDqIYs_xpE7moFnQ
10. What is Fat Tree and how to construct it in 4-steps ? https://blogchinmaya.blogspot.com/2017/04/what-is-fat-tree-and-
how-to-construct.html
40