ECI OpenFlow 2.0 the Future of SDN
-
Upload
eci-telecom -
Category
Technology
-
view
111 -
download
0
Transcript of ECI OpenFlow 2.0 the Future of SDN
ECI Proprietary
OPENFLOW 2.0 THE FUTURE OF SDN
Hayim PoratCTO
ECI Proprietary 2
AGENDA• Background• Problem statement• Proposes solution• Use cases• Summary
ECI Proprietary 3
STATE OF OPENFLOW
• Openflow (OF) is the leading protocol for SDN implementations
• OF is currently stateless by design
Stateless Stateful
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.)
ECI Proprietary 5
PROPOSED SOLUTION
Transform OF to true Stateful SDN
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
ECI Proprietary 7
STATE MACHINES
0: iconst_21: istore_12: iload_13: sipush 10006: if_icmpge 449: iconst_210: istore_2
SM_j...
PROPOSED SOLUTION - DETAILS
Table 0 Table 1 Table n Stateful Table
ExecutionSet
Action Set Action SetAction Set
Packet out
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_21: istore_12: iload_13: sipush 10006: if_icmpge 449: iconst_210: istore_2
SM_i
ECI Proprietary 8
HOW TO MAKE IT REALLY OPEN?
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
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
Win
dow
s
Text editor
Source code
Compiler
Bytecode
Intel x86
Create & Modify Java
Bytecode
JVMAWindows
RunIntel x86
Bytecode
JVMA
Solaris
Sun SPARC
Bytecode
JVMA
Mac
MAS Power PC
ECI Proprietary 11
Create in any bytecode compliant tool
SDN controller
USING BYTECODE WITH OPEN FLOW DEVELOPMENT ENV.
Hos
t OS Text editor
Source code
Compiler
BytecodeOf 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
ECI Proprietary 12
USE CASES
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
ECI Proprietary 14
Y.1731 STATE MACHINESDELAY MEASUREMENT
ETH-SLM:Fame Loss
Measurement
Synthetic LossMessage (SLM)
Synthetic Loss Reply (SLR)
ETH-LM:Fame Loss
Measurement
Loss Message Measurement
(LMM)
Loss MessageReply (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 link1.Send link
failure alarm2.Instantiate
APS
ECI Proprietary
SDN App
OF Switch
Host D
Access S
witch
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
WAN1WAN2WAN3WAN4
SDN APP
VNIC
NIC
Scheduler
ECI Proprietary
Standard Switch
SDN App
OF Switch
Host D
Access S
witch
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
WAN1WAN2WAN3WAN4
SDN APP
VNIC
NIC
Scheduler NMS
SDN Controller
OpenFlow
APS
ECI Proprietary
SDN App
OF Switch
Host D
Access S
witch
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
WAN1WAN2WAN3WAN4
SDN APP
VNIC
NIC
Scheduler
Path Selector Logic and State machine templates
SDN Controller
OpenFlow
APS
ECI Proprietary 18
STATEFUL FIREWALL FOR CLOUD
VMa VMb
Web Server App logic Database
VMa
VSwitch a
VMb
VSwitch b
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
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
ECI Proprietary 21
FREQUENTLY ASKED QUESTIONS
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
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
+
+
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
ECI Proprietary
THANK YOU!
25