OpenFlow e redes definidas por software

Um novo paradigma de controle e inovação em redes de pacotes

2

Agenda

Introdução

Fundamentos do protocolo OpenFlow- O que é? Porque? Como?

Tendencia: Software-Defined Networking

Implementações, produtos e interesse da industria

Cenarios de aplicação e exemplos

CPqD RouteFlow- Projeto, Arquitetura, Comunidade open-source

3

Resumo Executivo

4

Verticalização

Fechado, proprietário

Inovação lenta

AppAppAppAppAppAppAppAppAppAppApp

Horizontalização

Interfaces abertas

Inovação rápida

Plano de

Controle

Plano de

Controle

Plano de

Controleou ou

Interface Aberta

Plano de Controle

Especializado

Hardware Especializado

Funcionalidades especializadas

Chip Comercial (commodity)

Interface Aberta

Black-Box Networking vs. Software Defined Networking

5

Windows

(OS)Windows

(OS)Linux

Mac

OS

x86

(Computer)

Windows

(OS)

AppApp

LinuxLinuxMac

OSMac

OS

Virtualization layer

App

Controller 1

AppApp

Controller

2

Virtualization or “Slicing”

App

OpenFlow

Controller 1NOX(Network OS)

Controller

2Network OS

Tendência

Computer Industry Network Industry

Oportunidade para que se crie uma industria nacional para software de (gerenciamento e controle) de rede.

“Mainframe”

6

What is OpenFlow?

7

Short Story: OpenFlow is an API

Control how packets are forwarded (and manipulated)Implementable on COTS hardwareMake deployed networks programmable- not just configurable (e.g., via CLI)- vendor-independent

Makes innovation easier

Goal (experimenter’s perspective):- Validate experiments on deployed hardware with real traffic at line

speed

Goal (industry perspective):- Reduced equipment costs through commoditization and competition in

the controller / application space- Customization and in-house (or 3rd party) development of new

networking features (e.g. protocols).

8

Why OpenFlow?

9

Million of linesof source code

5400 RFCs Barrier to entry

Billions of gates Bloated Power Hungry

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

An industry with a “mainframe-mentality”, reluctant to change

The Ossified Network

Specialized Packet Forwarding Hardware

OperatingSystem

Feature Feature

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

10

Industry: Network vs. Computer Equipment

11

Research: Open Systems

Performance Fidelity

Scale Real User Traffic?

Complexity Open

Simulation medium medium no medium yes

Emulation medium low no medium yes

Software Switches

poor low yes medium yes

NetFPGA high low yes high yes

Network Processors

high medium yes high yes

Vendor Switches high high yes low no

gap in the tool spacenone have all the desired attributes!

12

OpenFlow: a pragmatic compromise

+ Speed, scale, fidelity of vendor hardware

+ Flexibility and control of software and simulation

Vendors don’t need to expose implementation

Leverages hardware inside most switches today (ACL tables)

15

How does OpenFlow work?

16

Ethernet SwitchEthernet Switch

17

Data Path (Hardware)Data Path (Hardware)

Control PathControl PathControl Path (Software)Control Path (Software)

18

Data Path (Hardware)Data Path (Hardware)

Control PathControl Path OpenFlowOpenFlow

OpenFlow ControllerOpenFlow Controller

OpenFlow Protocol (SSL/TCP)

19

Controller

PC

HardwareLayer

SoftwareLayer

Flow Table

MACsrc

MACdst

IPSrc

IPDst

TCPsport

TCPdport Action

OpenFlow Client

**5.6.7.8*** port 1

port 4port 3port 2port 1

1.2.3.45.6.7.8

OpenFlow Example

20

OpenFlow Basics Flow Table Entries

SwitchPort

MACsrc

MACdst

Ethtype

VLANID

IPSrc

IPDst

IPProt

L4sport

L4dport

Rule Action Stats

1. Forward packet to zero or more ports2. Encapsulate and forward to controller3. Send to normal processing pipeline4. Modify Fields5. Any extensions you add!

+ mask what fields to match

Packet + byte counters

VLANpcp

IPToS

21

Examples

Switching

*

SwitchPort

MACsrc

MACdst

Ethtype

VLANID

IPSrc

IPDst

IPProt

TCPsport

TCPdport Action

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

Flow Switching

