sdn for cloud architecture - an introduction (part 1)

Cloud, SDN & OpenFlowPart 1: SDN Concepts and Openflow

Steven Eychenne, IBM

SoftLayer Sales Engineer

Yves Eychenne, IBM

Cloud Advisor, Europe

Click to edit section name

Agenda

Introduction

Software-Defined Datacenter

Policy-based networking and configuration management

Software-Defined Networking

Software-Defined Networking concepts

OpenFlow

Software-Defined Networking controller

SDN Applications

Revisiting traditional IP services with Software Defined-Networking

Overlay networks

Hardware

Network hardware acceleration for servers

Programmable data plane

Conclusion

Software-Defined Data Center 2


« Software-Defined Data Center » is a key element to allow IT

transformation to an industrialized self-service.

Software-Defined Data Center


« Software-Defined Data Center » allow to reduce provisioning time of an

infrastructure to less than a few hours.


Legacy Data Center

Disruptive by standardization, consolidation, virtualization, automatization and pre-empt provisioning

4 weeks: provisioning time of a virtual machine

after validation process

4 months: provisioning time of a physical

machine after validation process

Compute, Storage, Network

Infrastructure by application

Manual operations


15 minutes: provisioning time of a virtual

machine after validation process

4 hours: provisioning time of a physical machine

after validation process

Software-Defined Compute, Software-Defined

Storage, Software-Defined Networking

Shared infrastructure

Automated operations


« Software-Defined Data Center » relies on « Software-Defined »

resources.


Software-Defined

Compute


(alias Software-Defined Environment)

Compute where the underlying

compute hardware has been

abstracted

Main hypervisors

VMWare ESX

KVM

Microsoft Hyper-V

Citrix XenApp

IBM PowerVM

Software-Defined

Storage

Software-Defined

Networking

Storage built with common

compute hardware and a

storage software

Definition 1: Network where creation,

deletion and management are

automatized and based on rules

Definition 2: Network built on top of a

underlying hardware network

on compute node


Agenda

Introduction





OpenFlow


SDN Applications


Overlay networks

Hardware



Conclusion

Policy-based networking and network management system 6


What looks like a data center network ?



Elements of a data center network


Hypervisor(VMWare ESX, Citrix Xen,

Microsoft Hyper-V, Linux KVM)

Virtual Switch(VMWare vSwitch, Cisco 1000V, Open vSwitch, IBM DVS-5000V)

Blade Switch

(IBM ESM, Cisco CSM)

IBM Bladecenter

Top-of-Rack Switch

(Juniper EX 4200, Cisco Nexus 5000)

Firewall(Juniper SRX,

Fortigate 300C,Palo Alto)

Core Switch(Cisco Nexus 7000)

Internet

Load Balancing(F5 Big IP)

IPS(Fortigate 300C)

10:1 - 15:1Virtual machine

consolidation

10xData Growth

Every 5 Years(Source: IDC)

10 GBNew NIC

capacity

1 data center

1 000 servers

100k new flows per second

(Source: Technology Strategy Brief,

Software Defined Networking (SDN)

in the Enterprise, Enterasys)

Network is complex to configure manually. It takes time. It is hard to reconfigure often.


First networking programmability models

1/ Configuration on each network devices

WHAT

Defining VLAN (name, VLAN/Port association)

IP on interface

Static routes

Routing protocols (BGP, ISIP, OSPF, OSPF-TE)

HOW

Command Line Interface

Web HMI

2/ Centralize network configuration

WHAT

Idem, but for several devices

HOW

Operations Support Systems (OSS)

Network management system (NMS)

Element management system (EMS)

PROTOCOL

Some standard API is only to read values, most configuration API are vendor specific

CLI over TELNET or SSH

SNMP (Simple Network Management Protocol)

NETCONF (Network Configuration Protocol) / YANG

Policy-based networking and network management 9

CLI1

Control Plane

Data Plane

CLI, Web HMI

Programmable APIs2

Control Plane

Data Plane

Applications

SNMP, …

Application, like Network Management System (NMS),

helps operators to centralize network configuration.


First networking programmability models: SNMP

Policy-based networking and network management system

SNMP: Simple Network Management Protocol

Protocol to manage externally devices’ configurations and statistics

Two mechanisms: requests/responses or event notification (alias trap)

SNMP Actions

GetRequest and GetNextRequest

A manager request an agent to read information concerning an object

SetRequest,

A manager request an agent to update information concerning an object

GetResponse

An agent send information in response to a manager request (GetRequest, GetNextRequest, SetRequest)

Trap,

An agent notify a manager that a condition is locally detected.

Object and Management Information Base (MIB II et RMON)

Objects are codified in a tree structure called MIB

Object examples

1.3.6.1.4.1.9.9.156.1.2.1.1.20 – Device Name

1.3.6.1.4.1.9.9.156.1.2.1.1.21 – Device IP

SNMP standard MIB is mainly to read values, most read/write MIB values are vendor specifics.

It results that SNMP was mainly used for monitoring network devices and few used for configuration.


First networking programmability models: NETCONF/YANG


