J A N U A R Y 2 0 1 3

SDN – Hybrid architecture

SDN switches – current status

OpenFlow switch has OpenFlow “agent” control plane logic on board

OpenFlow Standard assumes switch is “free-standing” – no really accommodate any other control plane

Hybrid switch – why we need it

Transition mechanism - allowing users to shift services to an OpenFlow basis gradually, as opposed to all-or-nothing approach

Missing features - To provide functionality that OpenFlow does not support (yet) - at least does not support in the version of OpenFlow actually available

Correct behavior - To support functionality that OpenFlow COULD support - but that is better delegated to switch-local implementation for scalability and efficiency reasons

Hybridization approaches

Ships in the night - each side (OpenFlow and current ) thinks it is alone, with no cooperation / coordination of their actions

Integrated Approach - allow the sides to co-operate

Ships in the night approach

The switch imposes Traffic Separation soon after ingress into two separate domains - OpenFlow and "other". The two common approaches are:

To separate by the Port (i.e. on some ports ALL traffic is OpenFlow, and on the other ports ALL traffic is Non-OpenFlow)

To separate by VLAN (i.e. ALL traffic in some VLAN(s) is sent to OpenFlow, and ALL traffic in all other VLANs is Non-OpenFLow)

Ships in the night – advantages and disadvantages

Simple to implement

Very hard (or impossible) to share information between Nodes connected to OpenFlow Ports/VLANs and nodes connected to Non-OpenFlow Ports/VLANs. In effect, the user is forced to build two separate networks - a regular one, and a separate Overlay

OpenFlow network. Any servers needed for Network operation (DHCP, DNS, RAS, AAA, ...) may have to be duplicated (or at least given two separate interfaces, one into each network).

In the most common case, of VLAN-based separation, users usually can't use VLANs at all, and moreover, depending on which mechanism is used to classify incoming traffic into VLANs, some security concerns may occur (e.g. if users send VLAN-tagged traffic, they can potentially get into or out of the OpenFlow network contrary to desired result)

In general, traffic sent to the OpenFlow side can only get the functionality OpenFlow supports even if the underlying systems can do better.

Functionality that has to apply to all frames has to be implemented twice - once on the OpenFlow side (assuming it is possible) and once on the "traditional" side.

Integrated Approach – By-Function choice

OpenFlow is considered an additional control input to the single, integrated data-plane.

The users can decide by-function if it will be configured by:

OpenFlow mechanism

Traditional Mechanism

Combination of Both

All Traffic is subject to handling controlled by both sides

Integrated approach– advantages and disadvantages

More complicate to implement

It is a Superset - user may still implement by-the-port or by-the-VLAN traffic separation, when desired. However, this is now a CHOICE to be made by the system administrator, rather than a forced limit imposed by the switch implementation. Moreover, this is not an all-or-nothing choice user can set a some ports or VLANs to OpenFlow-Only, some to Traditional-only, and some to mixed-mode operation.

It easier to migrate service to OpenFlow gradually, because when service/functionality X is migrated to OpenFlow, other needed services, still implemented by Traditional means can still apply to the same traffic. (e.g. All traffic can still be subject to Traditional L3 routing, while OpenFlow overrides the L2 forwarding, allowing policy-controlled traffic engineering to set links used to reach next-hop targets)

End-User has better visibility - if OpenFlow is used as a control-input to the general switch control implementation, naturally its operation is visible using the usual means system administrators are already familiar with. For example, in Marvell's hybrid switch the "show Running Configuration" CLI command (and its equivalents in GUI, SNMP and XML) will all show both configurations originating from Traditional channels and configurations coming from the OpenFlow side. This makes it much easier to understand and debug switch operation.

System Administrator is given Maximum capability and flexibility - any and all traffic can get any functionality the switch supports. There is nothing "forbidden“ or only available to SOME traffic. Given that only end-user really knows what is needed in the field, this is a big advantage, since any assumptions by switch implementer into how the switch "should" be used become in reality limitation on how the switch CAN be used

It is possible (and easy) to create synergies - OpenFlow can be used to supplement traditional services, and can co-operate with "traditional" control plane to create a best-of-both-worlds combinations. For example, OpenFlow can be applied to a selected subset of the traffic, leaving the Simple case to be handled by Traditional means.

Integrated approach– advantages and disadvantages

Network Device

Data Plane

Control Plane (on-board or local)

Management Plane (off-board)

Hybrid Switch Components and Interfaces

Program Web

Browser Telnet,

SSH NMS

Console

API Web

Server CLI

Parser SNMP Agent

OF Conf Agent

OF Agent

OpenFlow C&M

Management Plane, Control

Plane (off-board)

SDN / OF app

OF Controller

Forwarding Pipeline

On-board Logic

Node

To

Node

Protocols

HTML XML,

Netconf, etc’ ASCII SNMP

OF Config OF Wire

LN-2124OF –Switch with DualBoot© system

HW options 24 port 1GE Base-T 4 ports 10GE SFP+

2 SW Systems in one switch Fully featured L2, L3 with ROS and OpenFlow – VX-Works-

based Linux with OpenFlow – open source for development and

study SDK provided on www.larch-networks.com

Thank you!

networks.com-www.larch