port3

SwitchPort

MACsrc

MACdst

Ethtype

VLANID

IPSrc

IPDst

IPProt

TCPsport

TCPdport

Action

00:20.. 00:1f.. 0800 vlan1 1.2.3.4 5.6.7.8 4 17264 80 port6

Firewall

*

SwitchPort

MACsrc

MACdst

Ethtype

VLANID

IPSrc

IPDst

IPProt

TCPsport

TCPdport Action

* * * * * * * * 22 drop

22

Examples

Routing

*

SwitchPort

MACsrc

MACdst

Ethtype

VLANID

IPSrc

IPDst

IPProt

TCPsport

TCPdport Action

* * * * * 5.6.7.8 * * * port6

VLAN Switching

*

SwitchPort

MACsrc

MACdst

Ethtype

VLANID

IPSrc

IPDst

IPProt

TCPsport

TCPdport

Action

* * vlan1 * * * * *

port6, port7,port9

00:1f..

23

Centralized vs Distributed ControlBoth models are possible with OpenFlow

Centralized Control

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

Controller

Distributed Control

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

Controller

Controller

Controller

24

Flow Routing vs. AggregationBoth models are possible with OpenFlow

Flow-Based

• Every flow is individually set up by controller

• Exact-match flow entries• Flow table contains one

entry per flow

• Good for fine grain control, e.g. campus networks

Aggregated

• One flow entry covers large groups of flows• Wildcard flow entries• Flow table contains one entry per category of flows

•Good for large number of flows, e.g. backbone

25

Reactive vs. Proactive (pre-populated)Both models are possible with OpenFlow

Reactive

• First packet of flow triggers controller to insert flow entries

• Efficient use of flow table• Every flow incurs small

additional flow setup time• If control connection lost,

switch has limited utility

Proactive

• Controller pre-populates flow table in switch• Zero additional flow setup time• Loss of control connection does not disrupt traffic• Essentially requires aggregated (wildcard) rules

26

Towards the Software-Defined Network

27

Specialized Packet Forwarding Hardware

App

App

App

Specialized Packet Forwarding Hardware

App

App

App

Specialized Packet Forwarding Hardware

App

App

App

Specialized Packet Forwarding Hardware

App

App

App

Specialized Packet Forwarding Hardware

OperatingSystem

OperatingSystem

OperatingSystem

OperatingSystem

OperatingSystem

App

App

App

Closed

Current Internet

Closed to Innovations in the Infrastructure

Source: N. McKeown et al. http://www.openflow.org

28

Specialized Packet Forwarding Hardware

App

App

App

Specialized Packet Forwarding Hardware

App

App

App

Specialized Packet Forwarding Hardware

App

App

App

Specialized Packet Forwarding Hardware

App

App

App

Specialized Packet Forwarding Hardware

OperatingSystem

OperatingSystem

OperatingSystem

OperatingSystem

OperatingSystem

App

App

App

Network Operating System

App App App

“Software Defined Networking”bring to the networking industry what we did to the computing world

Source: N. McKeown et al. http://www.openflow.org

29

App

Simple Packet Forwarding Hardware

Simple Packet Forwarding Hardware

Simple Packet Forwarding Hardware

App App

Simple Packet Forwarding Hardware

Simple Packet Forwarding Hardware

Network Operating System

1. Open interface to hardware e.g., OpenFlow

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

Extensible, possibly open-source

The “Software-defined Network”

Source: N. McKeown et al. http://www.openflow.org

30

Interlúdio

Nos chegamos no conceito do SDN a partir da disponibilidade de uma interface padrão (i.e., OpenFlow) para conversar com o hardware.- MAS, essa é só uma parte (habilitadora mas

não essencial) de SDN.

Grande problema é a (especialmente nfalta de abstrações em redeso plano de controle)!- Compare com outras ciências (ex:

computação) com fundamentos, principios e abstrações bem definidos (ex: S.O., arquivos, estruturas de dados, linguagens programação)

Vide palestra do Scott Shenker:- https://www.youtube.com/watch?v=WVs7Pc99S7w

32

Layers are Main Network Abstractions

Layers provide nice data plane service abstractions- IP's best effort delivery- TCP's reliable byte-stream

Aside: good abstractions, terrible interfaces- Don’t sufficiently hide implementation details

