SDN with OpenStack

1 PREFACE 2

2 INTRODUCTION 2

3 SDN CONCEPTS 2
3.1 OPENFLOW 2
3.1.1 OPENFLOW PROTOCOL 6
3.1.2 OPENFLOW PORTS 7
3.1.3 OPENFLOW TABLES 9
3.1.4 PIPE LINE PROCESSING 10
3.2 OPENVSWITCH 14
3.3 SDN CONTROLLERS 14

4 OPENDAY LIGHT CONTROLLER 14

5 APPENDIX - LABS 14
5.1 OPENFLOW LAB 14

1 Preface

2 Introduction
topology change timer 0.00 gc timer 238.59
OpenvSwitch

3 SDN Concepts
3.1 OpenFlow
The networking industry

Research StagnaGon (circa 2007): Faster networks but not beEer networks
• Lots of deployed innovation in other areas – OS: filesystems, schedulers,
virtualization
– DS: DHTs, CDNs, MapReduce
– Compilers: JITs, new language paradigms
• Networks are largely the same as years ago – Ethernet, IP,WiFi
• Rate of change of the network seems slower in comparison
– Need better tools and abstractions to demonstrate and deploy


Networking Technology Issues
• Many complex funcGons baked into the infrastructure
• OSPF, BGP, mul,cast, differen,ated services,
• Traffic Engineering, NAT, firewalls, MPLS, redundant layers, ...
• An industry with a “mainframe-mentality”
• Liile ability for non-telco network operators to get what they want
• FuncGonality defined by standards, put in hardware, deployed on nodes


Closed Systems (Vendor Hardware)
• Can’t extend
• Stuck with interfaces (CLI, SNMP, etc)
• Hard to meaningfully extend
• Hard to meaningfully collaborate
• Vendors starting to open up, but not usefully

Ethane, a precursor to OpenFlow

Ethane’s dumb, simple switches might be more broadly useful...
Centralized, reacGve, per-flow control

OpenFlow: a pragmatic compromise..

Advantages
• Speed,scale,fidelityofvendorhardware
• Flexibility and control of software and simulation Vendors don’t need to
expose implementation
• Leverages hardware inside most switches today (ACL tables)

Disadvantages
• Least-common-denominator interface may prevent using all hardware
features
• Limited table sizes
• Switches not designed for this New failure modes to understand

3.1.1 What is OpenFlow
OpenFlow is the first standard communications interface defined between the
control and forwarding layers of an SDN architecture.
• OpenFlow allows direct access to and manipulation of the forwarding plane of
network devices such as switches and routers, both physical and virtual
(hypervisor-based).
• It is the absence of an open interface to the forwarding plane that has led to the
characterization of today’s networking devices as monolithic, closed, and
mainframe-like

OpenFlow can bec ompared to the instruction set of a CPU. The protocol
specifies basic primitives that can be used by an external software application to
program the forwarding plane of network devices, just like the instruction set of
a CPU would program a computer system.


Research StagnaGon (circa 2007): Faster networks but not beEer networks
• Lots of deployed innovation in other areas – OS: filesystems, schedulers,
virtualization
– DS: DHTs, CDNs, MapReduce
– Compilers: JITs, new language paradigms
• Networks are largely the same as years ago – Ethernet, IP,WiFi
• Rate of change of the network seems slower in comparison
– Need better tools and abstractions to demonstrate and deploy


Another problem:
Closed Systems (Vendor Hardware)
• Can’t extend
• Stuck with interfaces (CLI, SNMP, etc)
• Hard to meaningfully extend
• Hard to meaningfully collaborate
• Vendors starting to open up, but not usefully


Ethane, a precursor to OpenFlow

Ethane’s dumb, simple switches might be more broadly useful...

OpenFlow: a pragmatic compromise
Positives
• Speed,scale,fidelityofvendorhardware
• Flexibility and control of software and simulation Vendors don’t need to
expose implementation
• Leverages hardware inside most switches today (ACL tables)
Negatives
• Least-common-denominator interface may prevent using all hardware
features
• Limited table sizes
• Switches not designed for this New failure modes to understand


