TE581-Software Defined Networking-2019aaaaaaaaaaaaaaaa.pptx

TE581: Computer Networks & Protocols
Software Defined Networking

Two Key Network-Layer Functions
• Forwarding
• when a packet arrives at a router’s input link
• the router must move the packet to the appropriate output link
• It is a router-local action of transferring a packet from an
• input link interface to the appropriate output link
interface
• refers to the way a packet is delivered to the next node
1
2
3
0111
values in arriving
packet header

Two Key Network-Layer Functions
• Routing
• there are more than one route from the source to the
destination
• the network layer is responsible for determining the
‘best’ route or path
• taken by packets as they flow from a sender to a receiver
• It is a network-wide process that determines the end-to-
end paths that packets take from sender to receive
• routing algorithms
• refers to the way routing tables are created to help in
forwarding

1
2
3
0111
value in arriving
packet’s header
routing algorithm
local forwarding table
header value output link
0100
0101
0111
1001
3
2
2
1
Interplay between routing and forwarding

Network layer: data plane
Data plane (Part of the network that carries user traffic)
 local, per-router function
 determines how datagram arriving on router input port is
forwarded to router output port
 forwarding function
1
2
3
0111
values in arriving
packet header

Network layer: control plane
Control plane (make decisions about where traffic is sent)
 Part of the network that carries signaling traffic and is
responsible for routing (configuration, management and exchange
of routing table information)
 network-wide logic
 determines how datagram is routed among routers along
end-end path from source host to destination host

Network-layer functions
• forwarding: move packets from
router’s input to appropriate
router output
data plane
control plane
two network-layer functions:
 routing: determine route
taken by packets from source
to destination

Network Design Philosophy
• Networks and networking devices
• have been designed to overcome RARE but severe challenges
• The philosophy is survivability

Traditional Networking
• The data and control planes baked into one box

Traditional Switches & Routers

Networks design not based on formal principles
• Networks used to be simple
- Basic Ethernet/IP straightforward, easy to manage
- For every issue a protocol is developed
• New control requirements have led to complexity
- ACLs, VLANs, TE, Middleboxes, DPI,…
• The infrastructure still works...
- Only because of our great ability to master complexity
- Focus is on mastering complexity
• Ability to master complexity both blessing and curse
11

Simplicity
• To make systems easy to use and understand
• The focus must be on extracting simplicity
• The ability to master complexity is
• not the same as the ability to extract simplicity
• Extracting simplicity builds intellectual foundations
• Necessary for creating a discipline….
• Abstraction is key to extracting simplicity
• What abstractions do we have in networking?
• Abstraction
• Is the act of representing essential
features without including the
background details or explanations

Data Plane Abstractions: Layers
Applications
…built on…
Reliable (or unreliable) transport
…built on…
Best-effort global packet delivery
…built on…
Best-effort local packet delivery
…built on…
Local physical transfer of bits
13

Control Plane Abstractions
• How do we find these abstractions?
• Define our problem, and then decompose it

The Control Plane Problem
• What is the control plane problem?

The Control Plane Problem
• Control plane must compute forwarding state. To
accomplish its task, the control plane must:
1. Figure out what network looks like (topology)
2. Figure out how to accomplish goal on given topology
3. Tell the swtiches what to do (configure forwarding state)
• What components do we want to reuse?
1. Determining the topology information
3. Configuring forwarding state on routers/switches

Two Control Plane Abstractions
• Abstraction: global network view
- Provides information about current network
• Abstraction: forwarding model
- Provides standard way of defining forwarding state

SDN: Two Control Plane Abstractions
• Abstraction: global network view
- Provides information about current network
- Implementation: “Network Operating System”
- Runs on servers in network (replicated for reliability)
• Abstraction: forwarding model
- Provides standard way of defining forwarding state
- This is OpenFlow
- Specification of <match,action> flow entries

SDN Basic Concept
• Separate Control plane and Data plane entities
• Network intelligence and state are logically centralized.
• The underlying network infrastructure is abstracted from the
applications.
• Execute or run Control plane software on general purpose
hardware
• Decouple from specific networking hardware
• Use commodity servers and switches
• Have programmable data planes
• Maintain, control and program data plane state from a central entity
• An architecture to
• control not just a networking device but an entire network