Main Point: No control plane abstractions- No sophisticated management/control building blocks

Source: Scott Shenker

33

No Abstractions = Increased Complexity

Each control requirement leads to new mechanism- TRILL, LISP, etc.

We are really good at designing mechanisms- So we never tried to make life easier for ourselves- And so networks continue to grow more complex

But this is an unwise course:- Mastering complexity cannot be our only focus- Because it helps in short term, but harms in long term- We must shift our attention from mastering complexity to

extracting simplicity….

Source: Scott Shenker

34

Global Network View

Protocols Protocols

Control Program

Network Operating System

Current NetworksSoftware-Defined Networking (v1)

Control via forwarding interface

35

Major Change in Paradigm

No longer designing distributed control protocols- Now just defining a centralized control function

Control program: Configuration = Function(view)

Why is this an advance?- Much easier to write, verify, maintain, reason about, ….

NOS handles all state dissemination/collection- Abstraction breaks this off as tractable piece- Serves as fundamental building block for control

36

Nypervisor

Abstract Network View

Global Network View

Network Operating System

Moving from SDNv1 to SDNv2

Control Program

38

One Simple Example: Access Control

Full Network View

Abstract NetworkView

39

We need three main abstractions for networking!

Forwarding interface: abstract forwarding model- Shields higher layers from forwarding hardware

Distribution interface: global network view- Shields higher layers from state dissemination/collection

Specification interface: abstract network view- Shields control program from details of physical network

Source: Scott Shenker

40

Software Defined Network (SDN)

Global Network View

Network Virtualization

PacketForwarding

PacketForwarding

PacketForwarding

PacketForwarding

PacketForwarding

Network OS

Abstract Network View

ControlPrograms

41

Software Defined Network (SDN)

Global Network View

Network Virtualization

PacketForwarding

PacketForwarding

PacketForwarding

PacketForwarding

Abstract Network View

ControlPrograms

42

Usage examples

Alice’s code:- Simple learning switch - Per Flow switching- Network access control/firewall- Static “VLANs”- Her own new routing protocol:

unicast, multicast, multipath- Home network manager- Packet processor (in controller)- IPvAlice

– VM migration– Server Load balancing– Mobility manager– Power management– Network monitoring and

visualization– Network debugging– Network slicing

… and much more you can create!

43

OpenFlow Implementations(Switch and Controller)

44

OpenFlow/SDN Timeline

Source: G. Appenzeller (BigSwitch)

45

OpenFlow building blocks

ControllerNOXNOX

SlicingSoftwareFlowVisorFlowVisor

FlowVisorConsole

45

ApplicationsLAVILAVIENVI (GUI)ENVI (GUI) ExpedientExpedientn-Castingn-Casting

NetFPGANetFPGASoftware Ref. SwitchSoftware

Ref. SwitchBroadcom Ref. SwitchBroadcom Ref. Switch

OpenWRTOpenWRT PCEngine WiFi AP

PCEngine WiFi AP

Commercial Switches Stanford Provided

OpenFlowSwitches

SNACSNAC

Stanford Provided

Monitoring/debugging toolsoflopsoflopsoftraceoftrace openseeropenseer

OpenVSwitchOpenVSwitch

HP, NEC, Pronto, Juniper.. and many

more

HP, NEC, Pronto, Juniper.. and many

more

BeaconBeacon HeliosHelios MaestroMaestro

46

Ciena Coredirector

NEC IP8800UNIVERGE PF5240

Current OpenFlow hardware

More coming soon...

Juniper MX-series

HP Procurve 5400

Pronto 3240/3290

WiMax (NEC)

PC EnginesNetgear 7324

47

Growing CommunityVendors and start-ups Providers and business-unit

More... More...

Note: Level of interest variesNote: Level of interest varies

48

Industry commitment

Big players forming the Open Networking Foundation (ONF) to promote a

new approach to networking called Software-Defined Networking (SDN).

http://www.opennetworkingfoundation.org/ http://www.opennetworkingfoundation.org/

49

Application scenarios and examples

50

Cenarios de Aplicação

