Software Defined Networks and OpenFlow

BRKRST-2051
Frank Brockners

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

Abstract
Software Defined Networking (SDN) is a new approach to networking,
complementing traditional network architectures. SDN aims at the normalization of
network configuration and control through open programmatic interfaces to
individual network devices as well as to the whole network. SDN incorporates
concepts for network and network topology virtualization, and enables customized
control planes. The latter allows close alignment of the network forwarding logic to
the requirements of applications. OpenFlow is a specification being developed by
the Open Networking Foundation (ONF) that defines a flow-based forwarding
infrastructure and a standardized application programmatic interface (API) that
allows a controller to direct the functions of a switch through a secure channel. This
session supplies an overview of the different concepts present in SDN, discusses
contributing technologies, and reviews OpenFlow as a protocol. The SDN concept
is put into perspective with existing and evolving network architectures and
principles.
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

In the SDN architecture, the control and data planes are

decoupled, network intelligence and state are logically
centralized, and the underlying network infrastructure is
abstracted from the applications
h&ps://www.opennetworking.org/images/stories/downloads/white-papers/wp-sdn-newnorm.pdf

open standard that enables researchers

to run experimental protocols in campus networks. Provides
standard hook for researchers to run experiments, without
exposing internal working of vendor devices
h&p://www.openow.org/wp/learnmore/

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

A way to op8mize link u8liza8on in my network

enhanced, applica8on driven rou8ng

An open solu8on for VM

mobility in the Data-Center
A way to reduce the
CAPEX of my network
and leverage commodity
switches

An open solu8on for customized ow forwarding

control in and between Data Centers

A pla'orm for developing new

control planes

A solu8on to automated network

congura8on and control

A means to get assured

quality of experience for
my cloud service oerings

Develop solu8ons at soTware speeds: I dont want

to work with my network vendor or go through
lengthy standardiza8on.

A solu8on to build a very large scale A means to do

layer-2 network
trac engineering
without MPLS

A solu8on to build virtual

topologies with op8mum mul8cast
forwarding behavior

A means to scale my xed/mobile gateways

and op8mize
A way to op8mize broadcast TV delivery by
their placement
op8mizing cache placement and
cache selec8on
A way to distribute policy/intent, e.g. for
DDoS preven8on, in the network
A way to congure my en8re network as

a whole rather than individual devices

A way to build my own

security/encryp8on solu8on

A way to
scale my
rewalls and
load
balancers

A solu8on to get a global view of the

network topology and state

Simplied Opera?ons Enhanced Agility New Business Opportuni?es

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

Classes of Use-Cases
Leveraging APIs and logically centralized control plane components
Custom Routing (incl. business logic) Online Traffic Engineering
Custom Traffic Processing (Analytics, Encryption)
Consistent Network Policy, Security, Thread Mitigation
Virtualization and Domain Isolation (Device/Appliance/Network)
Federating different Network Control Points (LAN-WAN, DC-WAN, Virtual-Physical, Layer-1-3)
Automation of Network Control and Configuration (Fulfillment and Assurance)

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

Towards Programmatic Interfaces to the Network

Approaching Todays Application Developer Dilemma
Many Network Applications today:

New Model for Network Applications

Keep speed and agility

App

Full-duplex interac?on with

the network across mul?ple
planes extract, control,
leverage network state

New

Avoid network interaction

complex and slow innovation

Fast

App

Slow

OTT for speed and agility

Service

Edge

Appliance
Service

CLI(s)

Service

Core

CPE

Service

Mobile

A New Programming Paradigm is Needed

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

Re-assessing the Network Control Architecture

Evolving Design Constraints on the Control Plane
Classic generic networks
Operate without communication guarantees
A distributed system with arbitrary failures, nearly unbounded latency, and highly variable resources on each node in the
system

Compute the configuration/forwarding-state of each physical device and keep the information up to
date as conditions change
Change of conditions typically detected by the network elements themselves

Operate within given network-level protocol (IP, Ethernet, )

Domain specific networks (e.g. Data-Center, SP-Access/Agg,..)

Specific qualities of these networks relax or evolve network design constraints:
Examples: Well defined topologies; little variety in network device-types; no arbitrary changes in connected end-hosts
(change always an outcome of provisioning action),

Independence of network-level protocol (combined L2, L3 service delivery,)

Different solutions for different domains: DC != WAN, TOR != PE

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

Towards the Open Network Environment for SDN

Implementation Perspective: Evolve the Control-Plane Architecture
Tradi?onal Control Plane
Architecture

Control Plane Architecture with SDN (Examples)

Enable modularization and componentization of network control- and data-plane functions, with
associated open interfaces. This allows for optimized placement of these components (network devices,
dedicated servers, application servers) and close interlock between applications and network functions.
Anticipated benefits include: Closely align the control plane with the needs of applications, enable
componentization with associated APIs, improve performance and robustness, enhance manageability,
operations and consistency
Control-plane component(s)
BRKRST-2051

Data-plane component(s)
2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

Open Network Environment

Approaching a Definition
Resource Orchestration & Analytics
Network Middleware

Programmatic Interfaces
API

Server

Server

API

Integrated Physical & Virtual Infrastructure

physical

virtual
physical
virtual

API
API
API

virtual

physical
virtual

Server

physical

BRKRST-2051

Server

2012 Cisco and/or its affiliates. All rights Cisco

reserved.
Conden?al

Cisco Public

Open Network Environment

Approaching a Definition
Resource Orchestration & Analytics
Network Middleware

Programmatic Interfaces

Controllers and Agents

Integrated Physical & Virtual Infrastructure

Platform APIs

Virtual Overlays

BRKRST-2051

2012 Cisco and/or its affiliates. All rights Cisco

reserved.
Conden?al

Cisco Public

Open Network Environment

Open Network Environment Complementing
the Intelligent Network
Preserve what is working:
Resiliency, Scale and Security,
Comprehensive feature-set
Evolve for Emerging Requirements:
Operational Simplicity, Programmability,
Application-awareness

Open
Network Environment

Programma<c
APIs

The Open Network Environment

integrates with existing infrastructure
Software Defined Network concepts are a
component of the Open Network Environment

Resource
Orchestra<on -
Agents and
Controllers

Simplied Opera?ons
Enhanced Agility

The OpenFlow protocol can be used to link agents and

controllers, and as such is component of SDN as well
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Network
Virtualiza<on
Infrastructure

Cisco Public

Network Mone?za?on

Programmatic Network Access Multiple Layers

Full-Duplex access to the network at multiple layers and networking planes
Enable a holistic Network
Programming model

Applica?ons/Developm.
Programma8c network
automa8on, e.g. Cisco Pulse,..

Leverage and extend

infrastructure at pace
of the business
Deploy common applications
across all devices
Extend/upgrade/add features
without upgrading the
network operating system
Reduced time to market by
leveraging common platform
for building services

Orchestra?on
Network wide service access:
Op8mized paths (PCE), Topology
& service selec8on (NPS/ALTO),
MediaTrace, Address mapping, ..

ONE

Control
SDN

Common forwarding
abstrac8ons: Data-Path access,
Flow-Forwarding, Tunneling, ..

Transport/Device
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Applica8on development
frameworks, e.g. Spring,

Harvest
Network
Intelligence

Management
Automated, policy directed service
and cloud management, e.g.
NetworkService Manager,
OpenStack,

Network Service
Common control abstrac8ons:
Security, Policy, Rou8ng, ..

Forwarding
Device congura8on, state
monitoring, logging, debugging

Cisco Public

Program for
Op8mized
Experience

13

Open Network Environment Qualities

Programmatic APIs

Programma?c
APIs

Resource
Orchestra?on