http://fr.slideshare.net/tailfsystems/netconf-yang-tutorial


New systems allow to define rules for a generic templates instead of

defining rules for each applications


http://fr.slideshare.net/nuage-networks/policy-driven-networking-and-migration-to-openstack-by-scott-sneddon-of-nuage-networks


Several tools for policy-based networking and network

management system are ready to be used.


Cisco ACI Juniper Contrail

Open DayLight Centec

Nuage Networks

Roadmap priority is to be integrated with OpenStack and VMWare


Agenda

Introduction





OpenFlow


SDN Applications


Overlay networks

Hardware



Conclusion

Software-Defined Networking concepts 15


History: “Demoiselles du téléphone”, how to get “Le 22 à Asnières” ?


“With manual service, the customer lifts the receiver off-hook and asks the

operator to connect the call to a requested number. Provided that the number

is in the same central office, and located on the operator's switchboard, the

operator connects the call by plugging the ringing cord into the jack on the

switchboard corresponding to the called customer's line.” – Wikipedia

http://en.wikipedia.org/wiki/Telephone_exchange#Manual_service_exchanges


Definition of data plane and control plane


Image from RES343

A forwarding function directs

every packet from an input port

to the right output port, based

on the header of the packet and

the routing table (RT).

A routing function exchanges

reachability and topological

information, computes the best

route to any destination and

populate the routing table

accordingly.

Forwarding functions of all devices lay on forwarding plane

(alias data plane).

Routing functions of all devices lay on control plane.

EthernetIP

MPLSMPLS

BGP

OSPF

OSPF-TE

ARP


Stanford University definition of « Software-Defined Networking »

(definition 3)


Ethernet IP

MPLS

MPLSEthernet IP

MPLS

MPLS

BGP

OSPF

OSPF-TE

ARP

Standard x86

servers

Intelligence logically

centralized

A network in which the control plane ( )

is physically separated from the forwarding

plane ( )

A single control plane controls several

forwarding devices.


« Software-Defined Networking » (definition 3) simplify the development

of new network feature with a system approach.


Legacy Network

Each network device comes with:

A specialized hardware (e.g.. ASIC)

An operating system (e.g.. IOS, JunOS)

Applications (ex. BGP, OSPF, OSPF-TE)

New application

Should be developed for each operating system

by each vendor

Required to be standardized

Could require an hardware update

Software-Defined Network

Each network device comes with:

A specialized hardware (e.g.. ASIC)

A « control agent »

A controller manages several network devices

though their « Southbound API »

An application is developed only once on a

« Northbound API », could be done by a third-

party

Control Agent

Control Agent

Specialized Packet Forwarding Hardware

App App App


App App App

OperatingSystem

OperatingSystem


App App App

Control Agent

OperatingSystem

Control Agent

Control Agent


Controller



App App App App App

Control Agent

Northbound APIs

Southbound APIs


Control Agent

Control Agent


Controller

Virtualization or slicing layer




App App App App

Control Agent

Southbound APIs

ControllerSouthbound APIs

Virtualization or Slicing SoftwareSouthbound APIs

Southbound APIs

Multiple controllers can communicate with the same pool of SDN switches.

SDN architecture includes a virtualization or slicing layer To run several controllers on the

same pool of switches

Controllers communicate to the virtualization or slicing layer with one of his southbound API

The virtualization or slicing layer consolidates requests from different controllers and sends the request to the pool of switches

Why ? Multi-tenancy of a hardware

network

Application isolation

Solve application dependencies with several operating systems and versions


Software Defined Network is a business model revolution for the

network industry


Open ModelIntegrated Model

Independent network switches

• Switches oblivious to application requirements

• “One size fits all” configurations and policies

• Poor utilization of available resources

• Vendor-proprietary extensions lock-in

SDN Controller programs switches

• Re-configures network to match application

requirements and global resource conditions

• Exports SDN API to applications that extend

network capabilities or enhance performance

• Enables innovation in a static, closed market

Computer

Industry

Network

Industry

Controller

Slicing Software

App

Switch Switch Switch

Controller

App App App

OS

Switch

App App

OS

Switch

App App

OS

Virtualization or Slicing Software

App

Hardware Hardware Hardware

OS

App App App

OS

Hardware

App App

OS

Hardware

App App

IBM

Cisco Juniper

HP

Microsoft Red Hat

Microsoft

VMWare

HP IBM

IBM

IBM

Juniper NEC

Stanford

Juniper

IBM

IBM

Software Defined Network allows the network industry to follow the computer industry

toward an open model with more actors and more innovations


Goals of SDN

Simplifying operational network configuration Moving the industry away from Command Line Interface (CLI)

Standardizing device configuration interfaces

Customizing network policy, topology and feature state with rich network applications

Controlling coherently multiple network layers Manage state across several layers: optical, transport, trunks,

virtual networks, services…

Not possible at any single node

Enabling reactive programming of the network Enables feedback loop

Enabling global reaction to events in different subsystems Ex: identity, routing, policy, state of the topology

Solving hardware issues Convergence time with small processor in network device