redes corporativas: novos mecanismos de controle de acesso e segurança, gerência integrada de rede cabeada e sem fio, configuração de VLANs, suporte à mobilidade, etc. (CASADO et al., 2007);backbone: convergência de redes de pacotes e circuitos, como, por exemplo, agregação e gerência dinâmica e flexível do tráfego, novos mecanismos de roteamento e engenharia de tráfego e recuperação de falhas; balanceamento do tráfego Web; Common control plane for “Layer 3” and “Layer 1” networks; etc. (GUDLA et al., 2010);redes celulares: uso transparente (bi/tri-casting) de diversas redes de acesso (Wi-Fi/3G/WiMAX), separação do provedor de infraestrutura do provedor de serviços (por exemplo, virtual network operators), etc. (YAP et al., 2010)data center: técnicas de conservação de energia, engenharia de tráfego, roteamento plano e multicaminho, suporte à virtualização de hosts e software switches, automação da gerencia da infraestutura de rede (switches fisicos e virtuais) e integrada com sistemas de TI e OSS/BSS (KOPONEN et al., 2010);redes domésticas: terceirização (outsourcing) da gerência de rede, compartilhamento da rede com vários provedores de serviços e usuários, como, por exemplo, Open Wi-Fi, e gerência de energia com medidores inteligentes, como smart grid;

52

Projeto

RouteFlow is an open-source project to provide IP routing & forwarding services in OpenFlow networks

CPqD UniRio Unicamp Indiana University

Marcelo Nascimento Carlos Corrêa Mauricio Magalhães Stanford University

Christian E. Rothenberg Sidney Lucena UFSCAR

Marcos Salvador UFPA

Eder Leao Fernandes ...

Rodrigo Denicol

Alisson Soares

Tomas Benedotti

CPqD UniRio Unicamp Indiana University

Marcelo Nascimento Carlos Corrêa Mauricio Magalhães Stanford University

Christian E. Rothenberg Sidney Lucena UFSCAR

Marcos Salvador UFPA

Eder Leao Fernandes ...

Rodrigo Denicol

Alisson Soares

Tomas Benedotti

53

Lógica de ControleRIP BGP OSPF ISIS

Sistema OperacionalDriver

Hardware Dedicado

Sistema Operacional API

OpenFlow

Switch Programáv

el

Servidor

de

Controle

54

High costSpecialized config.

Closed source

Slow innovation pace

BGP

Low cost (commodity)

Multi-vendor

Open source

Fast innovation pace

Controller

Open interface

OpenFlow Switch

Open interface

Software Defined IP RoutingOSPF ISIS LDP

Specialized Control Plane

Specialized Hardware

Specialized Features

55

Design

What's new?

Database layerJSON-based IPC

Core state

Programmer-friendly

Multi-Controller supportNOX

POX

Floodlight (ongoing)

Resillience, component names, debugging, user-control, GUI, etc.

56

57

Demos @ ONS 2011, 2012, SC´11

Pronto 3240/3290

Indiana University

+ Commercial switches from IBM, NEC, Pronto

58

Compare interfaces over the last 30 years

Source: Chris Small (Indiana)

59

RouteFlow User Interface

How to make network administration:Simpler to implement

More robust and consistent

Easier to manage

Automation and Abstraction

Can you build very different interfaces with SDN backends?E.g., type: http://netkarma.testlab.grnoc.iu.edu/rf/ or... http://goo.gl/T3Tqe

Source: Chris Small (Indiana)

62

http://go.cpqd.com.br/routeflow/

Visits: 12,000+ (5,000+ Unique)

From over 1,100 cities of 90+ countries all over the globe!

365days since

Project Launch

… building a community

63

Colaborações e desenvolvimentos comunitarios

Web-based UI & Internet 2 HW pilot [C. Small, Indiana]

Aggregated BGP Routing Service [C. Corrêa, Unirio]

SNMP plugin [J. Stringer, Google]

Optimal BGP best path reflection [R. Raszuk, NTT-MCL]

OpenFlow v1.1 and v1.2 [w/ Ericsson]

Open Label Switched Router [OSRF; Google]

Multi-path, Fast-ReRoute, BGP-Sec, IPv6, ... [YOU?]

✔✔✔

◷◶◵

?

64

Atividades em OpenFlow/SDN

RouteFlow+Low-cost routing, migration to IPv6, BGP Security extensions

Software-based OpenFlow switch v1.2 and v1.3Collaboration with Ericsson to release open-source software switch