OpenFlow is the first standard communications interface defined between the
control and forwarding layers of an SDN architecture.
OpenFlow allows direct access to and manipulation of the forwarding plane of
network devices such as switches and routers, both physical and virtual
(hypervisor-based).
It is the absence of an open interface to the forwarding plane that has led to the
characterization of today’s networking devices as monolithic, closed, and
mainframe-like.
OpenFlow can be compared to the instructions to a CPU. the protocol specifies
basic primitives that can be used by an external software application to program
the forwarding plane of network devices, just like the instruction set of a CPU
would program a computer system.

OpenFlow overview

3.1.2 OpenFlow Protocol

TheOpenFlowprotocolisimplementedonbothsidesofthe interface between
network infrastructure devices and the SDN control software.
• OpenFlowusestheconceptofflowstoidentifynetwork traffic based on pre-
defined match rules that can be statically or dynamically programmed by the
SDN control software.
• ItalsoallowsITtodefinehowtrafficshouldflowthrough network devices based on
parameters such as usage patterns, applications, and cloud resources.


Thisspecificationcoversthe components and the basic functions of the switch,
and the OpenFlow protocol to manage an OpenFlow switch from a remote
controller



An OpenFlow Switch consists of one or more flow tables and a group table, which
perform packet lookups and forwarding, and an OpenFlow channel to an
external controller The switch communicates with the controller and the
controller manages the switch via the OpenFlow protocol.

OpenFlow Protocol Supports three kinds of messages – Controller to Switch
– Asynchronous : Sent from Switch to Controller – Symmetric Messages : Sent in
both the directions




3.1.3 OpenFlow Ports


OpenFlow ports are the network interfaces for passing packets between
OpenFlow processing and the rest of the network.
OpenFlow switches connect logically to each other via their OpenFlow ports.
OpenFlow ports might not be same as the hardware port of the switch

Four OpenFlow Port types are:

• Standard: The OpenFlow standard ports are defined as physical ports,
logical ports, and the LOCAL reserved port if supported (excluding other
reserved ports). Standard ports can be used as ingress and output ports,
they can be used in groups

• Physical: The OpenFlow physical ports are switch defined ports that
correspond to a hardware interface of the switch. Ethernet switch,
physical ports map one-to-one to the Ethernet interfaces.
• Logical: The OpenFlow logical ports are switch defined ports that don't
correspond directly to a hardware interface of the switch.
o Logical ports are higher level abstractions that may be defined in
the switch using non- OpenFlow methods
o The only differences between physical ports and logical ports is
that a packet associated with a logical port may have an extra
metadata eld called Tunnel-ID associated with it
• Reserved: They specify generic forwarding actions such as sending to the
controller, flooding, or forwarding using non-OpenFlow methods, such as
“normal" switch processing.

Required:ALL:Representsallportstheswitchcanusefor forwarding a
specific packet.
•
– Can be used only as an output port. In that case a copy of the
packet is sent to all standard ports, excluding the packet ingress
port and ports that are configured OFPPC_NO_FWD.
Required: CONTROLLER: Represents the control channel with the
OpenFlow controller. Can be used as an ingress port or as an
output port.
– When used as an output port, encapsulate the packet in a
packet-in message and send it using the OpenFlow protocol
– When used as an ingress port, this identifies a packet originating
from the controller.

Required: TABLE: Represents the start of the OpenFlow pipeline
– This port is only valid in an output action in the action list of a
packet-out message and submits the packet to the first flow table
so that the packet can be processed through the regular OpenFlow
pipeline.
Required: IN PORT: Represents the packet ingress port.
• Can be used only as an output port, send the packet out
through its ingress port.
– Required: ANY: Special value used in some OpenFlow commands
when no port is specified (i.e. port is wild carded).
– – Can neither be used as an ingress port nor as an output port
– • Optional:LOCAL:Representstheswitch’slocalnetworking stack
and its management stack.
– – Can be used as an ingress port or as an output port.The local
port enables remote entities to interact with the switch and its
 network services via the OpenFlow network, rather than via a
separate control network.
– – With a suitable set of default flow entries it can be used to
implement an in-band controller connection.
–
– Optional:NORMAL:Representsthetraditionalnon- OpenFlow
pipeline of the switch.
– – Can be used only as an output port and processes the packet
using the normal pipeline.
– – If the switch cannot forward packets from the OpenFlow
pipeline to the normal pipeline, it must indicate that it does not
support this action.
– • Optional:FLOOD:Representsfloodingusingthenormal pipeline of
the switch.
– – Can be used only as an output port, in general will send the
packet out all standard ports, but not to the ingress port, nor ports
that are in OFPPS_BLOCKED state.The switch may also use the
packetVLAN ID to select which ports to flood.

