From dumb to smarter switches in software defined

From dumb to smarter switches in software defined
IEEE NETSOFT 2015 – London, April 13, 2015
From dumb to smarter switches
in software defined networks:
an overview of data plane evolution
Antonio Capone, Carmelo Cascone
Politecnico di Milano – ANTLab
Ecole Polytechnque de Montreal
A. Capone & C. Cascone: SDN tutorial
1
Acknowledgements
This tutorial has be supported by the EU
project BEBA
The authors wish to thank:
- prof. Giuseppe Bianchi and Marco Bonola (Univ. of Rome,
Tor Vergata)
- Luca Pollini and Davide Sanvito (Politecnico di Milano)
A. Capone & C. Cascone: SDN tutorial
2
Agenda
1) Setting the scene: a brief intro to SDN and
OpenFlow
2) Switches cannot remain dumb: Starting the
process of data plane evolution
3) Not too much not too little: OpenState and
statefull data planes
4) Applied smartness: statefull applications
(with hands-on activities)
A. Capone & C. Cascone: SDN tutorial
3
Setting the scene: a brief intro to
SDN and OpenFlow
The future has already arrived. It's just not
evenly distributed yet. [William Gibson]
A. Capone & C. Cascone: SDN tutorial
4
Classic network paradigm
Distributed network functions
State distribution mechanism
(protocols)
OS
Forwarding HW
OS
Forwarding HW
OS
Forwarding HW
Router/switch/appliance
A. Capone & C. Cascone: SDN tutorial
5
Vertically integrated
L3 Routing, L2 switching, ACL, VPNs, etc…
App
App
App
Control-plane
OS
Data-plane
Closed
platform!
Forwarding HW
Protocols guarantee interoperability…
But what’s the drawback?
A. Capone & C. Cascone: SDN tutorial
6
Way too many standards?
Source: IETF
A. Capone & C. Cascone: SDN tutorial
7
A. Capone & C. Cascone: SDN tutorial
8
Vendors dominated?
Source: IETF
A. Capone & C. Cascone: SDN tutorial
9
Non-standard management
• Configuration interfaces vary across:
– Different vendors
– Different devices of same vendor
– Different firmware versions of same device!
• SNMP fail
– Proliferation of non-standard MIBs
– Partially implemented standard MIBS
– IETF recently published a recommendation to stop
producing writable MIB modules
A. Capone & C. Cascone: SDN tutorial
10
Evolution of the infrastructure
Server
x86, Linux, hypervisors, cloud,
open-source, etc.
A. Capone & C. Cascone: SDN tutorial
Storage
Scale out, flash, thin provisioning, object
storage, etc.
Networking
•
7200+ RFCs
•
•
Mainframe hardware
Software integration
•
Extremely expensive
•
Protocols development needs
too long + adoption times
More protocols
11
The (new) paradigm
Traditional networking
Switch
Software-Defined Networking
Programmable
switch
Control-plane
Control-plane
Data-plane
Control-plane
Data-plane
Data-plane
Data-plane
Control-plane
Data-plane
Data-plane
A. Capone & C. Cascone: SDN tutorial
12
SDN architecture
App
App
App
Network control API
Network OS
HW open interface
Simple forwarding
HW
Simple forwarding
HW
Simple forwarding
HW
Simple forwarding
HW
A. Capone & C. Cascone: SDN tutorial
13
From protocols to API
• HW forwarding abstraction
– low-level primitives to describe packet forwarding
• Control plane API
– Network topology abstraction
– High-level access to switch programming
– Common libraries
• Host tracking
• Shortest-path
• Etc..
A. Capone & C. Cascone: SDN tutorial
14
Success keys
• Low-level HW open interface (but not too low
level …)
• Good, extensible and possibly open-source
Network OS (too many?)
• Open market for third-party network
application developers (development
ecosystem is crucial)
– Network app store
A. Capone & C. Cascone: SDN tutorial
15
Several attempts …
Active Networks, IETF ForCES, …
A. Capone & C. Cascone: SDN tutorial
16
Active networking
• “The goal for active networking is to have
programmable open nodes, with the ability to deploy
programs dynamically into node engines.”
app
active
node
l
ne
an
el
nn
a
ch
e
ul
ps
ca
le
ch
c
su
ap
app
active active
node node
channel
IP
router
channel
active
node
app
app
capsule
capsule
Capsule model
Programmable router model
D. Wetherall et al., “ANTS: A toolkit for building and dynamically
deploying network protocols. In IEEE OpenArch, April 1998.
J.M. Smith et al., "Activating networks: a progress report,"
Computer, vol.32, no.4, pp.32,41, Apr 1999
A. Capone & C. Cascone: SDN tutorial
17
ForCES Architecture
• ForCES - Forwarding and Control Element Separation
• IETF ForCES working group was established in 2001 and closed
in 2014
• RFC3746: “ForCES Framework” defines
– CE:Control Element
– FE:Forwarding Element
• CE may be required to control hundreds of FEs
ForCES Architecture - FE
FE Model
CE
ForCES Protocol
FE
ForCES Protocol Stack
LFB1
Attributes
Datapath
...
LFBn
Attributes
– ForCES Protocol
• To provide a universal standardized control interface for FEs
– LFB – Logical Functional Block
• e.g., Classifier LFB, IPv4 LPF LFB, IPv6 LPF LFB, Scheduler LFB
– Datapath
• Can configure dynamically LFB topology for supporting various
over IP services
… but one winner
OpenFlow
A. Capone & C. Cascone: SDN tutorial
20
OpenFlow
• Stanford, 2008
• Clean Slate research program
• “With what we know today, if we were to start
again with a clean slate, how would we design
a global communications infrastructure?”
Is it really a clean
slate approach?
A. Capone & C. Cascone: SDN tutorial
21
OpenFlow
• OpenFlow is actually a pragmatic approach to
SDN based on a simple HW abstraction that can
be implemented with current HW commercial
platforms
OpenFlow controller
OpenFlow Protocol
(SSL/TCP)
A. Capone & C. Cascone: SDN tutorial
In-bound or out-bound
22
OpenFlow
A. Capone & C. Cascone: SDN tutorial
23
What is OpenFlow
• Switch abstraction
– Match/action flow table
– Flow counters
– It doesn’t describe how this should be implemented in
switches (vendor neutral !!!)
• Application layer protocol
– Binary wire protocol, messages to program the flow
table
• Transport protocol
– TCP, TLS
A. Capone & C. Cascone: SDN tutorial
24
Flow table
Match
Actions
Counters
Bytes + packets
1.
2.
3.
4.
5.
6.
7.
Switch
Port
VLAN
ID
Forward (one or more ports)
Drop
Encapsulate and send to controller
Header rewrite
Push/pop MPLS label / VLAN tag
Queues + bitrate limiter (bit/s)
Etc..
VLAN
pcp
MAC
src
MAC
dst
Eth
type
IP
Src
IP
Dst
IP
ToS
IP
Prot
L4
sport
L4
dport
Slide courtesy: Rob Sherwood
A. Capone & C. Cascone: SDN tutorial
25
Switch abstraction
OpenFlow controller
Software
Hardware (e.g. TCAM)
or software
A. Capone & C. Cascone: SDN tutorial
OpenFlow client
Flow table
(aka Forwarding Information Base)
26
Example
Description
Port
MAC src
MAC
dst
Eth
type
VLAN
ID
IP Src
IP Dest
TCP
sport
TCP
dport
Action
L2 switching
*
*
00:1f:..
*
*
*
*
*
*
Port6
L3 routing
*
*
*
*
*
*
5.6.*.*
*
*
Port6
Micro-flow
handling
3
00:20..
00:1f..
0x800
Vlan1
1.2.3.4
5.6.7.8
4
17264
Port4
Firewall
*
*
*
*
*
*
*
*
22
Drop
VLAN
switching
*
*
00:1f..
*
Vlan1
*
*
*
*
Port6,
port7,
port8
A. Capone & C. Cascone: SDN tutorial
27
Reactive vs Proactive
• Reactive
–
–
–
–
Start with flow table empty
First packet of a flow sent to controller
Controller install flow entries
Good for stateful forwarding:
• L2 switching, dynamic firewall, resource management
• Proactive
– Flow entries installed at switch boot
– Good for stateless forwarding:
• L3 routing, static firewall, etc..
A. Capone & C. Cascone: SDN tutorial
28
OpenFlow 1.0 recap
Redirect to controller
Packet
Flow table
Drop
A. Capone & C. Cascone: SDN tutorial
Apply actions, forward
But how do we
implement a
flow table?
29
HW vs SW switches
• Soft switching based on general CPU
• Switching based on network processors
• Switching based on dedicated chips
10x
10x
 1 Tb/s capacity is the target switching