Enabling innovation Faster deployment of compute, storage, services

New services not possible with existing technology/protocols


Classic SDN5

Data Plane

Controller

Applications

OpenFlow

SDN improves the programmability of the network as a whole.


First Software-Defined Networking system

BGP route reflectors

Description

A route-reflector acts as a filter and reflector

for all other routers in its cluster.

It reduces the number of routes to be process

by each routers

Route selection is done with a centralized view

Use by carriers for:

Reducing the number of connections between

BGP routers of an Autonomous System (AS)

Improve convergence time


BGP could be a Southbound API for Software-Defined Networking.

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.94.8393&rep=rep1&type=pdf

Why can we consider this system has a

Software-Defined Networking ?

Most of the control plane (BGP filtering,

BGP announcements) is done by the route-

reflector.

It is physically separated from the

forwarding plane (IP forwarding) done by

other routers.

iBGP is used as a Southbound API


Agenda

Introduction





OpenFlow


SDN Applications


Overlay networks

Hardware



Conclusion

OpenFlow 24


OpenFlow is the idiomatic« Southbound API » for « Software-Defined

Networking » (definition 3).

OpenFlow

Control Agent


ControllerSouthbound APIs

Control Agent


Southbound API

Send « Match-Action »

instructions to network

devices

Get packets from network

devices to controller for

analysis

E.g. First flow packet (in

certain SDN configuration)

Get network statistics from

network devices

By flow, by ports…

Match-Action Tuple (n-uplet)

Match

Find a match between

header elements of a packet

and an rule entry in the

« Match-Action » table (alias

forwarding information base)

of a network equipment

Action

Modify packet header

Forward packet on one or

multiple ports

Delete packet

Jump to instruction X

All network header elements

form Layer 2 à Layer 4 is

considered like a unique n-

uplet (like ACL)

L2 (Ethernet, MPLS)

L3 (IPv4, IPv6, MPLS)

L4 (TCP, UDP)

A « match » could be realized

on any subset of headers

elements.

Slice 1 & 2 : MAC & IP

Slice 3 : TCP port


Open Networking Foundation

Open Networking Foundation (ONF) is a user-driven organization dedicated to the promotion and adoption of Software-Defined Networking (SDN) through open standards development.

Their signature accomplishment to date has been the introduction of the OpenFlow™ Standard, which enables remote programming of the forwarding plane.

The OpenFlow Standard is the first SDN standard and a vital element of an open software-defined network architecture.

Over 90 companies are members of the Open Networking Foundation.

OpenFlow 26

ONF is a user-driven organization which defines the OpenFlow standard


Flow Table Entries

OpenFlow 27

Match Fields Counters Instructions


Flow Table Entries

OpenFlow 28

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

A. Per Table1. Reference count (active entries)2. Packet Lookups3. Packet Matches

B. Per Flow1. Received Packets2. Received Bytes3. Duration (seconds)4. Duration (nanoseconds)

C. Per Port1. Received Packets2. Transmitted Packets3. Received Bytes4. Transmitted Bytes5. Received Drops6. Transmitted Drops7. Received Errors8. Transmitted Errors9. Receive Frame Alignment Errors10. Receive Overrun Errors11. Receive CRC Errors12. Collisions

D. Per Queue1. Transmitted Packets2. Transmitted Bytes3. Transmit Overrun Errors

E. Per Group1. Reference Count (flow entries)2. Packet Count3. Byte Count

F. Per Bucket1. Packet Count2. Byte Count


1. Ingress Port2. Metadata3. Ethernet source address4. Ethernet destination address5. Ether type6. VLAN id7. VLAN priority8. MPLS label9. MPLS traffic class10. IPv4 source address11. IPv4 destination address12. IPv4 protocol / ARP opcode13. IPv4 ToS bits14. TCP / UDP / SCTP src port15. ICMP Type16. TCP / UDP / SCTP dst port17. ICMP Code


Fields in OpenFlow Specification

OpenFlow 29



Flow representation

All fields enumerated in the previous slide and all fields that will be added to the OpenFlow specification should be considered as a n-tuple.

Matching can be done on any group of fields regardless of network layers.

OpenFlow 30

MAC Src MAC Dst IP Src IP Dst TCP Src port TCP Dst port

Slice 1 * 00:1c:.. * 10.10.10.0/24 * *

Slice 2 * 00:1f:.., 00:1a:.. * 8.0.0.0/8 * *

Slice 3 * * * * * 22



Flow Table Exercise

OpenFlow 31

Controller

OpenFlow Client

port 1

10.10.10.2

00:1B:44:11:3A:B7

Switching

Flow Switching

Routing


Software Layer

Hardware Layer

port 2

192.168.1.2

00:1B:44:11:3A:B7

port 3

10.10.10.3

00:1C:55:22:4B:C3

192.168.1.3

00:1A:77:44:5D:B2

10.10.10.4

00:1D:66:33:4C:A1

port 4VLAN 2VLAN 1 VLAN 1VLAN

1 & 2

Flow Table

Port MAC src MAC dst VLAN id IP src IP dst TCP src TCP dst Action

