Unifying Packet & Circuit Networks with OpenFlow

Unifying Packet & Circuit Networks

with OpenFlowSaurav Das, Guru Parulkar, & Nick McKeown

Stanford University

Huawei, Feb 3rd 2010

http://openflowswitch.org

Internet has many problems

Plenty of evidence and documentation

Internet’s “root cause problem”

It is Closed for Innovations

2

Million of linesof source code

5400 RFCs Barrier to entry

500M gates10Gbytes RAM

Bloated Power Hungry

We have lost our way

Specialized Packet Forwarding Hardware

OperatingSystem

App App App

Routing, management, mobility management, access control, VPNs, …

SoftwareControl

Router

HardwareDatapath

Auth

entica

tion,

Secu

rity, A

ccess

Contro

l

HELLO

MPLS

NATIPV6

anycastmulticas

tMobile IP

L3 VPN

L2 VPN VLANOSPF-TE

RSVP-TEHELLOHELLO

Firewall

Multi layer m

ulti

region

iBGP,

eBGP

IPSec

Many complex functions baked into the infrastructureOSPF, BGP, multicast, differentiated services,Traffic Engineering, NAT, firewalls, MPLS, redundant layers, …

An industry with a “mainframe-mentality”

Operating SystemOperating System

Reality

App

AppApp




OperatingSystem

App App App

• Lack of competition means glacial innovation• Closed architecture means blurry, closed interfaces

DeploymentIdea Standardize

Wait 10 years

Glacial process of innovation made worse by captive standards

process

• Driven by vendors• Consumers largely locked out• Glacial innovation


App

App

App


App

App

App


App

App

App


App

App

App


OperatingSystem

OperatingSystem

OperatingSystem

OperatingSystem

OperatingSystem

App

App

App

Network Operating System

App App App

Change is happening in non-traditional markets

App

Simple Packet Forwarding Hardware



App App

Simple Packet Forwarding Hardware Simple Packet

Forwarding Hardware

Network Operating System

1. Open interface to hardware

3. Well-defined open API2. At least one good operating system

Extensible, possibly open-source

The “Software-defined Network”

The change has already started

In a nutshell– Driven by cost and control– Started in data centers…. and may spread– Trend is towards an open-source,

software-defined network– Growing interest for cellular and telecom networks

Example: New Data Center

Cost200,000 serversFanout of 20 10,000 switches$5k commercial switch $50M$1k custom-built switch $10M

Savings in 10 data centers = $400M

Control

1.Optimize for features needed2.Customize for services & apps3.Quickly improve and innovate

Large data center operators are moving towards defining their own network in software.

Windows(OS)

Windows(OS)

Linux MacOS

x86(Computer)

Windows(OS)

AppApp

LinuxLinuxMacOS

MacOS

Virtualization layer

App

Controller 1

AppApp

Controller2

Virtualization or “Slicing”

App

OpenFlow

Controller 1NOX(Network OS)

Controller2Network OS

Trend

Computer Industry Network Industry

Simple common stable hardware substrate below+ programmability + strong isolation model + competition above = Result : faster innovation

Signaling

Control

Data

Simple, Robust, ReliableData Path

Controller

DecoupledAutomated Control

Open Interface

Into Hardware

The Flow Abstraction

Rule(exact & wildcard)

Action Statistics


Action Statistics


Action Statistics


Default Action Statistics

Exploit the flow table in switches, routers, and chipsets

Flow 1.

Flow 2.

Flow 3.

Flow N.

e.g. Port, VLAN ID, L2, L3, L4, …

e.g. unicast, mcast, map-to-queue, drop

Count packets & bytesExpiration time/count

14

Controller

OpenFlow Switch

FlowTableFlowTable

SecureChannelSecureChannel

OpenFlow

Protocol

SSL

hw

sw

OpenFlow Switching

• Add/delete flow entry• Encapsulated packets• Controller discovery

A Flow is any combination of above fields described in the Rule

ControllerFlow Example

OpenFlowProtocol

Rule Action Statistics

Rule Action Statistics Rule Action Statistics

A Flow is the fundamentalunit of manipulation within a switch

Routing

OpenFlow is Backward Compatible

Ethernet Switching

*

SwitchPort

MACsrc

MACdst

Ethtype

VLANID

IPSrc

IPDst

IPProt

TCPsport

TCPdport

Action

* 00:1f:..* * * * * * * port6

Application Firewall

*

SwitchPort

MACsrc

MACdst

Ethtype

VLANID

IPSrc

IPDst

IPProt

TCPsport

TCPdport

Action

* * * * * * * * 22 drop

IP Routing

*

SwitchPort

MACsrc

MACdst

Ethtype

VLANID

IPSrc

IPDst

IPProt