capacity for top level devices
 The differences in performance
between HW and SW switches are
expected to remain
 But the application domain of soft
switches will expand in scenarios where
extremely high rates are not required
A. Capone & C. Cascone: SDN tutorial
30
HW vs SW switches
• OF has been designed having in mind current
specialized HW architecture for switches
• Even if it has greatly stimulated the evolution
of soft switches and extended their use
• OF doesn’t describe how the forwarding
abstraction should be implemented in switches
(vendor neutral !!!)
– but what does this really mean? (…)
A. Capone & C. Cascone: SDN tutorial
31
Forwarding Abstraction OF1.0
SMT - Single Match Table
TCAM
Ternary Content Addressable Memory
A. Capone & C. Cascone: SDN tutorial
32
Limitations of SMT abstraction
• SMT is a simple and powerful abstraction, but the
option to implement it using a single TCAM is not
practical
• A very big and wide TCAM would be necessary in
most cases
– Wide: all header fields
– Big: all possible combinations of values relevant
– the distance between abstraction and
implementations is at the basis of the OF success
– but also an incentive to try to make the
abstraction evolve and become more flexible (…)
A. Capone & C. Cascone: SDN tutorial
33
Other (less known) sides of OF
• Before moving to the evolution of the
forwarding abstraction it is worth pointing out
some other characteristics of OF
• OF focuses only on the control of the data
plane
• However its relation with network
management and configuration is within an
area which is not completely back-n-white
A. Capone & C. Cascone: SDN tutorial
34
Control plane vs Management plane?
• Another important practical issue is the relation of OF
and the controller with the network management
platforms
• In principle controllers could take over the
management functions (mainly device configuration
and monitoring)
• This however requires more complex functions and a
number of legacy management services that are still
crucial for networks
• If we take a look at a popular SDN controller
(OpenDayLight) architecture, it is easy to understand
things are more complex than they appear
A. Capone & C. Cascone: SDN tutorial
35
Network OS / controller example:
OpenDaylight (Linux Foundation)
A. Capone & C. Cascone: SDN tutorial
36
OF-CONFIG
• ONF defined its own configuration protocol based
on NETCONF and xml data models
Configuration
Configuration
Point
Point
OF-CONFIG
Configuration
OpenFlow
Point
Controller
using IETF Netconf &
XML data models
OpenFlow
Capable Switch
OpenFlow
OF Logical
Switch
Configuration
OpenFlow
Point
Controller
OpenFlow
OF Logical
Switch
resources
(ports, queues)
A. Capone & C. Cascone: SDN tutorial
37
SDN Layers and Architecture Terminology
• IETF is trying to
clean up
terminology and
architecture and
reconcile it with
real schemes
Source: IRTF Software-Defined Networking Research Group (SDNRG)
A. Capone & C. Cascone: SDN tutorial
38
Switches cannot remain dumb:
Starting the process of data
plane evolution
One man alone can be pretty dumb sometimes, but for real
bona fide stupidity, there ain't nothin' can beat teamwork.
[Edward Abbey]
A. Capone & C. Cascone: SDN tutorial
39
Models can be perfect and clean,
reality is dirty!
• The match/action model can ideally be used to program
any network behavior and to get rid of protocol
limitations at any level
• But unfortunately, with OF:
– Matches can be done only on a set of predefined header
fields (Ethernet, IPv4, MPLS, VLAN tag, etc.)
– Actions are limited to a rather small set
– Header manipulation (like adding label/tags, rewriting of
fields, etc.) is limited to standard schemes
• As a result, OF is not really protocol independent and
standards (including OF standards) are still necessary
A. Capone & C. Cascone: SDN tutorial
40
Where do OF limitations come from?
• TCAMs are typically expensive components that are used
by manufacturers only when strictly necessary
• Less expensive memory components based on predefined
search keys are often used for most of the common
functions of a switch
• OF success depends on its “vendor neutral” approach
where implementations issues are completely opaque
(including reuse of standard modules for e.g. MAC and IP
forwarding)
• Specialized ASICs are typically complex with a number of
hard limitations on table types, sizes, and match depth
A. Capone & C. Cascone: SDN tutorial
41
Multiple Match Tables (MMT)
• Single Match tables are costly: all possible
combinations of header values in a single long
table
• Solution: Multiple Match Tables (MMT)
• MMTs are the HAL of OF 1.1
OpenFlow Switch
Packet
In
Ingress
port
Action
Set = {}
Table
0
Packet +
ingress port +
metadata
A. Capone & C. Cascone: SDN tutorial
Action
Set
Table
1
...
Table
n
Packet
Action
Set
Execute
Action
Set
Packet
Out
42
MMT and implementations
• MMT introduced in OF 1.1 are actually much
closer to real switch implementation in
specialized chips
source: bigswitch.com
A. Capone & C. Cascone: SDN tutorial
43
Switch pipeline
• Existing switch chips implement a small (4–8) number of
tables whose widths, depths, and execution order are set
when the chip is fabricated
• Optimization of the pipeline can lead to very different
results depending on the context:
– A chip used for a core router may require a very large 32-bit IP
longest matching table and a small 128 bit ACL match table;
– A chip used for an L2 bridge may wish to have a 48-bit
destination MAC address match table and a second 48-bit
source MAC address learning table;
– an enterprise router may wish to have a smaller 32-bit IP prefix
table and a much larger ACL table as well as some MAC address
match tables.
[RMT] Pat Bosshart et al, “Forwarding Metamorphosis: Fast Programmable Match-Action Processing in Hardware for SDN”, ACM SIGCOM 2013.
A. Capone & C. Cascone: SDN tutorial
44
Group Tables (OF 1.1)
• Packets of the same flow are applied the same actions
unless the table entry is modified by the controller
• Not good for some common and important cases (e.g.
multicast, multipath load balancing, failure reaction, etc.)
• Solution: Group tables
– Goto table “group table n”
– List of buckets of actions
– All or some of the buckets are executed depending on the type
• Types of Group tables
– All (multicast)
– Select (multipath)
– Fast-failover (protection switching)
A. Capone & C. Cascone: SDN tutorial
45
Group Tables (OF 1.1)
• Fast failover
• Note that this is the first “stateful” behavior in the data
plane introduced in OF !!!
Group table
fast failover
Action bucket 1:
FWD Port A, …
Action bucket 2:
FWD Port B, …
Action bucket 3:
FWD Port C, …
Action bucket 4:
FWD Port D, …
Port A
Status
monitoring
Port B
Status
monitoring
A
Port C
Status
monitoring
B
D
C
Port D
Status
monitoring
A. Capone & C. Cascone: SDN tutorial
46
OF 1.2
• Extensible match (Type Length Value)
• Support for IPv6, new match fields:
– source address, destination address, protocol
number, traffic class, ICMPv6 type, ICMPv6 code,
IPv6 neighbor discovery header fields, and IPv6
flow labels
• Experimenter extensions
• Full VLAN and MPLS support
• Multiple controllers
A. Capone & C. Cascone: SDN tutorial
47
OF 1.3
• Initial traffic shaping and QoS support
– Meters: tables (accessed as usual with “goto
table”) for collecting statistics on traffic flows and
applying rate-limiters
Meter Table
Meter indentifier
Meter band
Counters
…
…
…
…
…
…
…
…
…
Type
A. Capone & C. Cascone: SDN tutorial
Rate
Counters
Type/argument
48
OF 1.4
• More extensible wire protocol
• Synchronized tables
– tables with synchronized flow entries
• Bundles
– similar to transactional updates in DB
• Support for optical ports
A. Capone & C. Cascone: SDN tutorial
49
OF 1.5
Egress tables
A. Capone & C. Cascone: SDN tutorial
50
OF 1.5
• Packet type aware pipeline
• Extensible flow entry statistics
• TCP flags matching
A. Capone & C. Cascone: SDN tutorial
51
OF future extensions
[MAC13] Ben Mack-Crane, “OpenFlow Extensions”, US Ignite ONF GENI workshop, Oct 2013
• The discussion on flow states
– The capability to store / access flow metadata that
persists for lifetime of flow (not just current packet)
– Potential to enable a variety of new capabilities:
•
•
•
•
•
Fragment handling without reassembly
Relation between bidirectional flows (e.g., RDI)
Autonomous flow learning + flow state tracking
MAC learning
TCP proxy
– Hierarchies of flows
• e.g. FTP control / data, all belonging to a user, etc.
A. Capone & C. Cascone: SDN tutorial
52
Also abstraction “involutions” (?):
Typed tables
• “A step back to ensure wider applicability”
• A third way between reactive and proactive
• Pre-run-time description of switch-level
“behavioral abstraction” (tell to the switch which
types of flowmods will be instantiated at run time)
• Limit types supported according to HW type
Typed tables patterns: Forwarding Elements (F:E.)
OpenFlow
1.0
Statefull
Generic
Tunnel
Layer 3
IPv4
Constrained
OpenFlow 1.1
A. Capone & C. Cascone: SDN tutorial
Stateless
Generic
Tunnel
802.1D
Forwarding
(…)
ONF Forwarding Abstractions WG
53
Breaking the limitation of specialized
pipelines: Reconfigurable Match Table
• OF introduced the MMT model but does not mandate
the width, depth, or even the number of tables
• OF allows the introduction of new match fields through
a user-defined field facility
• Recent proposal by McKeown, Varghese et al. [BOS13]:
RMT
• Goal: reconfigurability of multiple tables with arbitrary
width
[BOS13] P. Bosshart, G. Gibb, H.-S. Kim, G. Varghese, N. McKeown, M. Izzard, F. Mujica, and M. Horowitz, “Forwarding
metamorphosis: Fast programmable match-action processing in hardware for sdn”, in ACM SIGCOMM 2013.
A. Capone & C. Cascone: SDN tutorial
54
Reconfigurable Match Tables (RMT)
• Field definitions can be altered and
new fields added
• Number, topology, widths, and
depths of match tables can be
specified, subject only to an overall
resource limit on the number of
matched bits
• New actions may be defined
• Arbitrarily modified packets can be
placed in specified queues, for
output at any subset of ports, with
a queuing discipline specified for
each queue.
Physical
Stage 1
Physical
Stage 2
Physical
Stage M
Logical Stage 1
...
Logical
Stage N
Logical Stage 2
: Ingress logical
match tables
: Egress logical
match tables
Physical
flexible
architecture
on chip
[BOS13] P. Bosshart, G. Gibb, H.-S. Kim, G. Varghese, N. McKeown, M. Izzard, F. Mujica, and M. Horowitz, “Forwarding
metamorphosis: Fast programmable match-action processing in hardware for sdn”, in ACM SIGCOMM 2013.
A. Capone & C. Cascone: SDN tutorial
55
Reconfigurable Match Tables (RMT)
Logical Stage 1
Switch State
(metadata)
Global states
VLIW
Action
...
Configurable
Output
Queues
1
...
Header re-write with very
long instruction word (VLIW)
Packets
...
Recombine
OP code
(from inst
mem)
State
New Header
Src 3
...
K
Output
Channels
Configurable
queues
Packet
Header
Vector
Src 1
Src 2
Src 3
Action
Unit
Action
Memory
Action Input Selector (Crossbar)
...
Very Wide
Header Bus
Match
Results
...
Programmable
parser
Action
Unit
Src 2
Match
Tables
Select
Payload
...
K
Src 1
Packet
Header
Vector
Match
Tables
Prog.
Parser
1
Input
Channels
...
Header
Packets
Statistics
Logical Stage N
OP code
Ctrl
VLIW Instruction Memory
[BOS13] P. Bosshart, G. Gibb, H.-S. Kim, G. Varghese, N. McKeown, M. Izzard, F. Mujica, and M. Horowitz, “Forwarding
metamorphosis: Fast programmable match-action processing in hardware for sdn”, in ACM SIGCOMM 2013.
A. Capone & C. Cascone: SDN tutorial
56
Pipeline flexibility: FlexPipeTM (Intel)
• Flexible pipeline and
table solutions already
available from some
vendors
Source: Dr. Recep Ozdag - INTEL
A. Capone & C. Cascone: SDN tutorial
57
All the way down to programmability: P4
• OpenFlow 2.0 proposal by McKeown, Rexford et al.
[BOS14]
• 3 goals:
– Protocol independence
• Configurable packet parser
• Match/actions not tied to any specific network protocols
– Target independence
• Compiler handles mapping independently to switch details
(e.g. TCAM vs RAM, softswitch, RMT, FlexPipe, etc.)
– Reconfigurability
• Change parsing and processing in the field
[BOS14] P. Bosshart, D. Daly, G. Gibb, M. Izzard, N. McKeown, J. Rexford, C. Schlesinger, D. Talayco, A.
Vahdat, G. Varghese, and D. Walker “P4: Programming protocol-independent packet processors,”
SIGCOMM CCR, July 2014
A. Capone & C. Cascone: SDN tutorial
58
All the way down to programmability: P4
• Configuration achieved with a programming language
describing parsing and control
• Flow tables populated with “Classic” OpenFlow
• Compiler maps parser and tables to specialized hardware
or software
A. Capone & C. Cascone: SDN tutorial
59
All the way down to programmability: P4
P4 configuration abstractions:
• Header
– Ordered list of fields with name and width
• Parser
– State machine traversing the packet to extract header fields
(If ethertype == 0x800 then…)
• Action functions
– Custom functions made of primitive actions
(add_field,remove_header, copy, set, increment, checksum, etc…)
• Typed tables
– What fields are matched in what way
(exact match, longest prefix, range, etc...)
• Control flow
– Table application order, conditionals, functions
• Stateful memories
– Counters, meters and registers which persist across packets
A. Capone & C. Cascone: SDN tutorial
60
All the way down to programmability: P4
Example:
Header formats:
Typed tables and functions:
Parser state function:
Action function:
copy_f i el d( mTag. et her t ype, vl an. et her t ype) ;
/ / Set VLAN’ s et her t ype t o si gnal mTag
set _f i el d( vl an. et her t ype, 0xaaaa) ;
set _f i el d( mTag. up1, up1) ;
set _f i el d( mTag. up2, up2) ;
set _f i el d( mTag. down1, down1) ;
set _f i el d( mTag. down2, down2) ;
/ / Set t he dest i nat i on egr ess por t as wel l
set _f i el d( met adat a. egr ess_spec, egr _spec) ;
}
A. Capone & C. Cascone: SDN tutorial
61
Protocol Oblivious Forwarding (POF)
• Removing/neglecting constraints on general HW can lead
to extreme flexibility of a clean slate approach (not in the
OF evolution track)
• POF proposal by Huawei [SON13]
• POF makes the forwarding plane totally protocol-oblivious
• The POF FE has no need to understand the packet format
• Arbitrary field definition:
MAC
field {
type;
offset;
length;
};
Example:
0
6
dst
12
src
type
dst: {0, 0, 48};
src: {0, 48, 48};
type: {0, 96, 16};
[SON13] H. Song, “Protocol-oblivious forwarding: Unleash the power of SDN through a future-proof
forwarding plane, HotSDN ’13. ACM, 2013, pp. 127–132.
A. Capone & C. Cascone: SDN tutorial
62
Protocol Oblivious Forwarding (POF)
• POF FE execute instruction of its controller to:
– extract and assemble the search keys from the
packet header,
– conduct the table lookups,
– execute the associated instructions (in the form of
executable code written in FIS or compiled from
FIS).
[SON13] H. Song, “Protocol-oblivious forwarding: Unleash the power of SDN through a future-proof
forwarding plane, HotSDN ’13. ACM, 2013, pp. 127–132.
A. Capone & C. Cascone: SDN tutorial
63
Protocol Oblivious Forwarding (POF)
Example: forwarding based on a “new” protocol IPvX with 64 bits addresses
Flow Table 0 (Dst, Type)
0
1
Flow Table 1 (Src_Addr)
Fields
Instructions
Fields
Instructions
Goto-Table{
Table 1, /*Flow Table 1*/
14,
/*Packet Process Pointer
move forward 14bytes */
1,
/*match field number is 1*/
{0, 64,64}, /*match field is Src_Addr*/
}
2
3
0
1
Fields
Instructions
3
Packet Process Pointer
14
14
0
MAC
IPvX
0
8
Dst_Addr
Instructions
2
Packet Process Pointer
0
Fields
16
Src_Addr
Type
MAC
IPvX
0
8
Dst_Addr
16
Src_Addr
Type
[SON13] H. Song, “Protocol-oblivious forwarding: Unleash the power of SDN through a future-proof
forwarding plane, HotSDN ’13. ACM, 2013, pp. 127–132.
A. Capone & C. Cascone: SDN tutorial
64
Tiny programs in the packets
• Taking programmability to the extreme …
• Remember “active networks” …
Ethernet Header
SP = 0x 0
PUSH [ QSi z e]
SP = 0x 4
PUSH [ QSi z e]
0x 00
SP = 0x 8
PUSH [ QSi z e]
0x00
0xa0
SP = 0x c
PUSH [ QSi z e]
0x 00
0x a0
0x 0e
Other headers
(e.g., TCP/IP)
Packet memory is preallocated. The TPP never grows/shrinks inside the network.
[JEY13] V. Jeyakumar, M. Alizadeh, C. Kim, and D. Mazieres, “Tiny packet programs for low-latency
network control and monitoring,”. HotSDN ’13
A. Capone & C. Cascone: SDN tutorial
65
Deeply Programmable Networks (FLARE)
•
•
•
•
Fully programmable control plane
Fully programmable data plane
Flexible and extensible API for both planes
Experimental implementation
x8 6
Processor
M any Core
Processor
(b oard d esig ned b y N akaoLab )
Aki Nakao, FLARE Project, NakaoLab, The university of Tokyo.
A. Capone & C. Cascone: SDN tutorial
66
Not too much not too little:
OpenState and stateful data planes
Too clever is dumb.
[Ogden Nash]
A. Capone & C. Cascone: SDN tutorial
67
Looking for the “right” abstraction
• Programmability and real world viability
– High levels of (deep) programmability in the data
and control planes since ages
• Active Networks
• IETF ForCES
• Keywords for success:
– Pragmatism
– Compromise
– “Right” mix of programmability: right level of
abstraction
• Many wonderful programmable platforms buried in the
“lab world”
A. Capone & C. Cascone: SDN tutorial
68
Remember: OF meant to be a compromise
[original quotes: from OF 2008 paper]
• Best approach: “persuade commercial name-brand
equipment vendors to provide an open, programmable,
virtualized platform on their switches and routers”
– Plainly speaking: open the box!! No way…
• Viable approach: “compromise on generality and seek
a degree of switch flexibility that is
– High performance and low cost
– Capable of supporting a broad range of research
– Consistent with vendors’ need for closed
platforms.
A. Capone & C. Cascone: SDN tutorial
69
OF forces separation of data and control
Logically-centralized control
SMART!
DUMB!
A. Capone & C. Cascone: SDN tutorial
Commands to switches
(Un)install rules,
Query statistics,
Send packets
Events from switches
Topology changes,
Traffic statistics,
Arriving packets
70
Centralized Control: pros and cons
• PROS:
– Central view of the network as a whole
• Network states, etc
– One-click network config/deploy
• Platform agnosting switch API is key - e.g.
OpenFlow forwarding abstraction
• CONS:
– Control latency!!!
Great idea for
network-wide states
and «big picture»
decisions
Poor idea for local
states/decision,
(way!) better
handled locally
(less delay, less load)
• O(second)
1s = 300M packets lost @ 100 gbps
– Signalling overhead
A. Capone & C. Cascone: SDN tutorial
71
Distributed controllers
the «common» way to address such cons
Proprietary controller extensions?
Back to Babel?
A non-solution!
still slow path latency!!
«true» fast path solution: update
forwarding rules in 1 packet
time – 3 ns @ 40B x 100 Gbps
3 ns = 60cm signal propagation…
A. Capone & C. Cascone: SDN tutorial
72
Our vision
SMART!
Events from switches & central rule updates
Restricted to those of interest
for GLOBAL decisions
Decision on how network should operate
remains at the controller (SDN vision)
But “execution” of forwarding plane
updates can be locally delegated
Inject “switch control programs”
Change forwarding behavior as
SMART!
specified by “this program” IF
(local) events occur
Local processing: Ultra low Latency:
o(nanosec) versus o(sec)
Local states: lower signalling
A. Capone & C. Cascone: SDN tutorial
73
What is missing in the picture
Behavioral Description
src=1.2.*.*, dest=3.4.5.*  drop
src = *.*.*.*, dest=3.4.*.*  forward(2)
src=10.1.2.3, dest=*.*.*.*  send to controller
OF forwarding abstraction insufficient!!
Platform-agnostic stateful processing: how to?
«generic»
«repurposed
forwarding
» device
device
Any vendor, any size, any HW/SW platform…
A. Capone & C. Cascone: SDN tutorial
74
Stateless vs. Stateful data plane
Stateless model
(e.g. OpenFlow)
Controller
Global + local states
Stateful model
SMART!
Control
enforcing
Event
notifications
Switch
Stateless
A. Capone & C. Cascone: SDN tutorial
Controller
Global states
Auto-adaption
DUMB!
SMART!
Control
delegation
Switch
Local states
SMART!
75
Easier said than done
• We need a switch architecture and API which is…
– High performance: control tasks executed at wire-speed (packetbased events)
– Platform-independent: consistent with vendors’ needs for
closed platforms
– Low cost and immediately viable: based on commodity HW
Apparently, far beyond OpenFlow switches…
Our (perhaps surprising?) finding:
much closer to OF than expected!!
A. Capone & C. Cascone: SDN tutorial
76
Our findings at a glance
• Any control program that can be described by
a Mealy (Finite State) Machine is already (!)
compliant with OF1.3
• MM + Bidirectional flow state handling
requires minimal hardware extensions to
OF1.1+
• Proof of concept HW and SW implementation
A. Capone & C. Cascone: SDN tutorial
77
Our approach: OpenState
easier understood via a running
example: port knocking
[CCR14] G. Bianchi, M. Bonola, A. Capone, C. Cascone, “OpenState: programming
platform-independent stateful OpenFlow applications inside the switch”, ACM
Computer Communication Review, vol. 44, no. 2, April 2014.
[ARX14] G. Bianchi, M. Bonola, A. Capone, C. Cascone, S. Pontarelli, “Towards Wirespeed Platform-agnostic Control of OpenFlow Switches”, available on ArXiv, 2014.
A. Capone & C. Cascone: SDN tutorial
78
Remember OF match/action API
Programmabile logic
Vendor-implemented
Matching
Rule
Action
1. FORWARD TO PORT
2. ENCAPSULATE&FORWARD
3. DROP
4. …
Extensible
Pre-implemented matching engine
Switch
Port
MAC
src
MAC
dst
Eth
type
VLAN
ID
IP
Src
IP
Dst
IP
Prot
TCP
sport
TCP
dport
Multiple flow tables
since OF version 1.1
A. Capone & C. Cascone: SDN tutorial
79
Background: Port Knocking firewall
knock «code»: 5123, 6234, 7345, 8456
IPsrc=1.2.3.4
Port=5123
Drop(); 1.2.3.4  1° knock OK
IPsrc=1.2.3.4
Port=6234
Drop(); 1.2.3.4  2° knock OK
IPsrc=1.2.3.4
Port=7345
Drop(); 1.2.3.4  3° knock OK
IPsrc=1.2.3.4
Port=8456
Drop(); 1.2.3.4  OPEN port SSH
IPsrc=1.2.3.4
Port=22
A. Capone & C. Cascone: SDN tutorial
Forward()
80
Port Knocking @ controller
DROP
IPsrc=any
Port=any
When knock sequence
finalized, add entry
<Ipsrc, port=22; forward>
Encapsulate & forward
ALL packets of ALL flows
IPsrc=any
Port=any
controller
Maintain Knock state per flow
Lots of overhead!!
Needed as no «knock» state handled in switch
A. Capone & C. Cascone: SDN tutorial
81
«Abstract» description for port
knocking: Mealy Machine
Port!=5123
Port=5123
Port=6234
Port=7345
Port=8456
Port=22
Drop()
Drop()
Drop()
Drop()
Drop()
Forward()
DEFAULT
Stage 1
Stage 2
Stage 3
Port!=6234
Port!=7345
Port!=8456
Drop()
Drop()
Drop()
OPEN
Port!=22
Drop()
A. Capone & C. Cascone: SDN tutorial
82
Can transform in a flow table? Yes:
Ipsrc: ??
MATCH: <state, port>  ACTION: <drop/forward, state_transition>
Plus a state lookup/update
State DB
Metadata:
State-label
IPsrc
Port
Match fields
Actions
state
event
action
Next-state
DEFAULT
Port=5123
drop
STAGE-1
STAGE-1
Port=6234
drop
STAGE-2
STAGE-2
Port=7345
drop
STAGE-3
STAGE-3
Port=8456
drop
OPEN
OPEN
Port=22
forward
OPEN
OPEN
Port=*
drop
OPEN
*
Port=*
drop
DEFAULT
A. Capone & C. Cascone: SDN tutorial
IpsrcOPEN
State DB
83
Putting all together
1) State lookup
IPsrc=1.2.3.4
2) XFSM state transition
Port=8456
STAGE-3
IPsrc=1.2.3.4
Port=8456
XFSM Table
State Table
Flow key
IPsrc= … …
Ipsrc= … …
IPsrc=1.2.3.4
IPsrc=5.6.7.8
IPsrc= … …
IPsrc= no match
state
… … …
… … …
Write:
STAGE-3
OPEN
OPEN
… … …
DEFAULT
write
Match fields
Actions
state
event
action
Next-state
DEFAULT
STAGE-1
STAGE-2
STAGE-3
OPEN
OPEN
*
Port=5123
Port=6234
Port=7345
Port=8456
Port=22
Port=*
Port=*
drop
drop
drop
drop
forward
drop
drop
STAGE-1
STAGE-2
STAGE-3
OPEN
OPEN
OPEN
DEFAULT
3) State update
OPEN
IPsrc=1.2.3.4
Port=8456
1 «program» XFSM table for all flows
(same knocking sequence)
N states, one per (active) flow
A. Capone & C. Cascone: SDN tutorial
84
Proof of concept
• SW implementation:
– Trivial modifications to SoftSwitch
– Public domain
• HW implementation:
– 5 clock (2 SRAM read + 2 TCAM + 1 SRAM write)
– 10 Gbps just requires 156 MHz clock TCAM, trivial
– Optimization in progress (pipelining) for 100 Gbps.
A. Capone & C. Cascone: SDN tutorial
85
Cross-flow state handling
• Yes but what about MAC learning, multi-port protocols
(e.g., FTP), bidirectional flow handling, etc?
MACdst
MACsrc
State Table
lookup
Flow key
48 bit MAC addr
state
Port #
XFSM Table
MACdst
MACsrc
state
event
action
Next-state
Port#
*
forward
In-port
State Table
update
Flow key
48 bit MAC addr
state
Port #
DIFFERENT lookup/update scope
Field 1
Field 2
Flowkey selector
A. Capone & C. Cascone: SDN tutorial
Field N
Read/write signal
86
Current challenge
Prove programmability of complex functions
DONE:
• Port Knocking
• MAC learning
• Label/address
advertisement learning
• Reverse Path Forwarding
• Flow-consistent Load
Balancing
• DDoS multi-stage flow
marking
• …
CHALLENGE:
 IDS/DPI
 TCP flow processing
 Monitoring
