- 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.
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.)
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
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
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
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
Stateless operations mean that the match and actions on frames are based only on information included in the frame’s header.
Stateful operations also take into account any information derived from states or history
The Bytcode approach enables separation of the programming language from the HW implementation
This means that any high level language may be used to create the state machines
This also means that any DP ASICs/NPUs etc. can be used with no restrictions
The only part which is standardized is the bytcode, and that has been perfected by Java for a long time
Using this approach, the is no vendor locking, no strict implementation restrictions and big ecosystem
This also means that completing technologies like P4 can be seamlessly integrated into same architecture using same compiler and same JVM infra
Consider the following example:
A common cloud application is a web application which is composed of three tiers:
Web server
App Logic
Database
For security reason Webserver may initiate connection to the AppLogic but AppLogic may not initiate connection to the web server.
In a standard openflow implementation of a stateless firewall we can put a rule that when a first frame is coming from VMa with destination to VMb, we will allow it on both directions and when a first frame comes from VMb to VMa , we will not allow it
For security reason we would only want to allow traffic from VMb to VMa only when the TCP connection status is “established”
The problem with a stateless firewall occurs when we allow the traffic from VMa to VMb on both directions regardless of the state of the TCP connection, as VMb may communicate with VMa, after the session TCP session had ended