TCPsport

TCPdport

Action

* * * * *5.6.7.8

* * * port6

OpenFlow allows layers to be combined

VLAN + App

*

SwitchPort

MACsrc

MACdst

Ethtype

VLANID

IPSrc

IPDst

IPProt

TCPsport

TCPdport

Action

* * * vlan1 * * * * 80 port6, port7

Flow Switching

port3

SwitchPort

MACsrc

MACdst

Ethtype

VLANID

IPSrc

IPDst

IPProt

TCPsport

TCPdport

Action

00:1f..0800 vlan1 1.2.3.4 5.6.7.84 17264 80 port600:2e..

port3

SwitchPort

MACsrc

MACdst

Ethtype

VLANID

IPSrc

IPDst

IPProt

TCPsport

TCPdport

Action

0800 5.6.7.8 4 port 1000:2e..

Port + Ethernet + IP

* ****

A Clean Slate Approach

18

Goal: Put an Open platform in hands of researchers/students to test new ideas at

scaleApproach:

1. Define OpenFlow feature2. Work with vendors to add OpenFlow to their switches

3. Deploy on college campus networks4. Create experimental open-source software - researchers can build on each other’s work

OpenFlow Hardware

Cisco Catalyst 6k

NEC IP8800

HP Procurve 5400

Juniper MX-series WiMax (NEC) WiFi

Quanta LB4G Ciena CoreDirectorArista 7100 series (Fall 2009) (Fall 2009)

OpenFlow Deployments

• Stanford Deployments– Wired: CS Gates building, EE CIS building, EE Packard

building (soon)– WiFi: 100 OpenFlow APs across SoE– WiMAX: OpenFlow service in SoE

• Other deployments– Internet2– JGN2plus, Japan– 10-15 research groups have switches

Research and Production Deployments on commercial hardware

Juniper, HP, Cisco, NEC, (Quanta), …

UW

Stanford

UnivWisconsin

IndianaUniv

Rutgers

Princeton

ClemsonGeorgia

Tech

Internet2

NLR

Nationwide OpenFlow Trials

Production deployments before end of 2010

Production deployments before end of 2010

DDC

DDC

DDC

DDC

IP/MPLSIP/MPLS IP/MPLS

IP/MPLS

IP/MPLSIP/MPLS

IP/MPLSIP/MPLS

CDD

CDD

CDD

DD

DD

DD

DD

C C

DD

DD

GMPLS

Motivation

IP and Transport networks

are separate networks that are controlled and managed

independently leading to duplication of functions and resources

in multiple layers and high capex and opex

do not dynamically interact and thus do not benefit from

diverse switching technologies

have very different architectures that makes integrated

operation and convergence hard

FlowNetwork

DDC

DDC

DDC

DDC

IP/MPLSIP/MPLS IP/MPLS

IP/MPLS

IP/MPLSIP/MPLS

IP/MPLSIP/MPLS

CDD

CDD

CDD

DD

DD

DD

DD

C C

DD

DD

GMPLS

UCP

pac.c

FlowNetwork

… that switch at different granularities: packet, time-slot, lambda & fiber

Simple,Robust,Reliablenetwork of Flow Switches

Research Goal: Packet and Circuit Flows Commonly Controlled & Managed

25

OpenFlow & Circuit Switches

Exploit the cross-connect table in circuit switches

Packet FlowsSwitchPort

MACsrc

MACdst

Ethtype

VLANID

IPSrc

IPDst

IPProt

TCPsport

TCPdport

Action

25

Circuit Flows

Signal Type

VCG25 Signal Type

VCG

The Flow Abstraction presents a unifying abstraction

… blurring distinction between underlying packet and circuit and regarding both as flows in a flow-switched network

Unified Architecture

OPENFLOW Protocol

PacketSwitch

CircuitSwitch

Packet & Circuit Switch

NETWORK OPERATING SYSTEM

Underlying Data Plane SwitchingUnderlying Data Plane Switching

AppApp AppApp AppApp AppApp

UnifiedControl Plane

Unifying Abstraction

Networking Applications

Congestion ControlQoS

27

OpenFlow UCPenables innovation

@pkt-ckt interface

NetworkRecovery

Traffic Engineering

PowerMgmt

SecurityDiscovery

Routing

IN OUT

GE ports

TDM ports

Packet

Switch Fabric

Packet

Switch Fabric

OpenFlow(software)OpenFlow(software)

R A S R A S

IP 11.12.0.0 + VLAN2, P1 VLAN2 VCG 3

OpenFlow(software)OpenFlow(software)

VLAN 1025 + VLAN2, P2

VLAN7 VCG5

Packet Switch FabricPacket Switch Fabric

IP 11.13.0.0 TCP 80