…
Need new «actions»
Need extra logic (full XFSM)
All (!) otherwise not possible without
explicit controller’s involvement or
custom distrib. control…
Our challenge: towards an open «flow processor»?
A. Capone & C. Cascone: SDN tutorial
87
Aftermath
• Control intelligence in devices seems possible
– Via Platform-independent abstraction
– Retaining high speed & scalability
– As «small» OpenFlow extension (?!)
• TCAM as «State Machine processor»
– Now Mealy Machines
– Currently working on full XFSM extension
• Rethinking control-data plane SDN
separation?
– Control = Decide! Not decide+enforce!
A. Capone & C. Cascone: SDN tutorial
88
Applied smartness:
stateful applications
There are science and the applications of science,
bound together as the fruit of the tree which bears it.
[Louis Pasteur]
A. Capone & C. Cascone: SDN tutorial
89
Forwarding Consistency
• Ensure consistency in forwarding decisions for
packets of a same transport layer flow
Example: LAG @Internet Exchange Point
Example: Server
Load Balancer
A. Capone & C. Cascone: SDN tutorial
90
Fault Tolerance
• OpenFlow
Fast failover: local
reroute based on port
states (Group table)
A. Capone & C. Cascone: SDN tutorial
But what if a local
reroute in not
available ???
91
openstate-sdn.org
Switch: ofsoftswitch13; Controller: Ryu
A. Capone & C. Cascone: SDN tutorial
92
Hands-on session
Carmelo Cascone
A. Capone & C. Cascone: SDN tutorial
93
Forwarding Consistency
• Ensure consistency in forwarding decisions for
packets of a same transport layer flow
Example: LAG @Internet Exchange Point
Example: Server
Load Balancer
A. Capone & C. Cascone: SDN tutorial
94
Forwarding Consistency
One to Many:
Intra-flow state handling
Many to One:
Cross-flow state handling
Many to Many:
Inter-stage cross-flow state
handling
A. Capone & C. Cascone: SDN tutorial
95
Forwarding Consistency: One to Many
The first packet of a TCP connection coming from the input port
is sent to one of many possible output ports.
All the next packets of the same TCP connection must be
forwarded on the same selected port.
A. Capone & C. Cascone: SDN tutorial
96
Forwarding Consistency: One to Many
OpenFlow solution: the controller is in charge of states management.
controller
First packet of each new TCP connection is sent to the controller
in order to:
-select an output port (e.g. randomly) and forward the packet
-install a flow entry for subsequent packets
A. Capone & C. Cascone: SDN tutorial
97
Forwarding Consistency: One to Many
OpenState solution:
the switch itself handles connection’s state.
A flow is identified by [IP_SRC,IP_DST,TCP_SRC,TCP_DST]
FLOW STATE: output port
First packet of each new TCP connection is sent to the
Group Table in order to:
• select an output port randomly
• store the selected port in the State Table for subsequent
packets
Controller is not involved!
A. Capone & C. Cascone: SDN tutorial
98
Forwarding Consistency: One to Many
•
•
In this case the state is set in the group table
Random Group Entry
Lookup Scope: IP_src, IP_dst, TCP_src,TCP_dst
Update Scope: IP_src, IP_dst, TCP_src,TCP_dst
1) State lookup
IP_src=10.0.0.1
IP_dst=10.0.0.2
2) XFSM state transition
TCP_src=2500
TCP_dst=80
DEFAULT
IP_src=10.0.0.1
IP_dst=10.0.0.2
State Table
IP_dst=10.0.0.2
IP_dst=10.0.0.2
……
IP_dst=10.0.0.2
*
State
TCP_src=1000
……
TCP_src=2500
TCP_src=3000
*
TCP_dst=80
……
TCP_src=80
TCP_dst=80
*
1
…2…
3
DEFAULT
write
4) State update
2
IP_src=10.0.0.1
IP_dst=10.0.0.2
TCP_src=2500
A. Capone & C. Cascone: SDN tutorial
TCP_dst=80
XFSM Table
Flow key
IP_src=10.0.0.1
IP_src=10.0.0.1
……
IP_src=10.0.0.1
*
TCP_src=2500
TCP_dst=80
Match fields
Actions
state
event
action
DEF.
1
2
3
*
*
*
In-port=1
In-port=1
In-port=1
In-port=1
In-port=2
In-port=3
In-port=4
Group(1)
Forward(2)
Forward(3)
Forward(4)
Forward(1)
Forward(1)
Forward(1)
Group Table
Group Entry
Buckets
#
action
Next-state
Entry 1
Forward(2)
Forward(3)
Forward(4)
1
2
3
99
Forwarding Consistency: Many to One
Forwarding consistency must be ensured according to packets
received in the reverse direction.
The first packet of a TCP connection coming from one of the
many input ports is forwarded on the only output port.
All packets of the reverse flow of the same TCP connection
must be forwarded on the same ingress port.
A. Capone & C. Cascone: SDN tutorial
100
Forwarding Consistency: Many to One
OpenFlow solution:
the controller is in charge of states management.
controller
First packet of each new TCP connection is sent to the controller
in order to:
-forward the packet
-install a flow entry for reverse flow’s packets
A. Capone & C. Cascone: SDN tutorial
101
Forwarding Consistency: Many to One
OpenState solution:
the switch itself handles connection’s state.
A flow is identified by [IP_SRC,IP_DST,TCP_SRC,TCP_DST]
FLOW STATE: input port
First packet of each new TCP connection is forwarded and the
input port is stored to forward response packets
Cross-flow state
Controller is not involved!
A. Capone & C. Cascone: SDN tutorial
102
Forwarding Consistency: Many to One
Communication Host -> Server
Lookup Scope: IP_src, IP_dst,TCP_src,TCP_dst
Update Scope: IP_dst,IP_src,TCP_dst,TCP_src
1) State lookup
IP_src=10.0.0.1
IP_dst=10.0.0.100
2) XFSM state transition
TCP_src=2500
TCP_dst=80
DEFAULT
IP_src=10.0.0.1
IP_dst=10.0.0.100
State Table
IP_dst=10.0.0.2
……
IP_dst=10.0.0.1
……
*
State
TCP_src=80
……
TCP_src=80
……
*
TCP_dst=80
XFSM Table
Flow key
IP_src=10.0.0.200
……
IP_src=10.0.0.100
……
*
TCP_src=2500
TCP_dst=1000
……
TCP_dst=2500
……
*
Match fields
2
…1…
……
DEFAULT
Actions
state
event
action
Next-state
1
2
3
*
*
*
In-port=4
In-port=4
In-port=4
In-port=1
In-port=2
In-port=3
Forward(1)
Forward(2)
Forward(3)
Forward(4)
Forward(4)
Forward(4)
1
2
3
write
3) State update
1
IP_src=10.0.0.100
IP_src=10.0.0.1
IP_dst=10.0.0.1
IP_dst=10.0.0.100
TCP_src=80
TCP_dst=2500
TCP_src=2500
TCP_dst=80
A. Capone & C. Cascone: SDN tutorial
DIFFERENT
lookup/update
scope
103
Forwarding Consistency: Many to One
Communication Server -> Host
Lookup Scope: IP_src, IP_dst,TCP_src,TCP_dst
Update Scope: IP_dst,IP_src,TCP_dst,TCP_src
1) State lookup
IP_src=10.0.0.100
IP_dst=10.0.0.1
2) XFSM state transition
TCP_src=2500
TCP_dst=80
1
IP_src=10.0.0.1
IP_dst=10.0.0.100
State Table
IP_dst=10.0.0.2
IP_dst=10.0.0.1
……
*
TCP_src=80
TCP_scr=80
……
*
A. Capone & C. Cascone: SDN tutorial
TCP_dst=80
XFSM Table
State
Flow key
IP_src=10.0.0.200
IP_src=10.0.0.100
……
*
TCP_src=2500
TCP_dst=1000
TCP_dst=2500
……
*
2
1
……
DEFAULT
Match fields
Actions
state
event
action
Next-state
1
2
3
*
*
*
In-port=4
In-port=4
In-port=4
In-port=1
In-port=2
In-port=3
Forward(1)
Forward(2)
Forward(3)
Forward(4)
Forward(4)
Forward(4)
1
2
3
104
Forwarding Consistency: Many to Many
Combining the first two, we want here to load balance on the
output ports while doing reverse path forwarding on the input
port
The first packet of a TCP connection coming from one of the many input ports is
forwarded to one of many possible output ports.
All the next packets of the same TCP connection must be forwarded on the same
selected output port, while all packets of the reverse flow of the same TCP
connection must be forwarded on the same ingress port.
A. Capone & C. Cascone: SDN tutorial
105
Forwarding Consistency: Many to Many
OpenState solution
A flow is identified by [IP_SRC,IP_DST,TCP_SRC,TCP_DST]
Two states are needed for each bidirectional flow:
FLOW STATE 1: output port
FLOW STATE 2: input port
For each first packet of each new TCP connection:
• packet is forwarded to a random output port
• the selected output port is stored in the State Table 0
• the input port is stored in the State Table 1
A. Capone & C. Cascone: SDN tutorial
106
Forwarding Consistency: Many to Many
Communication Host -> Server
Lookup Scope: IP_src, IP_dst, TCP_src,TCP_dst
Update Scope: IP_src, IP_dst, TCP_src,TCP_dst
1) State lookup
IP_src=10.0.0.1
IP_dst=10.0.0.100
TCP_src=2500
2) XFSM state transition
TCP_dst=80
DEFAULT
State Table (Stage 0)
State
Flow key
IP_src=10.0.0.3
IP_src=10.0.0.1
……
IP_src=10.0.0.2
*
IP_dst=10.0.0.100
IP_dst=10.0.0.100
……
IP_dst=10.0.0.100
*
TCP_src=1000
TCP_src=2500
……
TCP_src=3000
*
4) State update (Stage 0)
TCP_dst=80
TCP_src=80
……
TCP_dst=80
*
6
…5…
4
DEFAULT
write
5
IP_src=10.0.0.1
IP_dst=10.0.0.100
TCP_src=2500
A. Capone & C. Cascone: SDN tutorial
IP_dst=10.0.0.100
IP_src=10.0.0.1
TCP_dst=80
Match fields
TCP_src=2500
TCP_dst=80
XFSM Table (Stage 0)
Actions
state
event
action
Next-state
DEF.
4
5
6
DEF.
…
*
*
*
In-port=1
In-port=1
In-port=1
In-port=1
In-port=2
…
In-port=4
In-port=5
In-port=6
Group(1)
Forward(4)
Forward(5)
Forward(6)
Group(1)
…
Table(1)
Table(1)
Table(1)
(1,stg_1)
(2,stg_1)
…
-
Group Table
Group Entry
Buckets
#
action
Next-state
Entry 1
Forward(4)
Forward(5)
Forward(6)
4
5
6
107
Forwarding Consistency: Many to Many
Communication Host -> Server
Lookup Scope: IP_src, IP_dst, TCP_src,TCP_dst
Update Scope: IP_dst, IP_src, TCP_dst,TCP_src
1) State lookup
IP_dst=10.0.0.100
IP_src=10.0.0.1
TCP_src=2500
2) XFSM state transition
TCP_dst=80
DEFAULT
State Table (Stage 0)
IP_src=10.0.0.1
IP_dst=10.0.0.100
IP_dst=10.0.0.100
IP_dst=10.0.0.100
*
IP_dst=10.0.0.100
IP_src=10.0.0.100
IP_dst=10.0.0.1
IP_dst=10.0.0.100
State
Flow key
IP_src=10.0.0.
IP_src=10.0.0.1
IP_src=10.0.0.1
*
IP_src=10.0.0.1
TCP_src=1000
TCP_src=2500
TCP_src=3000
*
TCP_dst=80
TCP_src=80
TCP_dst=80
*
TCP_src=2500
TCP_dst=80
TCP_src=80
TCP_dst=2500
5) State update (Stage 1)
6
5
4
DEFAULT
1
write
Match fields
TCP_src=2500
TCP_dst=80
XFSM Table (Stage 0)
Actions
state
event
action
Next-state
DEF.
4
5
6
DEF.
…
*
*
*
In-port=1
In-port=1
In-port=1
In-port=1
In-port=2
…
In-port=4
In-port=5
In-port=6
Group(1)
Forward(4)
Forward(5)
Forward(6)
Group(1)
…
Table(1)
Table(1)
Table(1)
(1,stg_1)
(2,stg_1)
…
-
State Table (Stage 1)
State
Flow key
IP_src=10.0.0.100
IP_src=10.0.0.100
IP_src=10.0.0.100
……
IP_dst=10.0.0.3
IP_dst=10.0.0.2
IP_dst=10.0.0.1
……
TCP_src=80
TCP_scr=80
TCP_src=80
……
A. Capone & C. Cascone: SDN tutorial
TCP_dst=1000
TCP_dst=3000
TCP_dst=2500
……
3
2
…1…
DIFFERENT lookup/update scope
108
Forwarding Consistency: Many to Many
Communication Server -> Host
Lookup Scope: IP_src, IP_dst, TCP_src,TCP_dst
Update Scope: IP_dst, IP_src, TCP_dst,TCP_src
1) State lookup Stage 0
IP_dst=10.0.0.100
TCP_dst=80
IP_src=10.0.0.1
TCP_src=2500
2) XFSM state transition Stage 0
DEFAULT
State Table (Stage 0)
IP_dst=10.0.0.100
IP_dst=10.0.0.100
IP_dst=10.0.0.100
*
TCP_src=1000
TCP_src=2500
TCP_src=3000
*
TCP_dst=80
TCP_src=80
TCP_dst=80
*
6
5
4
DEFAULT
TCP_dst=80
1
Match fields
4) XFSM state transition Stage 1
IP_dst=10.0.0.100
IP_src=10.0.0.1
TCP_src=2500
XFSM Table (Stage 1)
Match fields
Actions
state
event
action
1
1
1
2
……
In-port=4
In-port=5
In-port=6
In-port=1
……
Forward(1)
Forward(1)
Forward(1)
Forward(2)
……
A. Capone & C. Cascone: SDN tutorial
IP_src=10.0.0.1
State
Flow key
IP_src=10.0.0.
IP_src=10.0.0.1
IP_src=10.0.0.1
*
IP_dst=10.0.0.100
TCP_src=2500
XFSM Table (Stage 0)
Actions
state
event
action
Next-state
DEF.
4
5
6
DEF.
…
*
*
*
In-port=1
In-port=1
In-port=1
In-port=1
In-port=2
…
In-port=4
In-port=5
In-port=6
Group(1)
Forward(4)
Forward(5)
Forward(6)
Group(1)
…
Table(1)
Table(1)
Table(1)
(1,stg_1)
(2,stg_1)
…
-
State Table (Stage 1)
3) State lookup Stage 1
State
Flow key
IP_src=10.0.0.100
IP_src=10.0.0.100
IP_src=10.0.0.100
*
TCP_dst=80
IP_dst=10.0.0.3
IP_dst=10.0.0.2
IP_dst=10.0.0.1
*
TCP_src=80
TCP_scr=80
TCP_src=80
*
TCP_dst=1000
TCP_dst=3000
TCP_dst=2500
*
3
2
1
DEFAULT
109
Forwarding Consistency: Example Results
Results will show the average value of the
time required by 1000 TCP SYN packets to cross the switches at increasing rate.
One-to-Many
Many-to-Many
OpenFlow
Many-to-One
ofsoftswitch13
OpenFlow
ofsoftswitch13
OpenFlow
OpenFlow
Open Vswitch
ofsoftswitch13
OpenState
ofsoftswitch13
OpenFlow
Open Vswitch
OpenFlow
Open Vswitch
OpenState
ofsoftswitch13
OpenState
ofsoftswitch13
Switch: ofsoftswitch13; Controller: Ryu
A. Capone & C. Cascone: SDN tutorial
110
Fault Tolerance
• Ensure the network failure resiliency, quickly
readapting the routing after a failure
• Fundamental function in any network (telco
operators, data centers)
• Weak support in OpenFlow
A. Capone & C. Cascone: SDN tutorial
111
Fault Tolerance
• OpenFlow
Fast failover: local
reroute based on port
states (Group table)
A. Capone & C. Cascone: SDN tutorial
But what if a local
reroute in not
available ???
112
Fault Tolerance
• OpenFlow
controller
Obviously it is always possible to rely on the
controller to:
• forward the packet on the backup path
• install flow entries for the backup path
A. Capone & C. Cascone: SDN tutorial
113
Fault Tolerance in OpenState
With OpenState the switch itself can react to the fault
PKT
TAG
PKT
Proposed solution:
 Faults are signaled using the same data packets
 Packets are tagged and sent back
 Packets are sent back until matched against a node able