* * 00:1C:55:… * * * * * Port 3

VLANSwitching * * 00:1B:44:… 2 * * * * Port 2

* * * * * 10,10,10,2 * * Port 1

4 00:1D:66:… 00:1B:44:… 1 10,10,10,4 10,10,10,2 17264 80 Port 1


Instructions

OpenFlow 32



Pipeline processing

OpenFlow 33

Match Fields

Counters

Instructions

Match Fields

Counters

Instructions

Table 0 Table 1



Instructions

OpenFlow 34



Action Set

OpenFlow 35



Actions

OpenFlow 36



Counters

OpenFlow 37



Why do we need a new network configuration protocol?

Why do we need a new network configuration protocol? We already have

CLI (Command Line Interface)

SNMP (Simple Network Management Protocol)

RADIUS (Remote Authentification Dial in User Service)

NETCONF (Network Configuration Protocol)

XMPP (Extensible Messaging and Presence Protocol)

OpenFlow 38

OpenFlow allows the unification of L2 to L4 control and management

Ethernet, VLAN, MPLS, IP, TCP and UDP have dedicated protocols and

configuration in the control plane

IT administrators make complex ACL in each device using n-tuples with a

mix of attributes from all layers

OpenFlow allows the coherent and dynamic management of L2 to L4 layers

OpenFlow allows the unification of Packet and Circuit Switched Networks

control and management

Stanford University, Saurav Das, Guru Parulkar, Nick McKeown,

OPENFLOW-TR-2009-4

OpenFlow can be used to propose a simple way to unify the control and

management of circuit and packet switched networks. The basic idea is that a

simple flow abstraction fits well with both types of networks, provides a

common paradigm for control, and makes it easy to insert new functionality

into the network.

OpenFlow allows the coherent and dynamic management of IP and

Transport networks

OpenFlow standard permits defining a control plan coherent with the whole network

Tra

nsp

ort

Netw

ork

(TD

M, W

DM

, GM

PLS

)

IP/M

PL

S N

etw

ork


Unifying control plane of packet and circuit networks with OpenFlow

OpenFlow 39

Adding new fields to OpenFlow standard allows the definition of

a control plan unifying packet and circuit networks

Control Agent Control Agent

Circuit Switch Fabric

GE ports TDM ports

Packet Switch Fabric

Packet Switch Fabric

VCG5

VCG3

+ VLAN7, P2IP 11.12.0.0

VLAN 1025 + VLAN2, P2

P1

P2

VLAN2 VCG 3

VLAN7 VCG5 VCG5 { P3, STS192, 1}

VCG3{P1, VC4, 1},{P1, VC4, 2},{P2, VC4, 4}

TCP 80 +VLAN2, P1

PortMAC src

MAC dst

VLAN id

IP src IP dstTCP src

TCP dst

Action Port Lambda VCGSignal Type

StartingTime-Slot

Action


Agenda

Introduction





OpenFlow


SDN Applications


Overlay networks

Hardware



Conclusion

Software-Defined Networking controller 40


SDN deployment models


OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

Controller

Distributed Control

OpenFlow Switch

OpenFlow Switch

OpenFlow Switch

Controller

Controller

Controller

Centralized Control

One controller for all switches One controller per switch

OpenFlow enables both paradigms.

Nevertheless, SDN is more about centralizing

the control plane.

Centralization does not mean one node.

A centralized controller can be “distributed” on

several nodes.

A federation of controllers can be used to

manage the control plane of a network.

Each controller manages a sub-set of a network

Networks can be partitioned according to

centralization benefit, scalability capability,

availability and risk management

One paradigm, multiple deployment models.


SDN deployment models


Flow-Based

One flow entry per flow

Each flow entry is an exact-match of the flow

For fine grain control

For campus networks

Aggregated

One flow entry by group or large group of flows

Each flow entry uses wildcards to match flows

For handling large number of flows

For core networks

Reactive

Flow entry is inserted when the first packet of a

flow triggers the controller

Latencies to set up the flow

Immediate network adaptation to the new flow

Loss of control connection disrupts traffic

Proactive

Flow entries are pre-populated by the controller

based on previous events and traffic estimation

No latencies for set up

Slow or no network adaptation to the new flow

Loss of control connection does not disrupt

traffic

One paradigm, multiple deployment models.


Southbound APIsOpenFlow (OF 1.0, OF 1.3) Vendor-specific interfaces (onePK)

Base Network Services

Topology

Management

Statistics

Management

Device

Management

Forwarding

Logic

Flow

Management

Link

Discovery

Connection

Handler

Event Engine

ExtensionL4-L7 Services

Controller Built-In Applications

Network Slicing Network Troubleshooting GUI / CLI

Service Abstraction Layer & Inter-Controller Bus

Capability AbstractionsPlug-In Management

Storage Services

Label DB

TE tunnel DB

Packet-Flow

DB

Virtual Network

DOVE

Management

VXLAN

Management

NVGRE

Management

Northbound API (REST, WebSockets, OSGi)

REST WebSockets OSGi

Controller Overview


Data Center Orchestrators

OpenStack