Software Defined Networking (SDN)
API to the data plane
(e.g., OpenFlow)
Logically-centralized control
Switches
Smart,
slow
Dumb,
fast

Software-Defined Network with key Abstractions
Network Operating System
Routing Traffic
Engineering
Other
Applications
Well-defined API
Network Map
Abstraction
Forwarding
Forwarding
Forwarding
Forwarding
Separation of Data
and Control Plane
Network
Virtualization
Security
Data Plane
Control Plane
Application Plane
Instructions Instructions
Instructions
Instructions

23
Specification Abstraction
• Control program must express desired behavior
- Whether it be isolation, access control, or QoS
• It should not be responsible for implementing that
behavior on physical network infrastructure
- Requires configuring the forwarding tables in each switch
• Proposed abstraction: Virtual Topology of network
- Virtual Topology models only enough detail to specify
goals

Network Virtualization
• Introduce new abstraction and new SDN layer
• Abstraction: Virtual Topology
- Allows operator to express requirements and policies
- Via a set of logical switches and their configurations
• Layer: Network Hypervisor
- Translates those requirements into switch configurations
- “Compiler” for virtual topologies
24

26
Clean Separation of Concerns
• Control program: express goals on Virtual Topology
- Operator Requirements
- Configuration = Function(view)
- Not a distributed protocol, now just a graph algorithm
• Network Hypervisor: Virtual Topology  Global Network View
• Network OS: Global Network View  physical switches
- Gathers information for global network view
- Conveys configurations from control program to switches
• Router/switches: merely follow orders from NOS

Software defined networking (SDN)
data
plane
control
plane
Remote Controller
CA
CA CA CA CA
1: generalized“ flow-
based” forwarding
(e.g., OpenFlow)
2. control, data
plane
separation
3. control plane
functions external
to data-plane
switches
…
4. programmable control
applications routing
access
control
load
balance

SDN perspective: data plane switches
Data plane switches
• fast, simple, commodity switches
implementing generalized data-
plane forwarding in hardware
• switch flow table computed,
installed by controller
• API for table-based switch control
(e.g., OpenFlow)
• defines what is controllable and what
is not
• protocol for communicating with
controller (e.g., OpenFlow) data
plane
control
plane
SDN Controller
(network operating system)
…
routing
access
control
load
balance
southbound API
northbound API
SDN-controlled switches
network-control
applications

SDN perspective: SDN controller
SDN controller (network OS):
 maintain network state
information
 interacts with network control
applications “above” via
northbound API
 interacts with network switches
“below” via southbound API
 implemented as distributed
system for performance,
scalability, fault-tolerance,
robustness
data
plane
control
plane
SDN Controller
…
routing
access
control
load
balance
southbound API
northbound API
network-control
applications

SDN perspective: control applications
network-control apps:
 “brains” of control: implement
control functions using lower-
level services, API provided by
SND controller
 unbundled: can be provided by
3rd
party: distinct from routing
vendor, or SDN controller
data
plane
control
plane
SDN Controller
…
routing
access
control
load
balance
southbound API
northbound API
network-control
applications

Network-wide distributed, robust state management
Communication to/from controlled devices
Link-state info switch info
host info
statistics flow tables
…
…
OpenFlow SNMP
…
network
graph intent
RESTful
API
…
Interface, abstractions for network control apps
SDN
controller
routing access
control
load
balance
Components of SDN controller
communication layer:
communicate between
SDN controller and
controlled switches
Network-wide state
management layer: state of
networks links, switches,
services: a distributed
database
Interface layer to network
control apps: abstractions
API

OpenFlow protocol
• operates between
controller, switch
• TCP used to exchange
messages
• optional encryption
• three classes of
OpenFlow messages:
• controller-to-switch
• asynchronous (switch
to controller)
• symmetric (misc)
OpenFlow Controller

OpenFlow: controller-to-switch messages
Key controller-to-switch messages
• features: controller queries switch
features, switch replies
• configure: controller queries/sets
switch configuration parameters
• modify-state: add, delete, modify flow
entries in the OpenFlow tables
• packet-out: controller can send this
packet out of specific switch port
OpenFlow Controller