Network
Infrastructure
Virtualiza?on

The Need for Abstractions

Abstractions in Networking

Data-plane Abstractions ISO/OSI Layering

Examples
Local best effort delivery (e.g., Ethernet)
Global best effort delivery (e.g., IP)
Reliable byte-stream (e.g., TCP)

Data plane abstractions are key to Internets success

Abstractions for the other planes (control,

services, management, orchestration,..)
are missing

Modularity based on
abstrac8on is the way
things get done
Barbara Liskov
Turing Award Winner

Consequences include:
Notorious difficulty of e.g. network management solutions
Difficulty of evolving software for these planes

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

In computer science, abstraction is the process by which data and

programs are defined with a representation similar in form to its
meaning (semantics), while hiding away the implementation details.
Abstraction tries to reduce and factor out details so that the programmer
can focus on a few concepts at a time. A system can have several
abstraction layers whereby different meanings and amounts of detail are
exposed to the programmer. For example, low-level abstraction layers
expose details of the computer hardware where the program is run,
while high-level layers deal with the business logic of the program.
h&p://en.wikipedia.org/wiki/Abstrac?on_Computer_Science

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

16

Approaching abstractions for Networking

Tenant
Control

Abstractions allow the definition

of associated APIs
Enable API platform kit across all
platforms, to integrate with development
environments

Authen?ca?on

Accelerate development of network

applications: Completely integrated
stack from device to network
Multiple deployment modes (local
and remote (blade/server) based APIs)
Multiple Language Support (C, Java, Python)
Integrate with customer development
to deliver enhanced routing, forwarding..
BRKRST-2051

Network
Stats

Network
Topology

Service
Placement

Service
Path

Service
Discovery

Rou?ng

Neighbor
Discovery

Addressing/
Mapping

Forwarding
Policy, QoS

Data-Path/
Packet Access

Interface,
Tunnel

Debugging

Diagnos?c
Events

Device
Capabili?es

Device focused abstrac?ons

2012 Cisco and/or its affiliates. All rights reserved.

Segment
Federa?on

Tenant
Security
Provisioning Thread Control

Service/Network focused abstrac?ons

Cisco Public

17

APIs make Abstractions available to Programmers

Example: Ciscos onePK (one Programming Kit) Get your build on!

Applica?ons
That YOU
Create
onePK

Flexible development environment to:

Innovate
Extend
Automate
Customize
Enhance

Any Cisco
Router or
Switch
BRKRST-2051

Modify

2012 Cisco and/or its affiliates. All rights Cisco

reserved.
Conden?al

Cisco Public

Evolving How We Interact With The Network Operating System

CLI

Evolu?on

IOS

SNMP
HTML

Monitoring

XML

Policy

AAA

Interface

CDP

Discovery

Syslog
Neglow
Rou?ng Protocols

C
Java

Rou?ng
Data Plane

Span
Ac?ons

BRKRST-2051

App

Events

App
EEM (TCL)

2012 Cisco and/or its affiliates. All rights Cisco

reserved.
Conden?al

Cisco Public

Anything you can think of

Tradi?onal Approach

onePK Architecture
C, JAVA Program
onePK API Presentation

onePK API Infrastructure

IOS / XE
(Catalyst, ISR, ASR1K)

BRKRST-2051

NXOS
(Nexus Platforms)

2012 Cisco and/or its affiliates. All rights Cisco

reserved.
Conden?al

IOS XR
(ASR 9K, CRS)

Cisco Public

onePK Application Hosting Options

Process Hos?ng

Blade Hos?ng

Network OS

End-Point Hos?ng

Network OS

Network OS
External
Server

onePK Apps

Blade

Container
Container
onePK Apps

Write Once, Run Anywhere

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

onePK
Apps

onePK APIs are Grouped in Service Sets

Base Service Set

Description

Data Path

Provides packet delivery service to application: Copy, Punt, Inject

Policy

Provides filtering (NBAR, ACL), classification (Class-maps, Policy-maps), actions (Marking,

Policing, Queuing, Copy, Punt) and applying policies to interfaces on network elements

Routing

Read RIB routes, add/remove routes, receive RIB notifications

Element

Get element properties, CPU/memory statistics, network interfaces, element and interface
events

Discovery

L3 topology and local service discovery

Utility

Syslog events notification, Path tracing capabilities (ingress/egress and interface stats, nexthop info, etc.)

Developer

Debug capability, CLI extension which allows application to extend/integrate applications

CLIs with network element

BRKRST-2051

2012 Cisco and/or its affiliates. All rights Cisco

reserved.
Conden?al

Cisco Public

Yes, it is secure
Security Five Ways
App
Security

Code Isolation
Strong Typing

Admin
Security

Code
Security

AAA (PKI)
Encryption (TLS)

BRKRST-2051

Digital Signing
Certification Process

Runtime
Security

Container
Security

2012 Cisco and/or its affiliates. All rights Cisco

reserved.
Conden?al

CLI Control
Resource Allocation

Isolation
Resource Consumption

Cisco Public

Not all Networking APIs are created the same

Classes of Networking APIs following their Scope
Classify Networking APIs based
on their scope

U?lity

API Scopes:
Location independent; Area;
Particular place; Specific device

Example: Get Auth, Publish Log,..

Scope: Loca?on independent

Alternate approaches like device/

network/service APIs difficult to
associate with use cases

Example: Domain, OSPF-area,..

Scope: Group/Set/Area

Location where an API is hosted

can differ from the scope of the API

Different network planes could

implement different flavors of
APIs, based on associated
abstractions
BRKRST-2051

Area/Set

Place in the Network

Example: Edge Session, NAT
Scope: Specic place/loca?on

Element
Example: interface sta?s?cs
Scope: Specic element

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

24

APIs at work Element APIs

Example: Statistics, Diagnostics & Troubleshooting
Objective:
Provide operators/
administrators/ support
engineers with details about
how packets flow through the
network.

S ta

Flow Switching Details

rt T
rac
e

Applica?on
using onePK

onePK

Reveal network issues

Approach
NMS application leverages
onePK APIs to show path of
flow, timestamp, ingress/egress
interfaces, interface packet
counts
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Ingress time: May 15, 2011 00:46:55.145

Ingress intf: Gi0/1
Ingress pkts: 30
Egress time: Jun 6, 2011 00:46:55.251
Egress intf: Gi0/0
Egress pkts: 5

Cisco Public

25

APIs at work Place in the Network APIs

Example: Dynamic Bandwidth/QoS Allocation
Business Problem
Enable superior experience for
subscribers which access a particular
cloud service

Solution

Request premium
service 1

Install customer policy (QoS, access

control,..) using onePK on key networking
elements, e.g. Provider Edge (PE) routers
Similarities to broadband Bandwidth on
Demand use cases
Broadband: Policy controlled on SubscriberGateway (BRAS/BNG, GGSN/PGW, ..) only
Common API like onePK enables control points
on all key networking devices

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Policy
Server

Install customer policy

on all key network elements
2

SP Network

Cloud Services
Egress PE

Ingress PE

Customer trac is gelng

superior/specic treatment

Cisco Public

26

APIs at work Area APIs

Example: Custom Routing
Business Problem
Network operator needs to
direct traffic using unique or
external decision criteria;
e.g route long lived elephant
flows, like backup traffic
differently

Solution

Select packets take a custom

policy-based route

Data
Center B
Data
Center A

Custom route application built

and deployed using onePK,
communicating directly with
the forwarding plane.
Unique data forwarding
algorithm highly optimized for
the network operators
application.
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Secure Communica?ons Channel

App
Custom rou?ng applica?on hosted on a server,
communicates securely with onePK infrastructure to
route specic packets according to a custom policy.
API presenta?on layer

Cisco Public

27

APIs at work Area APIs

Examples: Topology graph
Network
Posi?oning
System

Business Problem

Hadoop
Op?miza?on

Topology
Visualiza?on

Several problems require a view of the

network topology (area, domain, or whole
network)
Examples:
Locate optimal service out of a given list

Topology API

Optimize Load Placement

Visualize the active Network Topology

Solution
Topology API to expose network topology
to applications, such as
NPS (for service selection)
Hadoop (for optimal job placement)
NMS (for topology visualization)

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

28

Example: Custom Routing

Data Center Traffic Forwarding Based on a Custom Algorithm
Business
Data & Logic
onePK Custom
Rou?ng Applica?on

y
log ry
o
p
e
To cov
s
Di

BRKRST-2051

Unique Data Forwarding Algorithm Highly Optimized

for the Network Operators Application
2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

onePK and Agent Framework

Enabling specific solutions/protocols (OpenFlow, IRS,) on top of onePK
Application Framework / Controller
Agent Communication
Component
Solu?on dened protocol
(e.g. OpenFlow)

Agent Implementation (e.g. OpenFlow)

onePK APIs Presentation

Agent Framework

onePK API Infrastructure

IOS / XE

NX-OS

IOS-XR
Cisco Conden?al

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

Open Network Environment Qualities

Programmatic APIs
ONFs OpenFlow Protocol

Programma?c
APIs

Resource
Orchestra?on

Network
Infrastructure
Virtualiza?on

OpenFlow
Original Motivation
Research communitys desire to be able to experiment with new control paradigms

Base Assumption
Providing reasonable abstractions for control requires the control system topology to be
decoupled from the physical network topology (as in the top-down approach)
Starting point: Data-Plane abstraction: Separate control plane from the devices that implement data plane

OpenFlow was designed to facilitate separation of control and data planes in a

standardized way
Current spec is both a device model and a protocol
OpenFlow Device Model: An abstraction of a network element (switch/router);
currently (versions <= 1.3.0) focused on Forwarding Plane Abstraction.
OpenFlow Protocol: A communications protocol that provides access to the forwarding plane of an
OpenFlow Device
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

Nothing new under the sun

Starting point of Data-Plane Abstraction & Data- and Control Plane separation isnt new
Ipsilon Flow Switching

IETF ForCES WG

Centralized flow based control, ATM link layer

Separation of control and data planes

GSMP (RFC 3292)

RFC 3746 (and many others)

AT&T SDN

GMPLS, MPLS-TP

Centralized control and provisioning of SDH/TDM

networks

A similar thing happened in TDM voice to

VOIP transition

PBB-TE
Multiple Cisco product examples, e.g.

Softswitch Controller

Wireless LAN Controller (WLC) APs

Nexus 1000V (VSM VEM)
Remember RSM (7200 on a stick with Catalyst
5000 as dataplane)?

Media gateway Switch

H.248 Device interface

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

33

OpenFlow
Basics

OpenFlow Components
Application Layer Protocol: OF-Protocol
Device Model: OF-Device Model
(abstraction of a device with Ethernet
interfaces and a set of forwarding
capabilities)
Transport Protocol: Connection
between OF-Controller and OF-Device*

Observation:
OF-Controller and OF-Device need preestablished IP-connectivity
Source: OpenFlow 1.3.0 specica?on, gure 1
* TLS, TCP OF 1.3.0 introduces auxiliary connec?ons, which can use TCP, TLS, DTLS, or UDP.
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

34

OF Processing Pipeline
OF 1.0 model
(single lookup)

OF 1.1 and beyond model

(mul?ple lookups)
Ingress Port

CONTROLLER

Packet IN

Table 0

Packet+
Ingress Port +
Metadata

Table 1

Table n

Packet
Ac?on Set

Ac?on Set {}
Packet IN

Single
Table

Execute
Packet OUT
Ac?on
Set

Ac?on Set

Packet OUT

Packet DROP

35

Source: OpenFlow 1.3.0 specica?on, gure 2

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

OpenFlow Table
Match Fields (ingress port, packet header, metadata from previous table)
Priority (matching precedence of flow entry)
Counters (matching packets)
Instructions (modify action set, pipeline processing)
Timeouts (flow expiry)
Cookie (opaque data chosen by controller)

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

36

Packet Flow through an OpenFlow Switch

Source: OpenFlow 1.3.0 specica?on, gure 3

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

37

Required Match Fields

Field

Description

OXM_OF_IN_PORT

Ingress port. This may be a physical or switch-defined logical port.

OXM_OF_ETH_DST

Ethernet source address. Can use arbitrary bitmask

OXM_OF_ETH_SRC

Ethernet destination address. Can use arbitrary bitmask

OXM_OF_ETH_TYPE

Ethernet type of the OpenFlow packet payload, after VLAN tags.

OXM_OF_IP_PROTO

IPv4 or IPv6 protocol number

OXM_OF_IPV4_SRC

IPv4 source address. Can use subnet mask or arbitrary bitmask

OXM_OF_IPV4_DST

IPv4 destination address. Can use subnet mask or arbitrary bitmask

OXM_OF_IPV6_SRC

IPv6 source address. Can use subnet mask or arbitrary bitmask

OXM_OF_IPV6_DST

IPv6 destination address. Can use subnet mask or arbitrary bitmask

OXM_OF_TCP_SRC

TCP source port

OXM_OF_TCP_DST

TCP destination port

OXM_OF_UDP_SRC

UDP source port

OXM_OF_UDP_DST

UDP destination port

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

38

OF Match Fields

OFPXMT_OFB_IN_PORT = 0, /* Switch input port. */

OFPXMT_OFB_ARP_OP = 21, /* ARP opcode. */

OFPXMT_OFB_IN_PHY_PORT = 1, /* Switch physical input port. */

OFPXMT_OFB_ARP_SPA = 22, /* ARP source IPv4 address. */

OFPXMT_OFB_METADATA = 2, /* Metadata passed between tables. */

OFPXMT_OFB_ARP_TPA = 23, /* ARP target IPv4 address. */

OFPXMT_OFB_ETH_DST = 3, /* Ethernet destination address. */

OFPXMT_OFB_ARP_SHA = 24, /* ARP source hardware address. */

OFPXMT_OFB_ETH_SRC = 4, /* Ethernet source address. */

OFPXMT_OFB_ARP_THA = 25, /* ARP target hardware address. */

OFPXMT_OFB_ETH_TYPE = 5, /* Ethernet frame type. */

OFPXMT_OFB_IPV6_SRC = 26, /* IPv6 source address. */

OFPXMT_OFB_VLAN_VID = 6, /* VLAN id. */

OFPXMT_OFB_IPV6_DST = 27, /* IPv6 destination address. */

OFPXMT_OFB_VLAN_PCP = 7, /* VLAN priority. */

OFPXMT_OFB_IPV6_FLABEL = 28, /* IPv6 Flow Label */

OFPXMT_OFB_IP_DSCP = 8, /* IP DSCP (6 bits in ToS field). */

OFPXMT_OFB_ICMPV6_TYPE = 29, /* ICMPv6 type. */

OFPXMT_OFB_IP_ECN = 9, /* IP ECN (2 bits in ToS field). */

OFPXMT_OFB_ICMPV6_CODE = 30, /* ICMPv6 code. */

OFPXMT_OFB_IP_PROTO = 10, /* IP protocol. */

OFPXMT_OFB_IPV6_ND_TARGET = 31, /* Target address for ND. */

OFPXMT_OFB_IPV4_SRC = 11, /* IPv4 source address. */