Based on previously IPv6 extended v1.1 reference switch design

OpenFlow-enabled ROADMPilot experiment for the EU/Brazil FIBRE Project

Networking for the CloudIntegration of OpenFlow w/ OpenStack and transport networks

65

Conclusões

“Software Defined Networking”bring to the networking industry what we did to the computing world

66

… perguntas?

Obrigado!

Learn more!http://go.cpqd.com.br/routeflow

67

DEMO VIDEO

http://www.youtube.com/watch?v=YduxuBTyjEw

Obrigado!

Perguntas?

Christian Esteve Rothenberg, Ph.D. Diretoria de Redes Convergentes (DRC)

esteve@cpqd.com.br

69

BACKUP

70

NetFPGA testbed evaluation

NOX OpenFlow-Controller

RF-Server

5 x NetFPGA “Routers”

71

NetFPGA testbed results

72

What can you not do with OpenFlow ver1.0

Non-flow-based (per-packet) networking- ex. Per-packet next-hop selection (in wireless mesh)- yes, this is a fundamental limitation- BUT OpenFlow can provide the plumbing to connect these systems

Use all tables on switch chips- yes, a major limitation (cross-product issue)- BUT an upcoming OF version will expose these

New forwarding primitives- BUT provides a nice way to integrate them through extensions

New packet formats/field definitions - BUT a generalized OpenFlow (2.0) is on the horizon

Optical Circuits- BUT efforts underway to apply OpenFlow model to circuits

Low-setup-time individual flows- BUT can push down flows proactively to avoid delays

73

Where it’s going

OF v1.1: Extensions for WAN- multiple tables: leverage additional tables

Better flow table usage ( n routes * m policies == too many flow_mods)

- tunnels and tags (e.g., MPLS)- multipath forwarding- fast failover (faster than controller latency)- support for new match types

OF v2+- generalized matching and actions: an “instruction set” for networking

74

Virtualizing OpenFlow

75

Windows(OS)

Windows(OS)

LinuxMacOS

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

76

Simple Packet Forwarding Hardware

Network Operating System 1

Open interface to hardware

Virtualization or “Slicing” Layer

Network Operating System 2

Network Operating System 3

Network Operating System 4

App App App App App App App App

Many operating systems, orMany versions

Open interface to hardware

Isolated “slices”

Simple Packet Forwarding Hardware

Simple Packet Forwarding Hardware

Simple Packet Forwarding Hardware

Simple Packet Forwarding Hardware

77

Switch Based VirtualizationExists for NEC, HP switches but not flexible enough

Normal L2/L3 Processing

Flow Table

Production VLANs

Research VLAN 1

Controller

Research VLAN 2

Flow Table

Controller

78

Slicing traffic

All network traffic

Researchtraffic

Experiment #1

Experiment #2

…

Experiment N

79

FlowVisor-based Virtualization

OpenFlow Switch

OpenFlowProtocolOpenFlowProtocol

OpenFlow FlowVisor & Policy Control

Craig’sController

Heidi’sControllerAaron’s

Controller

OpenFlowProtocolOpenFlowProtocol

OpenFlow Switch

OpenFlow Switch

Topology discovery is

per slice

Topology discovery is

per slice

80

FlowSpace: Maps Packets to Slices

81

82

More Detailed Model

L2 L3 ACLPacket In Packet Out

Service model can generally be described by a table pipeline

83

Implementing Specification Abstraction

L2L2 L3L3 ACLACL

Network Hypervisor (Nypervisor)

Compiles abstract pipeline into physical configuration

Given: Abstract Table Pipeline

Need: pipeline operations distributed over network of physical switches

84

Two Examples

Scale-out router:- Abstract view is single router- Physical network is collection of interconnected switches- Nypervisor allows routers to “scale out, not up”

Multi-tenant networks:- Each tenant has control over their “private” network- Nypervisor compiles all of these individual control requests into a single

physical configuration- “Network Virtualization”

85

Three Basic Network Interfaces

Forwarding interface: abstract forwarding model- Shields higher layers from forwarding hardware

Distribution interface: global network view- Shields higher layers from state dissemination/collection

Specification interface: abstract network view- Shields control program from details of physical network

86

Abstractions Must Separate 3 Problems

Constrained forwarding model

Distributed state

Detailed configuration