- The document proposes adding stateful capabilities to OpenFlow 2.0 in order to better support use cases that require stateful processing like APS and load balancing. - It suggests including a stateful flow table, programmable state machines, and the ability to generate and process frames within OpenFlow switches. - To ensure interoperability, it recommends adopting a bytecode approach where any programming language could be used to define state machines which are then compiled to a common bytecode format and run on switches from different vendors.

1. ECI Proprietary
OPENFLOW 2.0
THE FUTURE OF
SDN
Hayim Porat
CTO

2. ECI Proprietary 2
AGENDA
• Background
• Problem statement
• Proposes solution
• Use cases
• Summary

3. ECI Proprietary 3
STATE OF OPENFLOW
• Openflow (OF) is the leading protocol for SDN
implementations
• OF is currently stateless by design
Stateless Stateful

4. ECI Proprietary 4
PROBLEM STATEMENT
• OF fails to provide good solution to some
popular use cases that are based on
tasteful frame-by-frame decision:
̶ APS (Automatic protection switching)
̶ Load balancing
̶ Bandwidth capping
• No notion of a flow as a set of
interrelated ingress and egress
traffic streams
• No notion of flow context, e.g.
User, Originating VM
• No ability to generate frames
(e.g. CCMs, 1588, etc.)

5. ECI Proprietary 5
PROPOSED
SOLUTION
Transform OF
to true Stateful
SDN

6. ECI Proprietary 6
PROPOSED SOLUTION
• Add Stateful flow table, context, frame
generation and states to OF
• Offload flow and state processing to the FE
• Extend OF with new flow table type
“Stateful”
• Associate “Stateful” table with a set of
programmable state machines
• Extend OF to enable association
and programming of state machines
• Controller retains global
network view

7. ECI Proprietary 7
STATE MACHINES
0: iconst_2
1: istore_1
2: iload_1
3: sipush 1000
6: if_icmpge 44
9: iconst_2
10: istore_2
SM_j...
PROPOSED SOLUTION - DETAILS
Table 0 Table 1 Table n Stateful Table
Execution
Set
Action Set Action Set
Action Set
Packetout
Packet in
Programmable module within
the switch, maintains and runs the
various user-defined state machines
Converted from high level programs
into bytecode
Modified Openflow Switch
0: iconst_2
1: istore_1
2: iload_1
3: sipush 1000
6: if_icmpge 44
9: iconst_2
10: istore_2
SM_i

8. ECI Proprietary 8
HOW TO MAKE IT
REALLY OPEN?

9. ECI Proprietary 9
CREATING A VENDOR AGNOSTIC SOLUTION
 Deciding on a one way to develop state machines /applications could be
problematic
 Same goes for deciding on one single way to implement in the switches
 On the other hand, loose definitions would lead to interoperability
problems
̶ Same problems that hurdled OF in the first place

10. ECI Proprietary 10
ADOPTING THE BYTECODE APPROACH
 Enables separation of the programming
language from the HW implementation
 Any high level language may be used
 Any DP ASICs/NPUs etc. can be used
 The only part which is standardized is the bytecode
 Ensures: no vendor locking, no strict
implementation restrictions and big
ecosystem
 Completing technologies can be
seamlessly integrated into same
architecture using same compiler and
same JVM infrastructure
Write Java source code
Windows
Text editor
Source code
Compiler
Bytecode
Intel x86
Create & Modify Java
Bytecode
JVMA
Windows
Run
Intel x86
Bytecode
JVMA
Solaris
Sun
SPARC
Bytecode
JVMA
Mac
MAS
Power PC

11. ECI Proprietary 11
Create in any bytecode
compliant tool
SDN controller
USING
BYTECODE
WITH OPEN
FLOW DEVELOPMENT ENV.
HostOS
Text editor
Source code
Compiler
Bytecode
Of apps P4 code other
BytecodeJVMA
Datapath Multicore
Embedded OS A
Switch
Vendor C
BytecodeJVMA
Datapath NPU
Embedded OS A
Switch
Vendor B
BytecodeJVMA
Datapath ASIC
Embedded OS A
Switch
Vendor A

12. ECI Proprietary 12
USE CASES

13. ECI Proprietary 13
USE CASE: AUTOMATIC PROTECTION SWITCHING
Y.1731 APS is a set of mechanisms to detect and isolate faults on Ethernet networks. These faults can be
simple connectivity faults or more complex faults due to misconfigurations (cross-connect & remote MEP
errors). The basic principal is that end nodes (MEPs) exchange regular messages called Continuity Check
Messages (CCM). The message rate is configurable from 3.3ms up to 10 minutes for each service.
Service
Provider #1
Service
Provider #2