OFPXMT_OFB_IPV6_ND_SLL = 32, /* Source link-layer for ND. */

OFPXMT_OFB_IPV4_DST = 12, /* IPv4 destination address. */

OFPXMT_OFB_IPV6_ND_TLL = 33, /* Target link-layer for ND. */

OFPXMT_OFB_TCP_SRC = 13, /* TCP source port. */

OFPXMT_OFB_MPLS_LABEL = 34, /* MPLS label. */

OFPXMT_OFB_TCP_DST = 14, /* TCP destination port. */

OFPXMT_OFB_MPLS_TC = 35, /* MPLS TC. */

OFPXMT_OFB_UDP_SRC = 15, /* UDP source port. */

OFPXMT_OFP_MPLS_BOS = 36, /* MPLS BoS bit. */

OFPXMT_OFB_UDP_DST = 16, /* UDP destination port. */

OFPXMT_OFB_PBB_ISID = 37, /* PBB I-SID. */

OFPXMT_OFB_SCTP_SRC = 17, /* SCTP source port. */

OFPXMT_OFB_TUNNEL_ID = 38, /* Logical Port Metadata. */

OFPXMT_OFB_SCTP_DST = 18, /* SCTP destination port. */

OFPXMT_OFB_IPV6_EXTHDR = 39, /* IPv6 Extension Header pseudo-field */

OFPXMT_OFB_ICMPV4_TYPE = 19, /* ICMP type. */

OFPXMT_OFB_ICMPV4_CODE = 20, /* ICMP code. */

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

39

OpenFlow Actions
Output
Set-Queue* (for QoS)
Drop
Group
Push-Tag/Pop-Tag*
Set-Field* (e.g. VLAN)
Change-TTL*

*Op?onal

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

40

OpenFlow Ports
Physical Ports, Logical Ports, Reserved Ports
Physical Ports == Ethernet Hardware Interfaces
Logical Ports == ports which are not directly associated with hardware interfaces (tunnels, loopback
interfaces, link-aggregation groups)
Can include packet encapsulation. Logical ports can have metadata called Tunnel-ID associated with them

Reserved Ports
ALL (all ports of the switch)
CONTROLLER (represents the control channel with the OF-controller)
TABLE (start of the OF-pipeline)
IN_PORT (packet ingress port)
ANY (wildcard port)
LOCAL* (local networking or management stack of the switch)
NORMAL* (forward to the non-OF part of the switch)
FLOOD*
* Op?onal
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

41

OpenFlow Ports
Simplified View
CONTROLLER port
Physical Port

OF-Switch
part

Logical Port (represen?ng a VLAN)

Logical Port (represen?ng a VLAN)
Logical Port
(represen?ng link aggrega?on group)

TABLE
IN_PORT

LOCAL Port
NORMAL Port

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Classic Switch
part

Cisco Public

42

OpenFlow Ports
CONTROLLER port and NORMAL port
CONTROLLER

NORMAL

Forward packets to Controller

For reactive mode of operation
Considerations
Latency for decision making
Bandwidth between OF-switch and OFcontroller
Speed at which rules can be installed/
removed

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

More of a concept than a real port:

Hand packets to classic part of the
switch
Forwarding operation in the classic part
is TBD
Xconnect?
L2-Bridge (use Dest-MAC to forward packet
to o/if)?
L3-Route (requires L3-next hop info as metadata from OF, or rely on classic routing
protocol)?

Cisco Public

43

Hybrid Model
One criticism of OpenFlow
OpenFlow is making all switches dumb, it requires complete re-implementation of entire control plane
in the logically centralized controller (due to OpenFlow being a protocol)

Hybrid Model acknowledges a more generic approach:

Re-architect the control plane architecture where needed
Keep existing control planes on network devices and evolve/complement them
Drive definition of additional modules and associated abstractions

Hybrid Model Concerns include

Reconciliation of state required in case multiple modules can create competing decisions (e.g. using
the RIB)
Potentially requires the OpenFlow device model to evolve and to include additional abstractions

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

A Couple Of Hybrid Switch Use Cases

Installing ephemeral routes in the RIB
Install routes in RIB subject to admin distance or
Moral equivalent of static routes, but dynamic
May require changes to the OF protocol/model

Edge classification
Use OF to install ephemeral classifiers at the edge
Moral equivalent of ip set next-hop <addr> (PBR)
Use case: Service Engineered Paths/Service Wires
Program switch edge classifiers to select set of {MPLS, GRE, } tunnels
Core remains the same

Service Chaining

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

Programmable Service Chains

Basic Use Cases
Endpoints vs. In-line services
Composite Services / Service Chaining

e2e: client-server, peer-to-peer

Flow Routing
Fine vs. Coarse Grained Flows
endpoint service

Filtering vs. Routing

Placement vs. Topology
Addressing vs. Flows

in-line service

Additional Use Cases to be considered

CDN, Optical xconnect,

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

in-line service chain

Cisco Public

ONF Hybrid WG
Goal
Explore and document the requirements for a hybrid programmable forwarding plane (OF controls a
subset of all flows): Will allow definition of required OF protocol extensions
Hybrid Switch and Hybrid Network

Allows the installed base of switches and routers to be utilized effectively while allowing OF
deployments to commence
Allows deployment scenarios in which only a subset of the devices are OpenFlow-enabled.

Focus
Use-cases for integrating OpenFlow programmed state in existing network and service architectures
Ships in the Night architecture
Will also investigate: Integrated Architecture

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

Hybrid Switch:
Ships in the Night vs. Integrated
Ships-in-the-Night
Control
Plane

OpenFlow

Integrated
Control Plane
OpenFlow

Router

Router

A subset of ports controlled by OF, another subset

controlled by routers na?ve CP physical resources are
par??oned
Some level of integra?on: OF_NORMAL:
Implementer free to dene what normal is
May or may not be what router normally does
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Use OF for feature deni?on augment the na?ve control

plane
No longer par??oning of resources
Can operate at dierent abstrac?on levels (low-level like
OF1.0 or higher level)
Cisco Public

OpenFlow Versions
Status
Dec 31, 2009

OF 1.0
Single Table
L2, IPv4 focused
matching

Feb 28, 2011

Dec 5, 2011

April 19, 2012

OF 1.1

OF 1.2

OF 1.3.0

Mul?ple Tables
MPLS, VLAN
matching
Groups:
{Any-,Mul?-}cast
ECMP

IPv6
Flexible-length
matching

802.1ah PBB
Mul?ple parallel
channels between
Switch and Controller

Current ONF focus is on maturing the specification

No new feature release in 2012
Working code before new standards
ONF should not anoint a single reference implementation but instead encourage opensource implementations; ONF board encourages multiple reference implementations
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

49

OpenFlow Evolution
Making OF functionally complete
Examples of ongoing work
Hardware friendly switch model negotiations (typed tables)
Investigate OpenFlow as an interface to the Control plane of a switch
(Hybrid Switch Model Integrated Mode;
e.g. incl. Layer 3 forwarding model etc.)
Security model (granular access control)
High availability model for device and controller (state re-sync etc.)
OF protocol not easily extensible

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

OpenFlow Evolution Challenge

Device Model: Getting the right abstraction is hard
Example Device Models

VPN
Switch/
Router
Switch/
Router

Generic
Forwarder

Forwarder
with Packet
Queuing/
QoS

Forwarder,
Longest
Forwarder, prex match
Exact
lookup
match
lookup
OpenFlow 1.1
OpenFlow 1.2/1.3
Future / hybrid OpenFlow versions?

BRKRST-2051