3.1.4 Openflow Tables

Flow Table Entries

Examples



3.1.5 Pipe Line Processing

OpenFlow-compliant switches come in two types: OpenFlow-only, and
OpenFlow-hybrid
• OpenFlow- only switches support only OpenFlow operation, in those switches
all packets are processed by the OpenFlow pipeline, and can not be processed
otherwise.
• OpenFlow-hybrid switches support both OpenFlow operation and normal
Ethernet switching operation,
– i.e. traditional L2 Ethernet switching,VLAN isolation, L3 routing (IPv4 routing,
IPv6 routing...),ACL and QoS processing.
– Those switches must provide a classification mechanism outside of OpenFlow
that routes track to either the OpenFlow pipeline or the normal pipeline.
– For example, a switch may use the VLAN tag or input port of the packet to
decide whether to process the packet using one pipeline or the other, or it may
direct all packets to the OpenFlow pipeline.



The OpenFlow pipeline of every OpenFlow switch contains multiple flow tables,
each flow table containing multiple flow entries.
• TheOpenFlowpipelineprocessingdefineshow packets interact with those flow
tables.
• AnOpenFlowswitchisrequiredtohaveatleastone flow table, and can optionally
have more flow tables.
• An OpenFlow switch with only a single flow table is valid, in this case pipeline
processing is greatly simplified.

Each Flow table entry contains:
• match fields: to match against packets. These consist of the ingress port and
packet headers, and opGonally metadata specified by a previous table.
• priority: matching precedence of the flow entry.
• counters: updated when packets are matched.
• instrucGons: to modify the acGon set or pipeline processing.
• Gmeouts: maximum amount of Gme or idle Gme before flow is expired by the
switch.
• cookie: opaque data value chosen by the controller. May be used by the
controller to alter flow staGsGcs, flow modificaGon and flow deleGon.


Packet flow



Flow Removal

Flow entries are removed from flow tables in two ways, either at the request of
the controller or via the switch flow expiry mechanism.
• The switch flow expiry mechanism is run by the switch independently of the
controller and is based on the state and configuration of flow entries.
• Each flow entry has an idle_timeout and a hard_timeout associated with it.
• If the hard_timeout field is non-zero, the switch must note the flow entry’s
arrival time, as it may need to evict the entry later.

Meter Table
A meter table consists of meter entries, defining per- flow meters. Per-flow
meters enable OpenFlow to implement various simple QoS operations, such as
rate-limiting
• Can be combined with per-port queues to implement complex QoS
frameworks, such as DiffServ
• It is attached to a flow entry

Counters

• Counters are maintained for each flow table,
• flow entry, port, queue, group, group bucket, meter and meter band.
• OpenFlow-compliant counters may be implemented in software and
maintained by polling hardware counters with more limited ranges



Instructions,Action Sets
Instructions : Each flow entry contains a set of instructions that are executed
when a packet matches the entry. These instructions result in changes to the
packet, action set and/or pipeline processing.
• Action Set : Associated with each packet, is empty by default. It is populated
using Write - Action Instructions
– When the instruction set of a flow entry does not contain a Goto-Table
instruction, pipeline processing stops and the actions in the action set of the
packet are executed.


Action List :The Apply-Actions instruction and the Packet-out message include
an action list.
– The actions of an action list are executed in the order specified by the list, and
are applied immediately to the packet.


A switch is not required to support all action types, just those marked “Required
Action”
• The controller can also query the switch about which of the Optional Action" it
supports.
– e.g Required Action: Output.The Output action forwards a packet to a specied
OpenFlow port


OpenFlow Channels

The OpenFlow channel is the interface that connects each OpenFlow switch to a
controller.
• Controller configures and manages the switch, receives events from the switch,
and sends packets out the switch.
• Between the data-path and the OpenFlow channel, the interface is
implementation-specific, however all
• OpenFlow channel messages must be formatted according to the OpenFlow
protocol.
• The OpenFlow channel is usually encrypted using TLS, but may be run directly
over TCP.

3.2 OpenvSwitch
3.3 SDN Controllers

4 OpenDay Light Controller

5 Appendix - Labs
5.1 OpenFlow Lab