14. ECI Proprietary 14
Y.1731 STATE MACHINES
DELAY MEASUREMENT
ETH-SLM:
Fame Loss
Measurement
Synthetic Loss
Message (SLM)
Synthetic Loss
Reply (SLR)
ETH-LM:
Fame Loss
Measurement
Loss Message
Measurement
(LMM)
Loss Message
Reply (LMR)
FRAME LOSS MEASUREMENT CONTINUALLY CHECK PROTOCOL
ETH-DM:
Frame Delay
(FD) & Frame
Delay Variation/
Jitter (FDV)
Measurements
Delay Measurement
Message (DMM)
Delay Measurement
Reply (DMR)
Notes:
• Clock synchronization will be done via
NTP
• CCM intervals: 3.3ms, 10ms (default),
100ms, 1s, 10s, 1min, 10min
Typewriter
On
main
link
1 CCM
Missing
2 CCMs
Missing
No CCM
received
No CCM
Received
No CCM
Received
Received
CCM
Received
CCM
Received
CCM
10 intervals
Received
CCM
Failed link
1.Send link
failure alarm
2.Instantiate
APS

15. ECI Proprietary
SDN App
OF Switch
Host D
AccessSwitch
CCM Generator
Y.1731
OpenFlow
SDN Controller
DBCEP
OPTION 1: APS AS A SDN APP
• CCM is generated at
app and not at port
• Spurious delay added
to state machine
• Overloaded NBI/ SBI
Host C
Host B
Host A
APS Path
Selector
Rules
WAN1
WAN2
WAN3
WAN4
SDN APP
VNIC
NIC
Scheduler

16. ECI Proprietary
Standard Switch
SDN App
OF Switch
Host D
AccessSwitch
Y.1731
DB
OPTION 2: APS ON A HYBRID SWITCH
• OpenFlow is out of
the loop
• SDN is limited to the
stateless operations
• “Split Brain” operation
Host C
Host B
Host A
WAN1
WAN2
WAN3
WAN4
SDN APP
VNIC
NIC
Scheduler
NMS
SDN Controller
OpenFlow
APS

17. ECI Proprietary
SDN App
OF Switch
Host D
AccessSwitch
CCM GeneratorY.1731
DBCEP
PROPOSED SOLUTION: APS STATE MACHINES AT
OPEN FLOW SWITCH
• CCM is generated at
switch, where it should
• Full control by SDN app
and controller
• Frame operation is
delegated to switch and
SDN controller is
offloaded
Host C
Host B
Host A
WAN1
WAN2
WAN3
WAN4
SDN APP
VNIC
NIC
Scheduler
Path Selector Logic and State machine templates
SDN Controller
OpenFlow
APS

18. ECI Proprietary 18
STATEFUL FIREWALL FOR CLOUD
VMa VMb
Web Server App logic Database
VMa
VSwitch a
VMb
VSwitch b

19. ECI Proprietary 19
USE CASE CONT. - TCP STATE MACHINE
 TCP connection have several states such
as: closed, listen, Syn received,
established etc.)
 This state would be tracked in the stateful
flow table with Stateful OF, so the OF sate
would be would be the TCP state
 The state can be inferred from the TCP
flags (e.g. syn, ack, fin etc) and they
sequence in which they appear in the
traffic, as detailed in the TCP state
machine description

20. ECI Proprietary 20
SUPERIOR FRAME
PROCESSING
Achieved by offloading state
management from controller
and app to the switch
SUPERIOR DISTRIBUTION
OF FRAME PROCESSING
across the network
by utilizing many switches vs.
few controllers or apps
SUPERIOR OPTIMIZATION
for state machine
processing
by leveraging multicore NPs
etc.
STATEFUL APS FOR CLOUD – ADVANTAGES OF
PROPOSAL

21. ECI Proprietary 21
FREQUENTLY
ASKED
QUESTIONS

22. ECI Proprietary 22
WHY WAS IT NOT
IMPLEMENTED
UNTIL NOW?
 Actually the openflow specification does
include state machine specifications for
two use cases: LAG and Link protection
 These use cases had been
“baked” into the protocol without
further programmability
 Our suggestion is to make
the OF specification truly
programmable

23. ECI Proprietary 23
HOWEVER, IS STILL SDN?
Lets check the proposed solution using
criteria for SDN as stipulated by ONF:
Directly programmable
Agile
Centrally managed
Programmatically configured
Open standards-based
and vendor-neutral

+
+





24. ECI Proprietary 24
WILL IT FRAGMENT THE OPENFLOW SWITCH
IMPLEMENTATION?
• Even today there are many types of “Ethernet” switches
• There is no one implementation of an Ethernet switch
• Each implementation is used for a specific use case
• The same will be with stateful OF switches that will be used as needed

25. ECI Proprietary
THANK YOU!
25