Loca?on-based Services
Mobility
Trac Op?miza?on (WAAS,..)
Address Transla?on
Security (Firewall,..)
Iden?ty
Network Virtualiza?on/Topology Control
Enhanced Trac/Event repor?ng
Network Graph Traversal / Rou?ng
Encapsula?on Control
QoS Control
Device capability exchange
Basic sta?s?cs
Packet Filtering
Packet Forwarding Control LPM lookup
Packet Forwarding Control Exact match lookup

Model complexity increases with

set of use-cases/solu?ons covered
2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

Open Network Environment Qualities

Programmatic APIs
IETFs Interface to the Routing System (IRS)

Programma?c
APIs

Resource
Orchestra?on

Network
Infrastructure
Virtualiza?on

Towards the Interface to the Routing System

Approach

Dynamically augment the Routing System /

Control Plane based on
Policy
Flow & Application Awareness
Time & External Changes

Measure/
Analy?cs

Program

Leverage
Topology (active & potential)
Events
Traffic Measurements

Feedback Loop: Control & Informa?on

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

53

IRS: Initial Requirements

Data Models for Routing & Signaling State
RIB Layer: unicast RIBs, mcast RIBs, LFIB, etc.
Protocols: ISIS, OSPF, BGP, RSVP-TE, LDP, PIM, mLDP, etc.
Related: Policy-Based Routing, QoS, OAM, etc.

Filtered Events for Triggers, Verification & Learning Changed Router

State
Data Models for State
Topology model, interface, Measurements, etc.

Application-Friendly Interface & Protocol(s)

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

54

IRS Framework
Application
IRS Client

IRS Agent

Policy
Database

Topology
Database

Routing and
Signaling
Protocols

RIB Manager
FIB
Manager

See also:
draw-ward-irs-framework, draw-atlas-irs-problem-statement,
draw-amante-irs-topology-use-cases, draw-keyupate-bgp-services,
BRKRST-2051
2012 Cisco and/or its affiliates. All rights reserved.

Subscription and
Configuration
Templates for
Measurement, Events,
QoS, etc

Cisco Public

55

IRS - Key Aspects & Anticipated Features

Multiple Simultaneous Asynchronous
Operations
Configuration Not Re-Processed
Duplex Communication

Installed State can have different lifetime

models:
Ephemeral (until reboot)
Persistent

High-Throughput

Time-based Persistent:
Expires after specified time

Highly Responsive

Time-based Ephemeral:
Expires after specified time

Multi-Channel (readers/writers)
Capabilities Negotiation/Advertisement
(self-describing)

Operations to install state have different

install-time models:
Immediately
Time-Based
Triggered by an Event

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

56

Open Network Environment Qualities

Resource Orchestration/Controllers:
Logically centralized and fully distributed Control

Programma?c
APIs

Resource
Orchestra?on

Network
Infrastructure
Virtualiza?on

Orchestration: Agents and Controllers

APIs

Consolidate State Across Multiple Network Elements

Agent

Some network delivered functionality benefits from logically

centralized coordination across multiple network devices
Functionality typically domain, task, or customer specific
Typically multiple Controller-Agent
pairs are combined for a network solution

Agent

Controller

APIs

APIs

Agent

Agent

APIs

APIs

Controller
Process on a device, interacting with a set
of devices using a set of APIs or protocols

Controller
Analyze

Offer a control interface/API

Agent

Gather

Act

Process or library on a device, leverages device APIs to deliver a

task/domain specific function
Controller-Agent Pairs offer APIs which integrate into the overall
Network API suite
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Notify

Observe

Agent
Cisco Public

Distributed Control
Exploring the tradeoff between Agents and Controllers and fully distributed Control

Control loop requirements differ per

function/service and deployment domain

Logically centralized

(using Controller-Agent pairs)

As loose as possible, as tight as needed

Latency, Scalability, Robustness,
Consistency, Availability

Services-Plane

Different requirements per use case

Control-Plane

Example:
Topology for Visualization (Network
Management) vs. Topology for PathComputation/Routing

How to decide which functionality is well

suited a particular control paradigm?

Data-Plane

Fully distributed
Note: Example only Not all network planes shown

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

59

Subsidiarity is an organizing principle that

matters ought to be handled by the smallest,
lowest or least centralized competent authority.
h&p://en.wikipedia.org/wiki/Subsidiarity

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

60

Decision making feedback loop

Considerations Applying Subsidiarity to Networking

Locations of event/state-source, state-processing, decision-making, actiontaking can follow specific requirements

Fully distributed, agent/controller architectures, etc.

Different design goals and pre-requisites

Required reaction time-scales
Fast convergence (e.g. for voice/video apps) vs. conservative reaction times (long running batch-type
applications)

Leveraging state/information from multiple sources (network and applications) for

decision making
Macro vs. micro-level decision making (e.g. link/device layer redundancy vs. cluster/
POD level redundancy in MSDC)

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

61

Evolving the Control Plane Environment

Deployment Considerations Applying Subsidiarity to Networking
fully distributed
(on-box)

Rapid prototyping (TTM vs. performance)

Algorithms which require coordina?on between instances, benet from a global view
Large scale tables with rela?vely infrequent updates (ARP,..)
Sowware/Algorithm for ?ghtly coupled homogeneous environments
Controlled/?ghtly-managed Environments
Rapid response to Topology Changes: Ecient plain vanilla Layer-3-style forwarding
Rapid response to data-plane events / packet forwarding
Simplicity of Control- and Data-Plane Integra?on**

** Past experience (e.g. PSTN AIN, Sowswitches/IMS, SBC): CP/DP split requires complex protocols between CP and DP.
* See also: Mar?n Casados Blog: h&p://networkheresy.wordpress.com/2011/11/17/is-openowsdn-good-at-forwarding/

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

logically centralized
(servers)

Considerations for Control-Plane Evolution

Decision making feedback loops Example: Packet forwarding control

E.g. Link state change

E.g. FIB programming

Event/State
Source

State
Distribu?on

State
Processing

Ac?on
Taking

E.g. Link state distribu8on

E.g. Topology computa8on

Decision
Making
E.g. Route computa8on
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

63

Packet Forwarding Decision Making

An obvious observation

Network devices delivering line rate

forwarding performance need to take
forwarding decisions as quickly as
packets arrive
In case a forwarding rule exists, apply
rule at line rate
In case a forwarding rule does not exist
Buffer the packet and create a rule (or ask
someone else to create a rule)

Interframe Gap Standard

(IFG)
(96 bit times)

Minimum on
reception*

Ethernet

9.6us

4.7us

Fast Ethernet

0.96us

Not defined

Gigabit
Ethernet

0.096us

0.064us

10 Gigabit
Ethernet

0.0096us

0.0047us

*IFG shrinking is allowed to cope with variable

network delays, clock tolerances, added preable bits

How much buffer do you have?

Drop the packet

Flood the packet
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

64

Forwarding decision making

Pro-Active and Re-Active Mode

Pro-Active: Compute rules upfront and install in the devices

Typical behavior of a router

Re-Active: Decide forwarding rules once packets arrive

Send first (or first few think TCP) packets of a flow to a decision making
entity (Controller) which creates a forwarding rule for the flow and
optionally performs forwarding on the first (or first few packets)
Bridges kind-of do this: Derive forwarding tables from packet MAC
addresses: Requires hardware based learning

Combinations
Default to pro-active, leverage re-active for certain exceptions (e.g. few, long
living flows)

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

65

Reactive Mode: Considerations

Decision making delay and
associated buffering
requirements

Decision Making

Bandwidth between
Forwarding &
Decision Making?
Eciency of channel
between Decision Making
and Forwarding (i.e.
avoid control plane
involvement)

Flow-setup / Flow-teardown
latency
Scale
Bandwidth/packet forwarding
requirements between
forwarding entity and decision
making entity