OpenFlow: switch-to-controller messages
Key switch-to-controller messages
• packet-in: transfer packet (and its
control) to controller. See packet-
out message from controller
• flow-removed: flow table entry
deleted at switch
• port status: inform controller of a
change on a port.
Fortunately, network operators don’t “program” switches by
creating/sending OpenFlow messages directly. Instead use
higher-level abstraction at controller
OpenFlow Controller

host info
…
…
OpenFlow SNMP
…
network
graph intent
RESTful
API
…
1
2
3
4
6
5
Dijkstra’s link-state
Routing
s1
s2
s3
s4
SDN: control/data plane interaction example
S1, experiencing link failure
using OpenFlow port status
message to notify controller
1
SDN controller receives
OpenFlow message, updates
link status info
2
Dijkstra’s routing algorithm
application has previously
registered to be called when
ever link status changes. It is
called.
3
Dijkstra’s routing algorithm
access network graph info, link
state info in controller,
computes new routes
4

host info
…
…
OpenFlow SNMP
…
network
graph intent
RESTful
API
…
1
2
3
4
6
5
Dijkstra’s link-state
Routing
s1
s2
s3
s4
SDN: control/data plane interaction example
link state routing app interacts
with flow-table-computation
component in SDN controller,
which computes new flow
tables needed
5
Controller uses OpenFlow to
install new tables in switches
that need updating
6

OpenFlow: controller-to-switch messages
Key controller-to-switch messages
• features: controller queries switch
features, switch replies
• configure: controller queries/sets
switch configuration parameters
• modify-state: add, delete, modify
flow entries in the OpenFlow
tables
• packet-out: controller can send
this packet out of specific switch
port
OpenFlow Controller

How Does OpenFlow Work?
• OpenFlow Switch and Tables
General purpose PC,
Server
OpenFlow
protocol
Data Path, H/W
Control Path OpenFlow
Controller
(Server Software)
App App App
Ethernet Switch

What is OpenFlow?
• Allow separation of control and data planes.
• Centralization of control.
• Flow based control.
• Takes advantage routing tables in Ethernet switches and routers.
• SDN is not OpenFlow.
• SDN is a concept of the physical separation of the network control plane from the
forwarding plane, and where a control plane controls several devices.
• OpenFlow is communication interface between the control and data plane of an SDN
architecture.
• Allows direct access to and manipulation of the forwarding plane of network devices such as switches and
routers, both physical and virtual.
• Think of as a protocol used in switching devices and controllers interface.

Research Problems
• Scalability:
• Control plane bottleneck.
• Single controller is not sufficient to manage large scale network.
• How many controllers are needed to support large scale network?
• When to scale down?
• Multi Controllers.
• Each controller is responsible to a subset of the network.
• Concern with synchronization and communication between controllers.
• How to slice the resources among controllers?
• Latency between controllers and switches.
• Less accurate decision?

Research Challenges in SDN
Research
Issues in
SDN
1 Controller Design
Traffic Engineering
2
3 Debugging, Testing
Security
4
5 Failover

Four Crucial Points
• SDN is merely set of abstractions for control plane
- Not a specific set of mechanisms
- OpenFlow is least interesting aspect of SDN, technically
• SDN involves computing a function….
- NOS handles distribution of state
• …on an abstract network
- Can ignore actual physical infrastructure
• Network virtualization is the “killer app”
- Already virtualized compute, storage; network is next

Conclusion
• Key ideas of SDN:
• Dynamic programmability in forwarding packets.
• Decoupling control and data plane.
• Global view network by logical centralization in control plane.
• Applications can be implemented on top of the control plane.
• SDN is a concept to manage network that leverages OpenFlow protocols.

TE581-Software Defined Networking-2019aaaaaaaaaaaaaaaa.pptx

More Related Content

Similar to TE581-Software Defined Networking-2019aaaaaaaaaaaaaaaa.pptx

More from NanaAgyeman13

Recently uploaded

TE581-Software Defined Networking-2019aaaaaaaaaaaaaaaa.pptx

Editor's Notes