to respond to that fault
A. Capone & C. Cascone: SDN tutorial
114
Fault Tolerance
OpenState
• A DETOUR is enabled based on the specific failure without
constraints
• Backup paths can be pre-computed and installed by the
controller (traffic engineering and quality/congestion control)
• The controller is entitled to restore the primary path once the
fault has been resolved
[CAP14] A. Capone, C. Cascone, A. Nguyen, B. Sansò, “Detour Planning for Fast and
Reliable Failure Recovery in SDN with OpenState”, available on ArXiv, Nov. 2014.
A. Capone & C. Cascone: SDN tutorial
115
Fault Tolerance: Fault Reaction Example
OpenState
STATE
TRANSITION!
PKT
TAG
PKT
FLAG
SETUP
TAG
PKT
PKT
Fault_ID=20
Redirect Node:
Detect Node:
FLOW STATE = DEF 20
GLOBAL REGISTERS = 00
TAG = STATE = 20
TAG = FAULT_ID = 20
01
20
DEF
i
A. Capone & C. Cascone: SDN tutorial
116
Fault Tolerance:
Example on larger network
A. Capone & C. Cascone: SDN tutorial
19
Primary node
13
Detect node
17
Forward-back node
16
Redirect node
15
Detour node
117
Fault Tolerance: Example Results
Number of packets lost
OpenState vs. OpenFlow
OpenFlow (Ideal)
OpenFlow (Realistic)
OpenState (Ideal)
OpenState (Realistic)
Ideal case:
0ms failure detection
delay
Realistic case:
Switch embedded failure
detection mechanism
Ping rate (req/s)
A. Capone & C. Cascone: SDN tutorial
118
Thanks
Antonio Capone ([email protected])
Carmelo Cascone ([email protected])
OpenState: openstate-sdn.org
EU project BEBA – http://www.beba-project.eu
This slide-set is available on OpenState web site!
A. Capone & C. Cascone: SDN tutorial
119
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement