Transcript SDN Lecture 2x

SDN Lecture 2
Layer I: Infrastructure
Layer II: Southbound Interfaces
IV. SOFTWARE-DEFINED NETWORKS: BOTTOM-UP
• An SDN architecture can be represented as a composition of
different layers, as shown in Figure 6 (b). Each layer has its own
specific functions. While some of them are always present in an
SDN deployment, such as the southbound API, network operating
systems, northbound API and network applications, others may be
present only in particular deployments, such as hypervisor- or
language-based virtualization.
• Figure 6 presents a tri-fold perspective of SDNs. The SDN layers are
represented in the center (b) of the figure, as explained above.
Figures 6 (a) and 6 (c) illustrate a plane- oriented view and a system
design perspective, respectively.
• Next we will introduce each layer, following a bottom-up approach.
For each layer, the core properties and concepts are explained
based on the different technologies and solutions. Additionally,
debugging and troubleshooting techniques and tools are discussed.
A. Layer I: Infrastructure
• An SDN infrastructure, similarly to a traditional network, is composed of a
set of networking equipment (switches, routers and middlebox
appliances). The main difference resides in the fact that those traditional
physical devices are now simple forwarding elements without embedded
control or software to take autonomous decisions. The network
intelligence is removed from the data plane devices to a logicallycentralized control system, i.e., the network operating system and
applications, as shown in Figure 6 (c). More importantly, these new
networks are built (conceptually) on top of open and standard interfaces
(e.g., OpenFlow), a crucial approach for ensuring configuration and
communication compatibility and interoperability among different data
and control plane devices. In other words, these open interfaces enable
controller entities to dynamically program heterogeneous forwarding
devices, something difficult in traditional networks, due to the large
variety of proprietary and closed interfaces and the distributed nature of
the control plane.
• In an SDN/OpenFlow architecture, there are two main elements,
the controllers and the forwarding devices, as shown in Figure 7. A
data plane device is a hardware or software element specialized in
packet forwarding, while a controller is a software stack (the
“network brain”) running on a commodity hardware platform. An
OpenFlow-enabled forwarding device is based on a pipeline of flow
tables where each entry of a flow table has three parts: (1) a
matching rule, (2) actions to be executed on matching packets, and
(3) counters that keep statistics of matching packets. This high-level
and simplified model derived from OpenFlow is currently the most
widespread design of SDN data plane devices. Nevertheless, other
specifications of SDN-enabled forwarding devices are being
pursued, including POF [31], [120] and the Negotiable Datapath
Models (NDMs) from the ONF Forwarding Abstrac- tions Working
Group (FAWG) [121].
01
SDN$CONTROLLER$
ACTION%
SDN$DEVICE$
Control$
Communica5ons$
Network$$
Opera5ng$$
System$
Net$App$
Net$App$
Net$App$
Control$
Communica5ons$
Net$App$
Net$App$
Net$App$
RULE%
STATS%
Packet%+%counters%
FLOW$TABLES$
1.
2.
3.
4.
Forward%packet%to%port(s)%
Encapsulate%and%forward%to%co
Drop%packet%
Send%to%normal%processing%pip
Switch% MAC% MAC% Eth% VLAN% IP%%
src%
dst% type% ID% src%
port%
enFlow-enabled SDN devices
TABLE III
M ATCH FI EL DS, STATI STI CS A ND CA PA BI L I TI ES HAV E BEEN A DDED ON EACH OPEN FL OW PROTOCOL REV I SI ON
(REQ) A ND OPTI ONA L (OPT ) CA PA BI L I TI ES HA S GROWN CONSI DERA BLY.
• Inside an OpenFlow device, a path through a sequence of flow
tables defines how packets should be handled. When a
• new packet arrives, the lookup process starts in the first table and
ends either with a match in one of the tables of the pipeline or with
a miss (when no rule is found for that packet). A flow rule can be
defined by combining different matching fields, as illustrated in
Figure 7. If there is no default rule, the packet will be discarded.
However, the common case is to install a default rule which tells the
switch to send the packet to the controller (or to the normal nonOpenFlow pipeline of the switch). The priority of the rules follows
the natural sequence number of the tables and the row order in a
flow table. Possible actions include (1) forward the packet to
outgoing port(s), (2) encapsulate it and forward it to the controller,
(3) drop it, (4) send it to the normal processing pipeline, (5) send it
to the next flow table or to special tables, such as group or
metering tables introduced in the latest OpenFlow protocol.
• As detailed in Table III, each version of the OpenFlow specification
introduced new match fields including Ethernet, IPv4/v6, MPLS,
TCP/UDP, etc. However, only a subset of those matching fields are
mandatory to be compliant to a given protocol version. Similarly,
many actions and port types are optional features. Flow match
rules can be based on almost arbitrary combinations of bits of the
different packet headers using bit masks for each field. Adding new
matching fields has been eased with the extensibility capabilities
introduced in OpenFlow version 1.2 through an OpenFlow
Extensible Match (OXM) based on type-length-value (TLV)
structures. To improve the overall protocol extensibility, with
OpenFlow version 1.4 TLV structures have been also added to ports,
tables, and queues in replacement of the hard-coded counterparts
of earlier protocol versions.
Com
Com
System$
Switch% MAC% MAC% Eth% VLAN% IP%% IP%% TCP% TCP%
src%
dst% type% ID% src% dst% psrc% pdst%
port%
nFlow-enabled SDN devices
TABLE III
M ATCH FI EL DS, STATI STI CS A ND CA PA BI L I TI ES HAV E BEEN A DDED ON EACH OPEN FL OW PROTOCOL REV I SI ON .
(REQ) A ND OPTI ONA L (OPT ) CA PA BI L I TI ES HA S GROWN CONSI DERA BLY.
w Ver sion
1.0
1.1
1.2
M atch fields
Statistics
Ingress Port
Per table statistics
Ethernet: src, dst, type, VLAN
Per flow statistics
IPv4: src, dst, proto, ToS
Per port statistics
TCP/UDP: src port, dst port
Per queue statistics
Metadata, SCTP, VLAN tagging
Group statistics
MPLS: label, traffic class
Action bucket statistics
OpenFlow Extensible Match (OXM)
IPv6: src, dst, flow label, ICMPv6
1.3
PBB, IPv6 Extension Headers
1.4
—
Per-flow meter
Per-flow meter band
—
Optical port properties
. Nonetheless, this is changing at a fast pace. Some
est devices released in the market go far beyond
T HE NUM BER OF REQUI RED
# M atches
# I nstr uctions
# Actions
# Por ts
Req
Opt
Req
Opt
Req
Opt
Req
Opt
18
2
1
0
2
11
6
2
23
2
0
0
3
28
5
3
14
18
2
3
2
49
5
3
14
26
2
4
2
56
5
3
14
27
2
4
2
57
5
3
ofsoftswitch13 [141], Open vSwitch [142], OpenFlow Reference [143], Pica8 [150], Pantou [146], and XorPlus [46].
• Overview of available OpenFlow devices
– Several OpenFlow-enabled forwarding devices are available on
the market, both as commercial and open source products (see
Table IV). There are many off-the-shelf, ready to deploy,
OpenFlow switches and routers, among other appliances. Most
of the switches available on the market have relatively small
Ternary Content-Addressable Memory (TCAMs), with up to 8K
entries. Nonetheless, this is changing at a fast pace. Some of the
latest devices released in the market go far beyond that figure.
Gigabit Ethernet (GbE) switches for common business purposes
are already supporting up to 32K L2+L3 or 64K L2/L3 exact
match flows [122]. Enterprise class 10GbE switches are being
delivered with more than 80K Layer 2 flow entries [123].
• Other switching devices using high performance chips (e.g.,
EZchip NP-4) provide optimized TCAM memory that
supports from 125K up to 1000K flow table entries [124].
This is a clear sign that the size of the flow tables is growing
at a pace aiming to meet the needs of future SDN
deployments.
• Networking hardware manufacturers have produced
various kinds of OpenFlow-enabled devices, as is shown in
Table IV. These devices range from equipment for small
businesses (e.g., GbE switches) to high-class data center
equipment (e.g., high-density switch chassis with up to
100GbE connectivity for edge-to-core applications, with
tens of Tbps of switching capacity).
• Software switches are emerging as one of the most
promising solutions for data centers and virtualized
network infrastructures [147], [148], [149]. Examples of
software-based OpenFlow switch implementations include
Switch Light [145],
• ofsoftswitch13 [141], Open vSwitch [142], OpenFlow
Reference [143], Pica8 [150], Pantou [146], and XorPlus
[46]. Recent reports show that the number of virtual access
ports is already larger than physical access ports on data
centers [149]. Network virtualization has been one of the
drivers behind this trend. Software switches such as Open
vSwitch have been used for moving network functions to
the edge (with the core performing traditional IP
forwarding), thus enabling network virtualization [112].
• An interesting observation is the number of
small, start- up enterprises devoted to SDN, such
as Big Switch, Pica8, Cyan, Plexxi, and NoviFlow.
This seems to imply that SDN is springing a more
competitive and open networking market, one of
its original goals. Other effects of this openness
triggered by SDN include the emergence of socalled “bare metal switches” or “whitebox
switches”, where the software and hardware are
sold separately and the end-user is free to load
an operating system of its choice [151].
B. Layer II: Southbound Interfaces
• Southbound interfaces (or southbound APIs)
are the connecting bridges between control
and forwarding elements, thus being the
crucial instrument for clearly separating
control and data plane functionality. However,
these APIs are still tightly tied to the
forwarding elements of the underlying
physical or virtual infrastructure.
B. Layer II: Southbound Interfaces
• Typically, a new switch can take two years to be ready for
commercialization if built from scratch, with upgrade cycles that can
take up to nine months. The software development for a new
product can take from six months to one year [152]. The initial
investment is high and risky. As a central component of its design
the southbound APIs represent one of the major barriers for the
introduction and acceptance of any new networking technology. In
this light, the emergence of SDN southbound API proposals such as
OpenFlow [9] is seen as welcome by many in the industry. These
standards promote interoperability, allowing the deployment of
vendor-agnostic network devices. This has already been
demonstrated by the interoperability between OpenFlow-enabled
equipments from different vendors.
B. Layer II: Southbound Interfaces
• As of this writing, OpenFlow is the most widely accepted and
deployed open southbound standard for SDN. It provides a
common specification to implement OpenFlow-enabled forwarding devices, and for the communication channel between data
and control plane devices (e.g., switches and controllers). The
OpenFlow protocol provides three information sources for network
operating systems. First, event-based messages are sent by
forwarding devices to the controller when a link or ort change is
triggered. Second, flow statistics are generated by the forwarding
devices and collected by the controller. Third, packet-in messages
are sent by forwarding devices to the controller when they do not
known what to do with a new incoming flow or because there is an
explicit “send to controller” action in the matched entry of the flow
table. These information channels are the essential means to
provide flow- level information to the network operating system.
B. Layer II: Southbound Interfaces
• Albeit the most visible, OpenFlow is not the only avail- able
southbound interface for SDN. There are other API
proposals such as ForCES [30], OVSDB [153], POF [31],
[120], OpFlex [154], OpenState [155], Revised Open- Flow
Library (ROFL) [156], Hardware Abstraction Layer (HAL)
[157], [158], and Programmable Abstraction of Data- path
(PAD) [159]. ForCES proposes a more flexible approach to
traditional network management without changing the current architecture of the network, i.e., without the need of a
logically-centralized external controller. The control and
data planes are separated but can potentially be kept in the
same network element. However, the control part of the
network element can be upgraded on-the-fly with thirdparty firmware.
B. Layer II: Southbound Interfaces
• OVSDB [153] is another type of southbound API, designed to provide advanced management capabilities
for Open vSwitches. Beyond OpenFlow’s capabilities to
configure the behavior of flows in a forwarding device,
an Open vSwitch offers other networking functions. For
instance, it allows the control elements to create
multiple virtual switch instances, set QoS policies on
interfaces, attach interfaces to the switches, configure
tunnel interfaces on OpenFlow data paths, manage
queues, and collect statistics. Therefore, the OVSDB is a
complementary protocol to OpenFlow for Open
vSwitch.
B. Layer II: Southbound Interfaces
• One of the first direct competitors of OpenFlow is POF [31], [120]. One of
the main goals of POF is to enhance the current SDN forwarding plane.
With OpenFlow, switches have to understand the protocol headers to
extract the required bits to be matched with the flow tables entries. This
parsing represents a significant burden for data plane devices, in particular
if we consider that OpenFlow version 1.3 already contains more than 40
header fields. Besides this inherent complexity, backward compatibility
issues may arise every time new header fields are included in or removed
from the protocol. To achieve its goal, POF proposes a generic flow
instruction set (FIS) that makes the forwarding plane protocol-oblivious. A
forwarding element does not need to know, by itself, anything about the
packet format in advance. Forwarding devices are seen as white boxes
with only processing and forwarding capabilities. In POF, packet parsing is
a controller task that results in a sequence of generic keys and table
lookup instructions that are installed in the forwarding elements. The
behavior of data plane devices is therefore completely under the control
of the SDN controller. Similar to a CPU in a computer system, a POF switch
is application- and protocol-agnostic.
B. Layer II: Southbound Interfaces
• A recent southbound interface proposal is OpFlex
[154]. Contrary to OpenFlow (and similar to ForCES),
one of the ideas behind OpFlex is to distribute part of
the complexity of managing the network back to the
forwarding devices, with the aim of improving
scalability. Similar to OpenFlow, policies are logically
centralized and abstracted from the underlying implementation. The differences between OpenFlow and
OpFlex are a clear illustration of one of the important
questions to be answered when devising a southbound
interface: where to place each piece of the overall
functionality.
B. Layer II: Southbound Interfaces
• In contrast to OpFlex and POF, OpenState [155] and ROFL [156] do
not propose a new set of instructions for programming data plane
devices. OpenState proposes ex- tended finite machines (stateful
programming abstractions) as an extension (super-set) of the
OpenFlow match/action abstraction. Finite state machines allow
the implementation of several stateful tasks inside forwarding
devices, i.e., without augmenting the complexity or overhead of the
control plane. For instance, all tasks involving only local state, such
as MAC learning operations, port knocking or stateful edge firewalls
can be performed directly on the forwarding devices without any
extra control plane communication and processing delay. ROFL, on
the other hand, proposes an abstraction layer that hides the details
of the different OpenFlow versions, thus providing a clean API for
software developers, simplifying application development.
B. Layer II: Southbound Interfaces
• HAL [157], [158] is not exactly a southbound API, but is closely
related. Differently from the aforementioned ap- proaches, HAL is
rather a translator that enables a southbound API such as
OpenFlow to control heterogeneous hardware devices. It thus sits
between the southbound API and the hardware device. Recent
research experiments with HAL have demonstrated the viability of
SDN control in access networks such as Gigabit Ethernet passive
optical networks (GEPONs) [160] and cable networks (DOCSIS)
[161]. A similar effort to HAL is the Programmable Abstraction of
Datapath (PAD) [159], a proposal that goes a bit further by also
working as a southbound API by itself. More importantly, PAD
allows a more generic programming of forwarding devices by
enabling the control of datapath behavior using generic byte
operations, defining protocol headers and providing function
definitions.