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