NeutronCloudStack oVirt

Co

ntr

oller

Pla

tfo

rm

Physical & Virtual

Network Devices

Applications for Core Networks

Load SharingDynamic Optical

BypassUnified Recovery

Traffic

Engineering

Applications


Code samples on POX controllers

Define a flow table entry

Initialize a flow entry

fm = of.ofp_flow_mod()

Define a match rule

fm.match.in_port = in_port

fm.match.dl_dst = dst_addr

Define actions

fm.actions.append(of.ofp_action_output(port = out_port)

Define when to drop the flow entry

fm.idle_timeout = 10

fm.hard_timeout = 30

Send the flow rule to the switch

self.connection.send(fm)


http://www.cloudcomp.ch/2012/10/openflow-setting-up-a-learning-switch/

https://openflow.stanford.edu/display/ONL/POX+Wiki#POXWiki-ofp_packet_out-Sendingpacketsfromtheswitch


https://openflow.stanford.edu/display/ONL/POX+Wiki


Code samples on POX



http://archive.openflow.org/wk/index.php/OpenFlow_Tutorial



Code samples on POX






Agenda

Introduction





OpenFlow


SDN Applications


Overlay networks

Hardware



Conclusion

Revisiting traditional IP services with Software Defined-Networking 47


« Software-Defined Networking » allows to add new features to the

network by adding applications to the controllers.


All-Software Load balancer

Load balancing without a

dedicated network appliance

A load balancing virtual machine

(LB VM) is in charge to select a

Dynamic IP (DIP) in a server pool

for each new client contacting a

Virtual IP (VIP).

The LB application makes the

SDN controller pushes

dynamically configuration in the

virtual switches and LB VM.

Application-aware flow control DNS protection

Intrusion Prevention System (IPS)

without a dedicated network

appliance on all flows.

A new flow is forwarded through

an IPS. When the flow is identified,

the IPS application in the

controller set up the switches to

drop or to route the flow directly

to the destination with the

proper Quality of Service (QoS).

DNS Interception

The DNS Director application

drives the SDN controller to

configure switches to forward

DNS requests to DNS analyzer

servers.

DNS analyzer servers is in charge

to send a response to the client

depending on his security policy.


Inter Autonomous System Exchanges


http://fr.slideshare.net/umeshkrishnaswamy/sdnip-peering-using-bgp

Autonomous Systems (AS) exchange routing and

reachability information

At border routers using BGP

By router to router exchanges

With trust controls to peers

Route announcements from peers are filtered

Route announcements to peers are filtered also

Google Project Cardigan is a prototype to have a

“BGP”/”SDN-IP” application on a SDN network

Border SDN switches forward BGP messages between

peer routers and the central “BGP Daemon”.

The “BGP Daemon”

Handles BGP messages

Handles BGP filtering mechanisms

Manages the Routing Information Base (RIB) synchronized

with the Network Operating System (NOS)



Security Functions – 1/2


Protocol-conformance verification of flows

Principles

Check conformity to network protocols

No Ping of Death

No Land Attack

No SYN flood attack

Hardware evolution

Step 1: Dedicated firewall hardware

Step 2: Firewall in virtual machine

VMWare vShield Edge

Juniper Firefly

Step 3: Firewall in virtualized switch

VMWare NSX

http://icsa.cs.up.ac.za/issa/2004/Proceedings/Full/080.pdf

http://www.vmware.com/files/pdf/products/vShield/VMware-vShield5-Edge-Datasheet.pdf

http://www.vmware.com/files/pdf/techpaper/vShield-Edge-Design-Guide-WP.pdf

Flow filtering

Principles

Drop packets based on rules on TCP/UDP ports

Hardware evolution


Step 2: Integrated to router

Step 3: Integrated to L3 switch

Step 4: Virtualized firewall

Step 5: Integrated to SDN switch





Revisiting traditional IP services within SDN

Security Functions – 2/2


Network Address Translation (NAT)

Principles

Allows multiple users to connect to a public network

using the same IP address by

Modifying network fields of a flow

Keeping track of mapping

Hardware evolution



Step 3: Integrated to SDN switch

Virtual Private Network (VPN)

Principles

Extends a private network across a public network

(Optional) Ensures confidentiality of the data

Hardware evolution


Step 2: MPLS/L2TPv3/GRE routers for non secure VPN


Step 4: Integrated to SDN switch for non secure VPN








Agenda

Introduction





OpenFlow


SDN Applications


Overlay networks

Hardware



Conclusion

Overlay networks 52


« Overlay networks » allow to isolate more environments and to decuple

virtual networking from physical constrains

Large capacity to isolate environments for multi-tenancy

Large number of customers could be isolated safely on a same public

cloud infrastructure

Multiple applications of multiple business units of a large group could be

isolated safely on a same private / hybrid / public cloud infrastructure

VLAN are limited to 4096 VLAN where VXLAN, NVGRE and STT are

limited to 16 millions virtual networks

Decuple virtual networking from physical constrains

Avoid physical size limitation for VLAN

Avoid physical size limitation for MAC addresses table

Allow to move a virtual machine with his network attached from a

datacenter to an other, for resource allocation or disaster recovery

purposes

Could be done for virtual machines without changing the current L2/L3

physical network

Overlay networks


Encapsulation (L2 sur L3) des flux

Available protocols

VXLAN (UDP)

NVGRE (GRE)

STT (TCP)

MPLS

Point of encapsulation of virtual

networks

Available gateways

Primarily on virtual switches (ex.

OVS, Cisco 1000V)

Virtual machine gateway (ex. VMWare

NSX Edge)

Physical switches (ex. ALU, Cisco)

Intelligence centralized in a SDN

controller

Replace full mesh BGP system in

carrier overlay networks

Simplify updates of routing tables

and configuration of encapsulation

gateways

Rely on OpenFlow and OVSDB

« Software-Defined Networking » is only one component of « Overlay Networks »,

and « Overlay Networks » is only one use case of « Software-Defined Networking ».

Overlay networks

P1 SDN Controller

+ +

Technology combination: encapsulation, gateway, SDN

G1 G2 Data

P1 P2 Vert G1 G2 Data

G1 G2 Data

Virtual-Physical: Encapsulation at gateway

P1, add tag “Green”

P1 P2 Vert G1 G2 Data

Physique: Transport based on

physical addresses

Virtual-Physical: Decapsulation at

gateway P2

Virtual: Transport based on

“Green” virtual addresses

Virtual: Transport based on “Green”

virtual addresses

Physical Network

P1 P2 P3

Green

Virtual Network

G1 G2 G3

Red

Virtual Network

R1 R2 R3

V

P

V1

P

V2

VP1

VP2

G1 R1 R2 R3

G2 G3

P1 P2

P3

V1

P

V2

VP1

VP2

SDN Controller

Physical View Packet ViewLogical View


VXLAN, NVGRE and STT

Overlay networks 55

VXLAN NVGRE STT

Support VMWare, Cisco, IBM Microsoft, HP, Intel, Dell Nicira (VMWare)

Encapsulation technique UDP + VXLAN ID GRE TCP + STT

Outer

L2

Outer

L3

Enc.

Tech.

VM

L2

VM

L3

VM

L4

VM

Data

VM

L2

VM

L3

VM

L4

VM

Data

Enc.

Tech.

VM

L2

VM

L3

VM

L4

VM

Data

Outer

L2

Outer

L3

Enc.

Tech.

VM

L2

VM

L3

VM

L4

VM

Data

Outer

L2

Outer

L3

Enc.

Tech.

VM

L2

VM

L3

VM

L4

VM

Data

Outer

L2

Outer

L3

Enc.

Tech.

VM

L2

VM

L3

VM

L4

VM

Data

Outer

L2

Outer

L3

Enc.

Tech.

VM

L2

VM

L3

VM

L4

VM

Data

VM

L2

VM

L3

VM

L4

VM

Data

Enc.

Tech.

VM

L2

VM

L3

VM

L4

VM

Data

Outer

L2

Outer

L3

Enc.

Tech.

VM

L2

VM

L3

VM

L4

VM

Data

Virtual Overlay Network can be built on top of legacy network equipment.


« Overlay networks » market is becoming mature with multiples actors

(solution provider or infrastructure provider).

Overlay networks

VMWare NSX Juniper Contrail

IBM Dove HP

Nuage Networks

Google Andromeda

Windows Azure

VMWare NSX is leading the market.


Agenda

Introduction





OpenFlow


SDN Applications


Overlay networks

Hardware



Conclusion

Network hardware acceleration for servers 57


Challenges of 10 GB link at server level in a virtualized environment


Virtual Machine Host is responsible for

Protecting I/O access

Multiplexing / demultiplexing traffic

Monitoring HW/VM status

Using network HW

Communication between Guest Virtual Machines and Host Virtual Machine

Packets are delivered through shared memory

Netback / Netfront network drivers

Virtual Machine

Hypervisor / VMM

Host Virtual Machine

Virtual Switch

Physical Driver

NIC

Netback Netfront

Shared Memory

Upper Layers

Bottlenecks

for 10 GB

Two main bottlenecks for 10 GB network traffic

Multiplexing / demultiplexing in Host Virtual Machine

Communication between Guest Virtual Machines

and Host Virtual Machine through shared memory


Two main bottlenecks for 10 GB network traffic:

1/ Multiplexing-demultiplexing in Host Virtual Machine


VM Green

Hypervisor / VMM


Virtual Switch

Physical Driver

NIC

Netback Netfront

VM Blue

Netback

Bottleneck

Netfront

Rx Tx

Rx Tx

Rx Tx

Rx Tx

Rx Tx

Rx Tx

Rx Tx

Rx Tx

Rx Tx

VM Green

Hypervisor / VMM


Virtual Switch

Physical Driver

NIC

Netback Netfront

VM Blue

NetbackNetfront

Rx Tx

Rx Tx

Rx Tx

Rx Tx

Rx Tx

Tx

Rx Tx

Rx Tx

Rx Tx

VMDq

Traditional I/O VR Model

Multiplexing / demultiplexing traffic at virtual switch layer

Only one CPU can be used

Lots of I/O waits

Can’t be used for 10 GB traffic

VMDq Model

All CPUs can be used by the virtual switch

Can be used for 10 GB traffic and higher

Multiplexing / demultiplexing traffic at NIC layer with Virtual Machine Device queues (VMDq)

Hypervisor configures the queues of the NIC by using, for instance, Intel DMDQ API

Ex: VMWare NetQueue, Microsoft Virtual Machine Queues


Two main bottlenecks for 10 GB network trafficTwo main bottlenecks for 10 GB network traffic:

2/ Communication through shared memory


Virtual Machine

Hypervisor / VMM


Virtual Switch

Physical Driver

NIC

Netback Netfront

Shared Memory

Upper Layers

Bottleneck

for 10 GB

Direct I/O Assignment (Intel VT-d, AMD-Vi)

Dedicate a PCI peripheral to a virtual machine

Dedicate all the PCI bus to a virtual machine

Use an “Input/Output Memory Management Unit”

(IOMMU) to translate device-visible virtual addresses

to physical addresses in order to have Direct Memory

Access (DMA) independent of the central processing

unit (CPU)

Single Root I/O Virtualization (SR-IOV)

Same concept as Direct I/O Assignment but

with PCI function granularity

Also uses IOMMU for Direct Memory Access

Both Direct I/O Assignment are managed

by the hypervisor

Ex: VMWare DirectPath


Technologies for resolving the main bottlenecks

for 10 GB network traffic


Intel VT-c

Virtual Machine Device queues (VMDq)

Virtual Machine Direct Connect (VMDc)

SR-IOV: VT-d, DMA, IOMMU

Management

Intel DMDQ

VMWare NetQueue & DirectPath

Microsoft Virtual Machine Queues

Important

10 GB support begins to be mandatory in

RFI/RFP on NFV


Agenda

Introduction





OpenFlow


SDN Applications


Overlay networks

Hardware



Conclusion

Programmable data plane 62


Exising approches

Programmable data plane / From Dr Nick Feamster SDN course 63


Today: Hardware constraints

Chips are designed for specific datagrams



Tomorrow: OpenFlow chip

Chips designed for match-action regardless of datagrams format



Agenda

Introduction





OpenFlow


SDN Applications


Overlay networks

Hardware



Conclusion

Conclusion 67


Different definitions depending on actors

Definition 1:

Network where creation, deletion and management are

automatized and based on rules

Definition 2:

Network built on top of a underlying hardware network on

compute node

Definition 3:

A network in which the control plane is physically separated

from the forwarding plane

A single control plane controls several forwarding devices.

Conclusion 68


Network Programmability Models

Software Defined Networking is a network programmability model which tries to extract the control plane out of the network equipment.

Virtual Overlay configures a network (control and data plane) on top of an other network.

Other network programmability models only configure the control plane inside network equipment.

Conclusion 69

CLI1

Control Plane

Data Plane

CLI, Web HMI

Programmable APIs2

Control Plane

Data Plane

Applications

SNMP, …

Classic SDN5

Data Plane

Controller

Applications

OpenFlow

Virtual Overlays3

Virtual Control Plane

Virtual Data Plane

Control Plane

Data Plane

Applications

Overlay

Protocols

Hybrid “SDN”4

Control Plane

Data Plane

Controller

Applications

OpenFlow

SDN improves the programmability of the network as a whole.


Key points

Key SDN features

Control plane and data plane are separated

Controllers centralize views of a network

Programmability of the network by network applications

Allowing to

Control and automate networks with software

Meet specific QoS and security requirements

Define data flows based on network bandwidth, path latency, and

other criteria

Respond quickly and globally to events

Conclusion 70


Thank You

Yves EYCHENNE

Cloud Advisor

[email protected]

Steven EYCHENNE

SoftLayer Sales Engineer

[email protected]


References on VT-c, VT-d, VMDq, VMDc

http://www.cubrid.org/blog/dev-platform/x86-server-

virtualization-technology/

http://windowsitpro.com/virtualization/q-are-vmdq-and-sr-

iov-performing-same-function

http://www.intelethernet-dell.com/intel-virtualization-

technology-for-connectivity/

http://www.intelethernet-dell.com/best-practices-for-

simplifying-your-cloud-network/

http://www.tinkertry.com/cpu-storage-virtualization-

glossary/

72

http://www.cubrid.org/blog/dev-platform/x86-server-virtualization-technology/

http://windowsitpro.com/virtualization/q-are-vmdq-and-sr-iov-performing-same-function

http://www.intelethernet-dell.com/intel-virtualization-technology-for-connectivity/

http://www.intelethernet-dell.com/best-practices-for-simplifying-your-cloud-network/

http://www.tinkertry.com/cpu-storage-virtualization-glossary/


References on virtual overlay network

http://www.ethernetsummit.com/English/Collaterals/Procee

dings/2012/20120222_2-103_Recio.pdf

http://blogs.vmware.com/vsphere/files/2012/09/Networking-

Poster.jpg

http://blogs.cisco.com/tag/virtual-network-overlays/

http://searchsdn.techtarget.com/tip/Virtual-overlay-

networks-Tunneling-protocols-enable-multi-tenancy

http://crankypotato.com/?tag=vmware

http://www.cisco.com/en/US/prod/collateral/switches/ps944

1/ps9902/deployment_guide_c07-703595.html

http://www.my-rezo.fr/les-3-types-d-encapsulation-pour-l-

overlay-networking/73

http://www.ethernetsummit.com/English/Collaterals/Proceedings/2012/20120222_2-103_Recio.pdf

http://blogs.vmware.com/vsphere/files/2012/09/Networking-Poster.jpg

http://blogs.cisco.com/tag/virtual-network-overlays/

http://searchsdn.techtarget.com/tip/Virtual-overlay-networks-Tunneling-protocols-enable-multi-tenancy

http://crankypotato.com/?tag=vmware

http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/deployment_guide_c07-703595.html

http://www.my-rezo.fr/les-3-types-d-encapsulation-pour-l-overlay-networking/


References on OpenFlow

http://www.openflow.org/wk/index.php/OpenFlow_Tutorial

http://www.slideshare.net/openflow/openflow-tutorial

http://openflow.marist.edu/download/TIP2013%20Conferen

ce%20-

%20Software%20Defined%20Networking%20with%20Open

Flow%20-%20final.pdf

http://networkstatic.net/openflow-proactive-vs-reactive-

flows/

http://networkstatic.net/openflow-coarse-vs-fine-flows/

http://networkstatic.net/openflow-sdn-hybrid-deployment-

strategies

74

http://www.openflow.org/wk/index.php/OpenFlow_Tutorial

http://www.slideshare.net/openflow/openflow-tutorial

http://openflow.marist.edu/download/TIP2013 Conference - Software Defined Networking with OpenFlow - final.pdf

http://networkstatic.net/openflow-proactive-vs-reactive-flows/

http://networkstatic.net/openflow-coarse-vs-fine-flows/

http://networkstatic.net/openflow-sdn-hybrid-deployment-strategies


Reference on SDN

Martin Casado, "Origins and Evolution of OpenFlow/SDN", Nicira Networks

PDF Slides: http://www.opennetsummit.org/archives/oct11/casado-tue.pdf

Video: http://www.youtube.com/watch?v=4Cb91JT-Xb4&noredirect=1

Scott Shenker, "The Future of Networking, and the Past of Protocols", ICSI/Berkeley/ONF

PDF Slides: http://www.opennetsummit.org/archives/oct11/shenker-tue.pdf

Video: http://www.youtube.com/watch?v=YHeyuD89n1Y&noredirect=1

Nick McKeown, "How SDN will Shape Networking", Stanford/ONF

PDF Slides: http://opennetsummit.org/talks/mckeown-tue.pdf

Video: http://www.youtube.com/watch?v=c9-K5O_qYgA&noredirect=1

Teemu Koponen et al., “Onix: A distributed control platform for large-scale production networks”, OSDI, Oct,

2010

PDF Papers: https://www.usenix.org/legacy/events/osdi10/tech/full_papers/Koponen.pdf

Video: https://www.usenix.org/conference/osdi10/onix-distributed-control-platform-large-scale-production-networks

75

http://www.opennetsummit.org/archives/oct11/casado-tue.pdf

http://www.youtube.com/watch?v=4Cb91JT-Xb4&noredirect=1

http://www.opennetsummit.org/archives/oct11/shenker-tue.pdf

http://www.youtube.com/watch?v=YHeyuD89n1Y&noredirect=1

http://www.youtube.com/watch?v=c9-K5O_qYgA

http://opennetsummit.org/talks/mckeown-tue.pdf

http://www.youtube.com/watch?v=c9-K5O_qYgA&noredirect=1

https://www.usenix.org/legacy/events/osdi10/tech/full_papers/Koponen.pdf

https://www.usenix.org/conference/osdi10/onix-distributed-control-platform-large-scale-production-networks


References on SDN Controller

http://www.opendaylight.org/project/technical-overview

http://www.bigswitch.com/products/open-sdn

http://www.admin-magazine.com/Articles/Floodlight-Welcome-to-the-World-of-Software-Defined-Networking

https://github.com/noxrepo/nox-classic/wiki/NOX-Components

http://www.noxrepo.org/

http://osrg.github.io/ryu/


https://openflow.stanford.edu/display/ONL/POX+Wiki#POXWiki-ofp_packet_out-Sendingpacketsfromtheswitch


76


http://www.bigswitch.com/products/open-sdn




http://osrg.github.io/ryu/


https://openflow.stanford.edu/display/ONL/POX+Wiki



References on revisiting IP services on SDN

http://fr.slideshare.net/umeshkrishnaswamy/sdnip-

peering-using-bgp


http://www.vmware.com/files/pdf/products/vShield/VM

ware-vShield5-Edge-Datasheet.pdf

http://www.vmware.com/files/pdf/techpaper/vShield-

Edge-Design-Guide-WP.pdf

77