Forwarding

Total number of flows,

feasibility of rule aggregation
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Delay incurred
by decision making
and associated
buer requirements
on Forwarding
device?

Cisco Public

How quickly can you

program the forwarding
hardware?
- Large scale applica8ons
- Failure scenarios

66

Consistency and Availability

New Trade-offs in specific/constrained domains?

Consistency and Availability Trade-off

Typical databases are better at Consistency than
Availability, wide area databases cannot have both

Consistency

Availability

Trade-off typically domain specific

Trade-off between concurrency, performance and

consistency

Tolerance to
network
Partitions

Strict consistency can come at cost in update/read

latency and lower throughput
Trade-off typically domain specific

Classic network protocols

CAP Theorem: You can have at most two

of these proper?es for any shared data system
(Eric Brewer, UC Berkeley)

Designed for eventual consistency and partial failure;

solutions with different scope (i.e. IGP, BGP, ..)
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

67

Global vs. Local Optimum

Packet forwarding today solved as a distributed state problem
Optimal solution for shortest path (wrt/ link metrics)

Distributed algorithms sometimes only locate local optimum, not a global

optimum
Central view/control eases finding a global optimum
Frequent change of optimization parameters and algorithms used is easier if only done
on a single system, rather than in a distributed environment
OSPF RFC: 100+ pages on state distribution, only a few on the actual Dijkstra algorithm

Compute vs. Bandwidth trade-off: Centralization optimizes for CPU utilization, but
requires additional bandwidth to get to a decision
Speed vs. Accuracy: Often you go for a suboptimal but quick decision, compared to an
optimal, but slow decision (great late vs. acceptable fast)
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

68

Learning vs. Managed

Different Administration Paradigms in Networking
Learning systems: Derive decisions from observed behavior/events
Managed systems: Decisions driven through the management/orchestration system

No one-size-fits all
Federal Model central entities defining slowly evolving constraints, combined with
quick local, sometimes suboptimal, decision making

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

69

Open Network Environment Qualities

Resource Orchestration/Controllers

Programma?c
APIs

Resource
Orchestra?on

Network
Infrastructure
Virtualiza?on

Orchestration: Controllers and Agents

Task Specific Solutions and Generic Controller Infrastructure
Session Border
Control

Wireless LAN
Control

SIP-proxy/
SBC
H.248

SBC

SBC

B2BUA B2BUA

WLC

SBC

App

PCE

App

App

Control Programs leveraging

the ONE Controller
ONE Controller

CAPWAP

B2BUA

Generic Controller
Infrastructure

Path
Computa<on

AP

AP

PCEP

AP

PCC

PCC

PCC

OF-Agent

onePK

OF-Agent

onePK

OF-Agent

onePK

Networking already leverages a great breath of Agents and Controllers

Current Agent-Controller pairs always serve a specific task (or set of tasks) in a specific domain

System Design: Trade-off between Agent-Controller and Fully Distributed Control

Control loop requirements differ per function/service and deployment domain
As loose as possible, as tight as needed
Latency, Scalability, Robustness, Consistency, Availability
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

Controllers as Aggregation and Decision Points

Example: Network Positioning System (NPS)
Computes the location of and distance between
endpoints

Overlay-underlay Topology Correlation

Caching and replication are vital to optimization of

network traffic. Distribution paradigms efficiency is
augmented by dynamic mechanisms that locate
(and determine distance to) services and data in
order to optimize infrastructure resources utilization
Example: need to locate the nearest copy of a
movie or the closest instance of a service among
several available resources

NPS/Proximity leverages network layer and

Policy information.
Extended to other information sources such as:
state & performance and Geo-location
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Network Unaware

Network Aware

Aggarwal et al. show that when the p2p overlay topology is

network aware, it is highly correlated with the underlying network
topology; the nodes within an AS form a dense cluster, with only a
few connec?ons going to nodes in other AS.

(Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs and P2P systems co-operate for improved
performance?", ACM SIGCOMM Computer Communica?ons Review (CCR), 37:3, pp. 29-40 )

Cisco Public

Example: NPS
ALTO as the API
Example:
Request Reply Model: Address Ranking
Which targets in a given list of IP addresses are
the closest to a particular
query source (e.g.: user IP address) ?

CDN

Leverages IETF ALTO (Application Layer

Traffic Optimization) API
An API, through which an application can request
guidance from the network, here: for locating or
placing services
Preserves confidentiality between layers: No need
to know atomic topology details
2012 Cisco and/or its affiliates. All rights reserved.

P2P
Swarms

OTT
Overlay

Cloud
*aaS

ALTO

Simple location & distance request by application

to network

BRKRST-2051

REPLY
User IP Add: 10.1.1.1
Target-2: 10.30.1.1 10
Target-3: 10.40.1.1 20
Target-1: 10.20.1.1 30

REQUEST
User IP Add: 10.1.1.1
Target-1: 10.20.1.1
Target-2: 10.30.1.1
Target-3: 10.40.1.1

Policy

Service Loca?on,
Geo-
Perform-
Network Posi?oning
Loca?on
ance
Server

Network
Topology

Rou?ng

Network Devices

Cisco Public

73

Orchestration
Service Cross-Connect Network-Ramp to Cloud Services

Take request to provide services to a

given Cloud Service
Service Request

Control Traffic Routing traffic from Edge

to DC
Provision and manage
services in the DC

Services Cross Connect

Service

Traffic flow

SP Network
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Data Center
Cisco Public

Orchestration
Elastic DC Services

Route Traffic from Edge router

into a DC switch

Services Controller

Load Balance across a set of

service instances

Load Controller

Add more service instances when needed

VM Controller
Service

Remove services when not needed

Service

Service
Traffic flow

Load Balancer
Service

SP Network

Service

Data Center
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

Load
Monitor

Complementing classic VPN technologies

Network Partitioning, a.k.a. Slicing
VPN (L3VPN, L2VPN) technologies combine
Network Partitioning/Segmentation
Packet Forwarding Control (Control plane)

Slicing refers to Network Partitioning only,

i.e. no assumptions on the control plane made
Slices fully isolated (one slice not effecting resources and operation of other slices)
Several existing technologies incorporate slicing concepts, e.g.
PBB-TE network partitioned based on I-SID/VLANs (one partition controlled by STP, another one through a NMS)
MPLS-TP

ONE-Controller: Network slicing manager

Slicing manager defines/administers slices and maintains view of all slices in the network
Users only see their slice can be used e.g. as sandbox network for a given Dept/Developer

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

76

Orchestration & Virtualization: Network Partitioning

Example: Network Slicing for Research Environments
Business Problem
Research team A

University desires to slice the

network into multiple partitions:

Control Program/
Manager A

Research team B
Control Program/
Manager B

Slice 3: Research team A

Production network classic control

plane
Several research networks
experimentation with new control
algorithms, programs etc.

Dene Network
Par??ons/Slices

Solution
Network Slicing Manager
partitions the network based
on e.g. ports or VLANs

Network
Slicing
Manager

Slice 2: Research team B

Slice 1: Classic Control Plane

Network Administrator

Provides northbound interfaces,

incl. OpenFlow (Flowvisor-like)
Effects of a particular control
function of a partition/slice limited
to that partition/slice
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

77

Devices, Controllers and APIs

APIs represent
abstractions at different
layers complementing
each other

API

API

API

Service
Placement

Device-layer,
Network-layer etc.
Devices can deliver network
level abstractions and APIs
as well (e.g. link state
topology)
Common, consistent API,
different scopes

BRKRST-2051

API

Packet
Forwarding
Data-Path
Policy, QoS
Access

API

Common
consistent set of
APIs

Service
Path

Example
abstrac8ons and
associated APIs
delivered through
controllers

Network
Topology

Example
abstrac8ons
delivered by
individual device

Device level abstrac<ons Service/Network level abstrac<ons

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

78

Orchestration & Control

Cisco ONE Controller

Current Showcase
Examples
Flexible Network
Partitioning
and Provisioning (Slicing)
Network Troubleshooting

Applications (Cisco)

Applications (Customer)

Applications (3rd party)

Apps/Applica8ons
Northbound API

Built-in GUI for Management

Platform for generic

control functions state
consolidation across
multiple entities

Network Slicing

Network Troubleshooting

Custom Routing
Controller built-in Applica8ons

Flow Management

Forwarding Logic

Device Management
Controller Core Infrastructure

onePK API

OpenFlow 1.x Protocol

Southbound APIs (onePK, OneFlow,)

onePK

onePK

OpenFlow

OpenFlow

Custom Routing

Java-based
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

79

Orchestration & Path Computation

Deployments typically combine Device-APIs, device delivered Network-APIs, and
controller delivered Network APIs for a particular solution
Example: Data-Center Interconnect across two
providers with granular traffic forwarding control

L3 IP/MPLS Stateful PCE

Demand Admission API

PCEP, OF, IRS, CLI

Tunnel 1

Device Control

Path/Demand
Placement Engine

Collector

VNTM

BGP-LS, SNMP, OF, CLI, IRS

Topology

Tunnel 2

Provider 1

Datacenter 1

Provider 2

Op<cal Stateful PCE

GMPLS UNI

Tunnel 1

Demand Admission API

TL1, IRS, OF

Datacenter 2

Tunnel 2

Device Control

Path/Demand
Placement Engine

Collector

VNTM

TL1, BGP-LS

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

Orchestration
Multi-Layer PCE with iOverlay
Setup Service Instances

iOverlay

Se

Discovery, Status

Servic
e

unnel
rvice T

Service
XCON

Tunne
l

Services
el
Tunn

Tunn
el

Tunnel

Setup Tunnels (PCEP)

Link

IP/MPLS

Fib
er

L3 Link Topology
(BGP-LS)

Setup s (PCEP)

r
Fibe

DWDM Topology
(BGP-LS)

DWDM

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

ML-PCE

Example: Topology Exposure: Multi-Area IGP

ALTO server exposes multi-area IGP topology

ALTO server needs to

know all areas topology
Manually crafting of IGP
peering topology is tedious
and error prone

Approach:
Advertize Link-State
Information in BGP
draft-gredler-bgp-te

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

82

Full-Duplex Access across all Network Planes

Example: SP Network Model and Technology Context
Service Orchestra?on

Examples of evolving technologies:

Stateful PCEP: e.g. draw-crabbe-pce-stateful-pce
NPS/ALTO: e.g. draw-ieg-alto-protocol
CDN Internconec?on
onePK APIs
Protocols: NetConf/YANG, NetFlow, PCEP, Diameter, OF,
Topology exposure, e.g. BGP-LS

Service Control and Admin

NPS

Topologies,
Sta?s?cs

virtual Service Appliances/Gateways

Service Chaining, vPath
OF-Hybrid devices

Mul?-Layer PCE,
iOverlay

CDNI

Paths, Tunnels

DC/Cloud

IP/MPLS tunnels
Layer-3 Topologies

TE enhancements: draw-previdi-isis-metric-extensions
GENAPP: draw-isis-genapp-extensions
MPLS-TP

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Service Wires
Service Chains/Topologies

Wavelengths
Transport Topologies

Cisco Public

83

Open Network Environment Qualities

Network Infrastructure Virtualization

Programma?c
APIs

Resource
Orchestra?on

Network
Infrastructure
Virtualiza?on

In computing, virtualization is the creation of a

virtual (rather than actual) version of something,
such as a hardware platform, operating system,
storage device, or network resources.
h&p://en.wikipedia.org/wiki/Virtualiza?on

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

85

Network Abstractions support Virtualization

Blurring the lines between physical and virtual entities networks and services

Common Abstractions and common APIs across physical and virtual network elements
Virtual Overlay Networks
custom endpoint addressing
(e.g. for simple endpoint mobility)
custom topologies/segmentation

Map n Encap approaches to allow for exible overlays

and iden?ty and loca?on addresses:
L2-transport: FabricPath, 802.1ah
IP-transport: VXLAN, OTV, (L2-)LISP (all use the same frame format)
MPLS-transport: (PBB-)VPLS, (PBB-)EVPN

custom service chains

Example: vPATH

Virtual Service Appliances/Gateways

VSG, vWAAS

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

86

Virtual Overlay Networks

Example: Virtual Overlay Networks and Services with Nexus 1000V
Large scale L2 domains:
Tens of thousands of virtual ports

OpenStack
Quantum API

Common APIs

Nexus 1000V

Incl. OpenStack Quantum APIs

for orchestration

Scalable DC segmentation
and addressing
VXLAN

REST API

ASA 1KV

VXLAN
Gateway

Physical
(VLAN)
Network

VSG

ASA 55xx

Any Hypervisor

vWAAS

Virtual Services

Virtual service appliances and

service chaining/traffic steering

Tenant 1

Tenant 2

Tenant 3

Virtual Workloads

Physical Workloads

VSG (cloud-ready security), vWAAS (application acceleration), vPATH

Multi-hypervisor platform support: ESX, Hyper-V, OpenSource Hypervisors

Physical and Virtual: VXLAN to VLAN Gateway
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

87

Cloud technology stacks

Cloud Portal
and Orchestra<on

Virtual Network
Infrastructure

vCloud
Director/
DynamicOps

System
Center

Open
Source

CIAC/
OpenStack/
Partners

NSM/VNMC/
ONE Controller

ONE Controller/NSM

ONE Controller/NSM

ONE Controller/NSM

ASA 1KV
vWAAS
CSR 1KV

ASA 1KV
vWAAS
CSR 1KV

ASA 1KV
vWAAS
CSR 1KV

ASA 1KV
vWAAS
CSR 1KV

vPath

Hypervisor
Compu<ng PlaUorm
Physical Network

vPath

vPath

vPath

Nexus 1KV

Nexus 1KV

Nexus 1KV

Nexus 1KV

vSphere

Hyper-V

Open Source
(Xen, KVM)

vSphere, Hyper-V,
Xen, KVM

Management

Multi-Hypervisor and Multi-Orchestration Strategy

UCS
Nexus 2K-7K + ASR 9K (Edge)

Storage PlaUorm

Solutions: Vblock, FlexPOD, VMDC, VXI/VDI, HCS, Cross-DC Mobility

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

Open Network Environments

and Software Defined Networks

Summary: Open Network Environment

Leverage Network Value

Network
Services

m
m
y
ilit
ab

In
te
llig
en
ce

ra
og

BRKRST-2051

Orchestration

Pr

Program for
Op<mized
Experience

Analy<cs

2012 Cisco and/or its affiliates. All rights reserved.

Harvest
Network
Intelligence

Cisco Public

Some History
The early SDN architecture approach

Define target distribution

architecture upfront
Assume that suitable
abstractions can be found

Abstract Network View

Control
Nypervisor
Program

Approach

Global Network View

Data-plane abstraction as
starting point

Network Operating System

Network global view/state

abstraction (semantic free)
Control-programs (deal
with task-specific semantics)
Picture courtesy Sco& Shenker

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

91

Observations on early SDN architecture view

Finding the right (set of) device abstraction is hard
Too simple and you cant control important switch features, too complex and it becomes unimplementable
One size fits all probably impossible (see earlier experiences with e.g. H.248,)
Missing standardized definitions for northbound API/interface of the controller;
missing abstractions/APIs for Control Modules

Data-plane abstraction closely linked to OpenFlow protocol

Protocol nature inspires all control software to be removed from the network device, i.e. implemented
on a server (and be re-written)
In order to run the OpenFlow protocol the network device needs to implement a control plane
independent from what is controlled through OpenFlow (using OpenFlow only for an overlay network
with the underlying transport still using the normal control plane could be an escape out of this chickenand-egg situation)

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

92

Defining Generic Abstractions is Hard

Example: Network Graph Abstraction Layer
Network visualization
Loose timing and accuracy requirements

Accuracy/Consistency

Service/Load placement
Longer term heuristic algorithms used for service
placement, thus limited accuracy required

Forwarding: Generic Routing

Eventual consistency between forwarding and
control state (TTL for temporary loop protection)

Availability

Performance

Sub-second convergence time: Fast reaction to all occurring events

Forwarding: Generic Bridging

Strong consistency between forwarding and control state required (no loop protection in dataplane)
Sub-second convergence time: Fast reaction to all occurring events

Forwarding focused abstrac?ons: Consider opera?onal/debugging aspects

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

93

Evolve the early SDN Model

acknowledge the need for diverse abstractions

OF-Agent
Control
Plane

BRKRST-2051

Data
Plane

Management
Plane

2012 Cisco and/or its affiliates. All rights reserved.

Control
Plane

Diagnos?cs,
Events

Service
Discovery

Debugging

Service
Path

Cong &
Capabili?es

Agents

API infrastructure

API infrastructure

Service
Placement

Address
Mapping

Interfaces
and Tunnels

Network
Topology

Data-Path
Access

Forwarding
Policy, QoS

Data-Path
Access

Forwarding
Policy, QoS

Generic Controller

Rou?ng

Network stats
Analy?cs

App

App

App

APIs

Data
Plane

Cisco Public

Management
Plane

94

Programmatic Network Control and

the Gartner Hype Cycle
Technology Readiness Phases
Phase 1
Academic research
(OpenFlow)
Phase 2
Broad interest from technical
community + use cases (SDN)
Phase 3
Value Proposi<on for
mass market understood

Source: John Vrionis, LightSpeed Venture, opennetsummit.org/talks/ONS2012/vrionis-wed-closing.pdf

Entering Phase 3
BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

95

Open Network Environment for SDN

Applica?ons Management Orchestra?on
U5lity/Area/PIN APIs
(e.g. ALTO,.. )

Service/Network
Abstrac?ons

Network-Policy
Service-Path (incl. PCE, ..)
Loca8on/Topology (incl. ALTO, BGP-LS,)

U5lity/Area/PIN/Element APIs
(ex. ConnectedApps, PCEP, OpenFlow,
LISP-MS, OpenStack Quantum API, .. )

Physical Network Device

BRKRST-2051

APIs, Protocols,
Encapsula5ons
(e.g. BGP, IS-IS,..)

2012 Cisco and/or its affiliates. All rights reserved.

Virtual Network Device

Cisco Public

Open Network Environment for SDN

Focus: Network/Service Abstractions and associated APIs

Cloud
Cache
Network

MediaNet
Delivery
Network

Mul?-POD
Network
containers

Orchestra?on

Dynamic
Service
Chains

Applica?ons Management Orchestra?on

Service/Network
Abstrac?ons

Physical Network Device

BRKRST-2051

Network-Policy
Service-Path (incl. PCE, ..)
Loca8on/Topology (incl. ALTO, BGP-LS,)

Virtual Network Device

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

Open Network Environment

Focus: Network/Service Abstractions and associated APIs

BGP-LS,
ALTO,..

LISP-
MS,..

Physical Network Element

BRKRST-2051

NPS,..

PCE,..

ALTO

IRS

Virtual Network Element

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

Network stats
Analy?cs

Rou?ng

Service
Discovery

Service
Path

Service
Placement

Address
Mapping

Service/
Network
Abstrac?ons

Network
Topology

Applica?ons Management Orchestra?on

Open Network Environment for SDN

Focus: Device-level abstractions and associated APIs
Applica?ons Management Orchestra?on

Data Plane

Management Plane

Virtual / Physical Network Element

BRKRST-2051

Agents

API infrastructure
Control Plane

Neighbor
Discovery

Diagnos?c
Events

Debugging

Interfaces
and Tunnels

Data-Path
Access

Forwarding
Policy, QoS

Device
Capabili?es

Device
Congura?on

Service/Network Abstrac?ons

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

Industry Standards & Forums

Open Network Research
Center at Stanford
University

802.1 Overlay Networking Projects

Technical Advisory Group,

Working Groups:
Config, Hybrid, Extensibility,
Futures/FPMOD/OF2.0

Initiatives:
Quantum
Donabe
Overlay Working Groups:
NVO3, L2VPN, TRILL, L3VPN, LISP, PWE3
API Working Groups/BOFs
NETCONF, ALTO, CDNI, XMPP, SDNP, I2AEX
Controller Working Groups:
PCE, FORCES
New work items:
IRS Interface to the Routing System

Open Source Cloud

Computing project

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public

Summary

Summary: Open Network Environment

Cisco Innovations Summary announced at Cisco Live San Diego
onePK
Developer Kit

Controllers
+ Agent Support

Complete developers kit for

multiple Cisco Platforms, Servers,
Blades

Engage with universities &

research for campus slicing use
case

Rapidly develop test and deploy

Applications.

OpenFlow experimental support

on select Cisco platforms

Phased availability across IOS,

IOS-XR and NX-OS platforms

Controller SW for experimentation

on production networks

Programma?c
APIs

BRKRST-2051

Overlay
Network Solu<ons
Multi-hypervisor support on Nexus
1000V (incl. OpenSource hypervisor)
OpenStack and REST APIs on N1KV
for rapid tenant provisioning
VXLAN-VLAN gateway (for bridging
traditional environments)
Virtual or Physical Network Services

Controllers
and
Agents

2012 Cisco and/or its affiliates. All rights reserved.

Virtual
Overlays

Cisco Public

Cisco Vision: Exposing The Entire Network Value

Programmatic Control across Multiple Network Planes
Program Policies for
Op<mized Experience

Any Object

Applica?on Developer
Environment

Any Service

Analysis and Monitoring,

Performance and
Security
CISCO
SDN

Network Elements
and Abstrac?on

2012 Cisco and/or its affiliates. All rights reserved.

Cloud
Collaboration
Video
Security
Mobility

Any Layer

Harvest Network
Intelligence
BRKRST-2051

Switch/Router
ASIC
Network Fabric
Compute

Cisco Public

L1-7
Control/Data Plane
Hardware/Software
ASICs/OS

103

Open Network Environment Summary

The Industrys Broadest Approach to Programmatic Access to the Network
Evolutionary step for networking:
Complement/evolve the Network Control Plane where needed
Centered around delivering open, programmable environment for real-world use cases
No one-size-fits-all
Cisco will support Network Virtualization, APIs and Agents/Controllers
Joint evolution with industry and academia

Technology-agnostic
Not predicated on a particular technology or standard
Draw from Cisco technologies and industry standards

Delivered as incremental functionality

Many customers will use hybrid implementations
Build upon existing infrastructure with investment protection

BRKRST-2051

2012 Cisco and/or its affiliates. All rights reserved.

Open Network Environment

www.cisco.com/go/one
onePK
www.cisco.com/go/onepk
www.cisco.com/go/getyourbuildon

Cisco Public

104

Presentation_ID

2012 Cisco and/or its affiliates. All rights reserved.

Cisco Public