Software Defined Networks and OpenFlow

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
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
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
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
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
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
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)
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

Approaching a Definition
Resource Orchestration & Analytics
Network Middleware
Programmatic Interfaces
Controllers and Agents

Integrated Physical & Virtual Infrastructure

Platform APIs
Virtual Overlays
BRKRST-2051

reserved.
Conden?al
Cisco Public

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
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
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
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
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
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

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)

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)

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
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

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

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
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
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
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
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
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
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
Cisco Public

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
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
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
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

BRKRST-2051
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
Cisco Public
36
Packet Flow through an OpenFlow Switch

BRKRST-2051
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Cisco Public

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
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
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

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
Cisco Public
56

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
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
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
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
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
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
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
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
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
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
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
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
Cisco Public
69

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
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
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
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
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
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
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
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
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
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
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
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
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
Service Wires
Service Chains/Topologies
Wavelengths
Transport Topologies
Cisco Public
83

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
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
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
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
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
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
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
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
Cisco Public
93
Evolve the early SDN Model

acknowledge the need for diverse abstractions
OF-Agent
Control
Plane
BRKRST-2051
Data
Plane
Management
Plane
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
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,..)
Virtual Network Device
Cisco Public

Focus: Network/Service Abstractions and associated APIs
Cloud
Cache
Network
MediaNet
Delivery
Network
Mul?-POD
Network
containers
Orchestra?on
Dynamic
Service
Chains
Service/Network
Abstrac?ons
Physical Network Device
BRKRST-2051
Network-Policy
Service-Path (incl. PCE, ..)
Loca8on/Topology (incl. ALTO, BGP-LS,)
Virtual Network Device
Cisco Public

Focus: Network/Service Abstractions and associated APIs
BGP-LS,
ALTO,..
LISP-
MS,..
Physical Network Element
BRKRST-2051
NPS,..
PCE,..
ALTO
IRS
Virtual Network Element
Cisco Public
Network stats
Analy?cs
Rou?ng
Service
Discovery
Service
Path
Service
Placement
Address
Mapping
Service/
Network
Abstrac?ons
Network
Topology

Focus: Device-level abstractions and associated APIs
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
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
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
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
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

www.cisco.com/go/one
onePK
www.cisco.com/go/onepk
www.cisco.com/go/getyourbuildon
Cisco Public
104
Presentation_ID
Cisco Public

Software Defined Networks and OpenFlow

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Defined Networks and OpenFlow

Uploaded by

Copyright:

Available Formats

Software Defined Networks and OpenFlow

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

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

In the SDN architecture, the control and data planes are

open standard that enables researchers

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

A way to op8mize link u8liza8on in my network

An open solu8on for VM

An open solu8on for customized ow forwarding

A pla'orm for developing new

A solu8on to automated network

A means to get assured

Develop solu8ons at soTware speeds: I dont want

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

A solu8on to build virtual

A means to scale my xed/mobile gateways

a whole rather than individual devices

A way to build my own

A solu8on to get a global view of the

Simplied Opera?ons Enhanced Agility New Business Opportuni?es

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

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

Towards Programmatic Interfaces to the Network

New Model for Network Applications

Full-duplex interac?on with

Avoid network interaction

OTT for speed and agility

A New Programming Paradigm is Needed

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

Re-assessing the Network Control Architecture

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

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

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

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

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

Towards the Open Network Environment for SDN

Control Plane Architecture with SDN (Examples)

Open Network Environment

Integrated Physical & Virtual Infrastructure

2012 Cisco and/or its affiliates. All rights Cisco

Open Network Environment

Controllers and Agents

2012 Cisco and/or its affiliates. All rights Cisco

Open Network Environment

The Open Network Environment

The OpenFlow protocol can be used to link agents and

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

Programmatic Network Access Multiple Layers

Leverage and extend

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

Open Network Environment Qualities

The Need for Abstractions

Data-plane Abstractions ISO/OSI Layering

Data plane abstractions are key to Internets success

Abstractions for the other planes (control,

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

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

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

Approaching abstractions for Networking

Abstractions allow the definition

Accelerate development of network

Device focused abstrac?ons

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

Service/Network focused abstrac?ons