+ VLAN7, P2

TDM

CircuitSwitch Fabric

VCG5

VCG3

VCG3 P1 VC4 1 P2 VC4 4 P1 VC4 10

VCG5 P3 STS192 1

OpenFlow Example

Congestion Control

Congestion Control

Example Application (1)

..via Variable Bandwidth Packet Links

OpenFlow Demo at SC09

TrafficEngineering


TrafficEngineering


..via Dynamic Automated Optical Bypass

Controller

OpenFlowprotocol

AWGWSS(1×9)

AWG Fujitsu WSS basedOF circuit switch

Ethernet

Hosts

NOX

WSS(1×9)

NetFPGA basedOF packet switch

Openflow Circuit Switch

25 km SMF

OpenFlow packet switch OpenFlow packet switch

GE-Optical

GE-Optical

Mux/Demux

OpenFlow Protocol

C

C C

FLOWVISOR

OpenFlow Protocol

CK

CK

CK

PP

CK

P

CKP

Unified Virtualization

OpenFlow Protocol

C C C

FLOWVISOR

OpenFlow Protocol

CK

CK

CK

PP

CK

P

CKP

ISP ‘A’ Client Controller

Private Line Client Controller

High-end Client Controller

Under Transport n/w Service Provider control

IsolatedClient

Network Slices

SinglePhysical

Infrastructureof Packet &

Circuit Switches

Unified Virtualization

Summary• OpenFlow is a large clean-slate program with many motivations and goals

• convergence of packet & circuit networks is one such goal

• OpenFlow simplifies and unifies across layers and technologies

• packet and circuit infrastructures - electronics and photonics• while unified API allow innovations

• in data and control planes independently• in network control, management and virtualization

• Example demonstrations at circuit & packet intersection

• Variable Bandwidth Packet Links• Dynamic Automated Optical Bypass

• More @ http://openflowswitch.org/wk/index.php/PAC.C

http://openflowswitch.org/wk/index.php/PAC.C

Backup

Issues with Current IP & Transport n/w• Separate management systems and incompatible protocols - complexity of managing across several layers, interfaces & architectures, leading to duplication of resources and functions

• Lack of a unified architecture across packet and circuit –• fully distributed with tightly linked control and data planes in packet networks, • fully distributed, decentralized or fully centralized in transport networks,• multiple vendor domains with proprietary interfaces prevent greater integration and increase complexity

• GMPLS the only attempt towards a UCP across packet & circuit (2000)

• Today – Packet vendors and ISPs are not interested• Transport n/w SPs view it as a signaling tool available to the mgmt system for provisioning private lines (not related to the Internet)• After 10 yrs of development, next-to-zero significant deployment• GMPLS Issues

•Issues are when considered as a unified architecture and control plane

• control plane complexity escalates when unifying across packets and circuits because it

• makes basic assumption that the packet network remains same: IP/MPLS network – many years of legacy L2/3 baggage• and that the transport network remain same - , multiple layers and multiple vendor domains

• use of fragile distributed routing and signaling protocols with many extensions, increasing switch cost & complexity, while decreasing robustness

• does not take into account the conservative nature of network operation -

• can IP networks really handle dynamic links? • Do transport network service providers really want to give up control to an automated control plane?

• does not provide easy path to network virtualization

Issues with GMPLS

LMP

HELLO

41

UNI

TL-1GMPLS

PBB-TECarrier

EthernetMPLS-TP

ASON

ENNI intra

ENNI inter

OSPF-TE

RSVP-TEHELLOHELLO

CORBA

L1VPN

,

L2VPN

PCE PWE3

Many complex functions baked into the infrastructure

More coming ……

Control Plane

Data Plane

OF Protocol

Control Plane Architectures

OpenFlow: Architecture Concepts• Separate data from control

– A standard protocol between data and control

• Define a “generalized flow” based data path– Very flexible and generalized flow abstraction

– Delayer or open up layers1-7

• Hierarchically centralized “open” controller with API– For control and management applications

• Virtualization of data and control planes • Backward compatible

– Though allows completely new header

OpenFlow: Architecture Implications• Separate data from control

– Independent innovations in data and control planes

– Less dependence on a single vendor

• Define a “generalized flow” based data path– Simpler data path: cheaper, uniform, stable

– Applicable across technologies and layers

• Hierarchically centralized “open” control with an API– Easier to make reliable and robust

– Enables lots of innovations by different stakeholders

OpenFlow: Architecture Implications• Virtualization

– Enable innovations and experimentation

– Deployment of new ideas: “production revision control”

• Backward compatible– Easy to support in existing switches/routers and networks

– Easy to show the value proposition

Software Defined Networking

Documents

Unifying Packet & Circuit Networks with OpenFlow