SDN From Concept To Reality

SDN From Concept to Reality
BRKRST-2051
Frank Brockners
Backup: For your reference
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 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
What is SDN for you?
A way to optimize link utilization in my network
enhanced, application driven routing An open solution for customized flow forwarding
A platform for developing new control in and between Data Centers
An open solution for VM control planes
mobility in the Data-Center Develop solutions at software speeds: I dont
A solution to automated network want to work with my network vendor or go
A way to reduce the configuration and control through lengthy standardization.
CAPEX of my network A means to get assured
and leverage commodity quality of experience for A solution to build a very large scale A means to do
switches my cloud service offerings layer-2 network traffic engineering
A solution to build virtual without MPLS
topologies with optimum
multicast forwarding behavior
A way to
A means to scale my fixed/mobile scale my
gateways and optimize firewalls and
their placement A way to optimize broadcast TV delivery
by optimizing cache placement and A way to build my own load
cache selection security/encryption solution balancers
A way to distribute policy/intent, e.g.
for DDoS prevention, in the network A way to configure my entire network A solution to get a global view of the
as a whole rather than individual network topology and state
devices
SDN The Origin
6
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
https://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
http://www.openflow.org/wp/learnmore/
Original SDN Architecture
Routing, access control, etc.

Control Program
Global Network View
Controller / Network OS
OpenFlow
Forwarding Model
BRKRST-2051 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public
SDN The Journey
9
Classes of Use-Cases
Cross-Domain Relationships & Automation Drive Network Architecture Evolution
Federating different Network Control Points

(DC-WAN-LAN, Virtual-Physical, Layer-1-3, IaaS+VPN)
Fast IT:
Consistent Network Policy,
Security, Threat Mitigation Automation of
Network Control
and Configuration
Custom Routing Network Virtualization,
(Fulfillment and Assurance
Online Traffic Engineering Service Chaining
Virtual & Physical)
Custom Traffic Processing Network Function
(Analytics, Encryption) Virtualization (NfV)
SDN origin
Different Audiences For Different Drivers
Federating different Network Control Points
(DC-WAN-LAN, Virtual-Physical, Layer-1-3, IaaS+VPN)
Fast IT:
Consistent Network Policy, Automation of
Security, Threat Mitigation Network Control
Custom Routing Network Virtualization, and Configuration
Online Traffic Engineering Service Chaining (Fulfillment and Assurance
Virtual & Physical)
Custom Traffic Processing Network Function
(Analytics, Encryption) Virtualization (NfV)
Network OS / Service
Application Developer, System Administrator, Network Operator
Developer
Extend, modify, customize the Leverage the functionality of the network and
functionality of the network integrate into new / existing software systems (applications & operations)
Relationship Evolution
Combining Organizations, Functions, Layers
Evolve what started with Dev+Ops = DevOps
Combined technologies Development Quality
Java, C, Python, REST, Chef, Puppet, OpenStack, Software Assurance
onePK, APIC, Controllers, NetConf/Yang, OpenFlow Engineering -
Combined use cases, deployment models and Application &
processes Network
Automated DC provisioning, dynamic traffic engineering,
integrated with routers and switches and continuous
integration .
Combined operations, developer and QA roles

IT and network operations, business application and Operations
infrastructure developers, development test, Network Compute, Network
Programmability Developers/Designers/Engineer Storage
Integrate: Simplify & Automate & Move Fast
Architecture Evolution
Concepts and Realities
Enable Cross-Layer Relations: Consistent Experience, Simpler Operations,

Distributed Systems Control Theory Automation, Smarter Systems
Enable Cross-Layer Relations:

Customization, Automation, Smarter Devices
Abstractions & Models / APIs
Domain-specific Network Architecture

Optimized Domain-specific Networking
Evolution
Scale-out, Fast & Flexible Deployments

Virtualization
(public/private/hybrid-cloud)
Evolve the Control- and Management Plane Architecture
Application
Software
Infrastructure
Software
Embedded
Software
Hybrid Control plane:

Distributed control combined with
Fully Distributed Control Plane:
logically centralized control for
Optimized for reliability
optimized behavior
(e.g. reliability and performance)
Evolving The Network Software Stack
Applications Application
(End-User and System Applications) Software
Resource Orchestration & Management

API API API
Infrastructure open source
Orchestration Management orchestration functions
Service Infrastructure
Functions Functions
Functions
Software
API
Elementary Infrastructure Functions
open source
(Controller-layer) integration layer
API and Plugins
Physical and Virtual Infrastructure Embedded

(Overlays and Network Function Virtualization) Software
Distributed Systems Control Theory

Abstractions & Models / APIs Enable Cross-Layer Relations
Distributed Systems Control Theory;
Evolution Dealing with Uncertainty
Virtualization
We suffer sometimes from the hubris of believing that control
is a matter of applying sufficient force, or a sufficiently detailed
set of instructions.
Mark Burgess, In Search of Certainty, July 2013

ISBN-13: 978-1492389163
Promise Theory
Promise theory is a model of voluntary cooperation
between individual, autonomous actors or agents
Agents publish their intentions to one another in the Promiser Promisee(s)
form of promises
Agent Agent
An agent can only make promises about its own A B
behavior (because that is all it can control): Problems
can be autonomously solved by the agent. C
Promises may not have been verified: Body: Nature of the promise
Requires a degree of trust between agents
Trust can be built based on prior keeping of promises
The set of agents and promises between them allow Agent A promises
for a creation of reasoning networks (graphs) based agent B to
on voluntary commitments fulfill C
Close association with bargaining games / game theory
See also: http://markburgess.org/BookOfPromises.pdf
Applicable beyond pure systems management
E.g. model BGP behavior (difficult with pure control theory), swarms*
BRKRST-2051 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 18 *Promise theory - a model of autonomous objects for pervasive computing and swarms, ICNS 2006
Applying Promise Theory
Identify agents of intent (the key players) Obligation Promise
Agents promise things independently
Anything/Anyone can document intent Manager Manager
Get your model right
Deal with Uncertainty

Example: MTBF; Need for speedy repair to Promise Promise to
keep promises Do X Done goal X do Y
and incentive
Design for voluntary cooperation
Mismatches of intent
Initial state of a system has unknown intentions
Orchestration: Create agreements where agents
promise to behave in a certain way Staff Staff
Obligations
Command and Control
The source of any obligation is external to the agent that is being obliged.
If the agent is unable (or unwilling) to cooperate (it might have never received
the message), the problem cannot be resolved without solving another
distributed cooperation problem to figure out what went wrong and so on.
Obligations represent strong couplings (hard dependencies) that make systems

brittle and fragile under unrealistic assumptions
Expecting only best effort behavior (promises) leads to more weakly coupled
systems that are more resilient and adaptive to fault (can deal with incomplete
information)
Imperative programming is a programming paradigm that describes computation in terms
of statements that change a program state. In much the same way that imperative mood in
natural languages expresses commands to take action, imperative programs define
sequences of commands for the computer to perform.
Derived from latin word imperare means to command
Declarative programming is a programming paradigm which expresses what the program

should accomplish without prescribing how to do it in terms of sequences of actions to be
taken. Functional and logic programming are examples of a more declarative approach.
Source: http://en.wikipedia.org/wiki/Imperative_programming
21
Imperative vs. Declarative Example

Imperative Example Declarative Example function is pure, i.e.
has no side effects
var numbers = [1,2,3,4,5] var numbers = [1,2,3,4,5]
(change external state)
var doubled = []
for(var i = 0; i < numbers.length; i++) { var doubled = numbers.map(function(n) {
var newNumber = numbers[i] * 2 return n * 2
doubled.push(newNumber) })
} console.log(doubled) //=> [2,4,6,8,10]
console.log(doubled) //=> [2,4,6,8,10]
Source: http://latentflip.com/imperative-vs-declarative/
Imperative and Declarative
Set indicator, pull clutch, Lets meet at Moscone,

switch to second gear, turn right, Laus.ilumi.de
at 1pm
Imperative and Declarative
Closed and Open Worlds
The declarative approach requires that Imperative (procedural) approach:
users specify the end state of the The imperative/procedural approach
infrastructure they want, and then the takes action to configure systems in a
software system makes it happen. series of actions.
Example: Puppet, CFEngine 3 Example: Chef, Ansible
Open World Assumption Closed World Assumption

Assumption that the truth-value of a Presumption that what is not currently
statement is independent of whether or known to be true is false.
not it is known by any single observer or
agent to be true.
No single agent or observer has
complete knowledge
Even though fundamentally different, resulting procedures can be similar in reality and
depend on object, scale, time-scales being dealt with (think Newton vs. Quantum mechanics)
See also: http://en.wikipedia.org/wiki/Closed_world_assumption http://en.wikipedia.org/wiki/Open_world_assumption
Promise Theory Takeaways for System Management
Autonomy of control (dont send instructions from outside)
local system/agent always takes the final decision
Autonomous agents can work independently or cooperate by information
sharing on a peer-to-peer basis: Decentralized
single point of control without single point of failure
Pull not push (voluntary cooperation, not attack)
Run many times system never gets worse (convergence & idempotence)
Automation needs to be self-monitoring and self-healing
A systems desired config state can be said to be defined by fixed points
We are taught that machines just do what we tell them after
all, we are smart and they are dumb. Unfortunately, its often
the other way around.
Mark Burgess, April 2014

http://www.infoq.com/articles/in-search-of-certainty-book-review

Abstractions, Models, APIs
Evolution
Virtualization
Towards Programmatic Interfaces to the Network
Approaching Todays Application Developer Dilemma
App Fast App
Slow
New
Service
Edge Appliance
Service
CLI(s)
CPE
Service Service
Core Mobile
BRKRST-2051
A New Programming Paradigm Is Needed
2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 28
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) Modularity based on
Data plane abstractions are key to Internets success abstraction is the way
Abstractions for the other planes (control, things get done
services, management, orchestration,..)
are missing Barbara Liskov
Turing Award Winner
Consequences include:
Notorious difficulty of e.g. network management solutions
Difficulty of evolving software for these planes
Abstractions arent always generic

(i.e. can be specific to an objective)
Full-Duplex, Multi-Layer/Multi-Plane APIs
Workflow Management
Management Network Configuration & Device Models, ..
Harvest L2-Segments, L3-Segments, Service-Chains
Orchestration Network
Intelligence Multi-Domain (WAN, LAN, DC)
Topology, Positioning, Analytics
Network Services Multi-Layer Path Control, Demand Eng.
Routing, Policy, Discovery, VPN, Subscriber,
Control AAA/Logging, Switching, Addressing , ..
Program for L2/L3 Forwarding Control, Interfaces,
Optimized
Experience
Forwarding Tunnels, enhanced QoS, ..
Device configuration, Life-Cycle
Device/Transport Management, Monitoring, HA, ..
Full-Duplex, Multi-Layer/Multi-Plane APIs
Industry Examples
Workflow Management
Management Network Models - Interfaces (OMI)
Network Configuration & Device Models, ..
L2-Segments, L3-Segments, Service-Chains

Orchestration Multi-Domain (WAN, LAN, DC) OpenStack, Neutron* API
Topology, Positioning, Analytics Positioning (ALTO)

Network Services Multi-Layer Path Control, Demand Eng. Path Control (PCE)
Routing, Policy, Discovery, VPN, Subscriber, Interface to the Routing System (I2RS),
Control AAA/Logging, Switching, Addressing , .. OpFlex,
L2/L3 Forwarding Control, Interfaces,

Forwarding Tunnels, enhanced QoS, .. OpenFlow Protocol
Device configuration, Life-Cycle

Device/Transport Management, Monitoring, HA, .. Network Function Virtualization (NfV)
BRKRST-2051 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 31 *a.k.a. Quantum
Choice of programmable layer
BI Collaboration ERM
Business
Applications Analytics Infrastructure S/W Service Management
IT Software Infra Orchestration Management Policy & Compliance
abstract
Controller
Network Device Plug-Ins
Device detail
Programmatic Network Access
Plug-ins/Agents as Flexible Integration Vehicles
Application Frameworks, Management Systems, Controllers, ...
onePK SDK
C/Java Python NETCONF REST OpenFlow ACI Fabric OpenStack Puppet Protocols
Management Puppet
Orchestration Neutron
Protocols
Network Services BGP, PCEP,...
Control OpFlex
Forwarding OpenFlow
Plug-In Infrastructure
Device API and Data Models
Operating Systems IOS / NX-OS / IOS-XR
Extend Operate, Configure, Integrate
onePK SDK for Rapid Application Development
DEVELOPER ENVIRONMENT
Language of choice Python Java C
Programmatic interfaces
Rich data delivery via APIs
COMPREHENSIVE SERVICE SETS Data Path Policy Element Route

Better apps
New services Discovery Utility Developer Others
Monetization opportunity
DEPLOY
On a server blade
On an external server
Directly on the device
CONSISTENT PLATFORM SUPPORT

IOS
NX-OS
IOS-XR
IOS NX-OS IOS-XR
SDK Offers onePK APIs Grouped Into Service Sets
Base Service Set Description
Data Path Provides packet delivery service to application: Copy, Punt, Inject
Provides filtering (NBAR, ACL), classification (Class-maps, Policy-maps), actions (Marking,

Policy Policing, Queuing, Copy, Punt) and applying policies to interfaces on network elements
Routing Read RIB routes, add/remove routes, receive RIB notifications
Get element properties, CPU/memory statistics, network interfaces, element and interface
Element events
Discovery L2 topology (CDP/LLDP) and local service discovery
Utility Syslog events and queries, AAA, NTP, DHCP, DNS, VTY
Debug capability, CLI extension which allows application to extend/integrate applications

Developer CLIs with network element
SDK Offers onePK APIs Grouped Into Service Sets
Extension
Service Set Description
Diagnostics Probe services using IPSLA, Pong
MediaTrace Enables applications to direct a request at multiple systems along a path without needing to
address those systems individually. Provides statistics about each link and node along a
path.
Identity Enables applications to add, update, delete and query a network session based on a
combination of query attributes such as username, MAC address, and/or IP address among
others.
Location Stores information related to physical location, including network device, network interface,
and end user session. Physical location types include geo-location and street address.
What can you do with onePK SDK?
A few examples by Cisco and Partners
Routing for Dollars, Routing for Latency (Java)
Network Wiring Verification (Python)
Network Configuration Automation w/ Puppet, Chef (Python)
Custom Encryption (C)
Mission Critical Application Monitoring & Analytics (by Starview)
Enabling security for classified information (by Pramacom)
GeoLocation Security Features for Router Management (by Glueware)
Mapping SAP HANA to network conditions (by SAP)
Load Balancer Management (by Citrix)
DDoS Protection as an SDN Network Service (by Arbor)
Device Programmability
Approach Follows Developer Audience
Extend Operate Configure
onePK SDK C, Java, Python NETCONF, REST, Puppet/Chef
Extend the functionality of the network Provisioning/Configuration/Operations

(add custom features): E.g. Traffic steering, centric use cases
packet manipulation and packet capture, NMS / OSS / BSS Provisioning:
Real time event handling Netconf/REST
Improved AppDev experience DevOps Tools: Puppet/Chef Plugins
Business logic centric Automation/Flexibility/Agility for existing features
onePK SDK Focus Tune And Extend The Engine
onePK
SDK NMS/CLI
API Infrastructure Approach
Extend Operate
C Java Python Netconf REST
Auto-generated bindings from data models
bgp-cfg
Common Cisco Data Models
Data-Model to Feature Wiring
Feature Implementation
A data model is a wayfinding tool for both business and IT
professionals, which uses a set of symbols and text to
precisely explain a subset of real information to improve
communication within the organization and thereby lead to a
more flexible and stable application environment
"Data Modeling Made Simple 2nd Edition", Steve
Hoberman, Technics Publications, LLC 2009
Model Driven Architecture

do you remember?
Model Driven Architecture (MDA) developed by the
Object Management Group (OMG) several years ago
Original idea: Focus first on the functionality and
behavior of an application or system without worrying
about the technologies that will be used to implement it
At the time of deployment the system description is
mapped to the supported platform automatically using
tools
Model: An object that represents another object, leaving
out unnecessary detail
Map Generate
Platform Independent Model (PIM) Platform Specific Model (PSM) Code
Data Models
module: network-topology
+--rw network-topology
Models are a representation, i.e. a good +--rw topology [topology-id]
+--rw topology-id topology-id
enough story or more formally a suitably +--rw topology-types
+--rw underlay-topology [topology-ref]
idealized approximation to something | +--rw topology-ref topology-ref
+--rw node [node-id]
Focus on the desired/required | +--rw node-id node-id
| +--rw supporting-node [node-ref]
capabilities/state for a specific purpose | | +--rw node-ref node-ref
| +--rw termination-point [tp-id]
Data models are to support the development |
|
+--rw tp-id
+--ro tp-ref*
tp-id
tp-ref
of information systems by providing the +--rw link [link-id]
+--rw link-id link-id
definition and format of data +--rw source
| +--rw source-node node-ref
If done consistently across systems, | +--rw source-tp? tp-ref
+--rw destination
compatibility can be achieved | +--rw dest-node node-ref
| +--rw dest-tp? tp-ref
Data models correspond to the solution +--rw supporting-link [link-ref]
+--rw link-ref link-ref
context they are built for
Different levels of abstractions
Example: Data-Model for network topology;
See also draft-clemm-netmod-yang-network-topo
What is YANG?
Yet Another Next Generation
Data modeling language YANG provides:
Can be used to model both configuration Human readable, and easy to learn
and operational data of network elements. representation
Can be used to define the format of event (Java/C-like syntax)
notifications emitted by network elements Hierarchical configuration data models
Originally designed to write data models Reusable types and groupings (structured
for NETCONF protocol; response to types) Extensibility through augmentation
SNMP/SMI shortcomings, mainly mechanisms.
Lack of support for simple things like backup-and- Supports definition of operations (RPCs)
restore of element configuration
No concept of transactions (single- or multi-box)
Formal constraints for configuration validation
Many inherent limitations in SMI (e.g. label length) Data modularity through modules and sub-
modules
RFC 6020 (October 2010) Well defined versioning rules
YANG Features Overview
Organization
Leaf, leaf-list, container, lists, grouping, choice
Data model structure

Module, submodule, augment, if-feature, when
Constraints
Must, unique, min-elements, max-elements, mandatory
Data types
Many built-in types, sub-typing, restrictions
Reusable groupings
Grouping, uses
Example YANG module:
BGP Neighbor configuration
container bgp-neighbors { leaf default-action {
description A container has notypevalue,
actions-enum; }
"The top level container for the list container
holds related children, hasaf-specific-config
one instance {
of neighbours of the BGP router."; [] }
list bgp-neighbor { container bgp-neighbor-state {
key "as-number"; A list has no value,description
holds related children,
leaf as-number { "Thehas
has multiple instances, operational
a key parameters describing
property
type uint32; } the neighbour state.;
choice peer-address-type { leaf adminStatus {
case ip-address { A choice allows one type
alternative of the choice} to exist. The
bgp-peer-admin-status;
leaf ip-address { leaf in-lastupdatetime {
type inet:ip-address; choice mechanism can typebe used to provide
yang:timestamp; } } extensibility hooks
mandatory true; } } container bgp-neighbor-statistics {
case prefix { that can be exploited using augments.
description
leaf prefix { "The operational parameters describing
type inet:ip-prefix; the neighbour statistics.;
mandatory true; } } staistical parameters.";
case host { leaf nr-in-updates {
leaf ip-host-address { type uint32; }
type inet:host; leaf nr-out-updates {
mandatory true; } } } type uint32; } } } }
leaf prefix-list {
type prefix-list-ref; } A leaf has one value, nodraft-zhdankin-netmod-bgp-cfg-00
Source: children, one instance
Applications
(End-User and System Applications)

API API API
Infrastructure
Orchestration Management
Deployment Reality: Service
Functions
Functions Functions
Plugins
API

(Controller-base layer)
Platform APIs and Plugins
Physical and Virtual Infrastructure

Where Do onePK Applications Run?
Choose the Hosting Model that Suits Your Platform and Your Application
On An External Server
Plentiful memory/compute
App Higher latency and delay
Supported on by all platforms
On A Hardware Blade
Dedicated memory/compute
Low latency and delay
Blade
Requires modular hardware blade
App
On the Router
Shared memory/compute
App Very low latency and delay
Available on select platforms
Network Be Nimble
The Plugin Model
Centralized
Application coordination
Centralized Management /
Time Scale (seconds) Orchestration Application
Frequent local actions Consolidated

Time Scale central
(minutes) reporting
onePK Application
Meta- and
exception-
Local first-order Any communication protocol analysis
analysis (XMPP, OF, CIM, REST, etc)
Open Application Container Enabling Plugins
Virtualized environment to host
applications on a Cisco device. Customer ISV Cisco
Apps Apps Apps
Wide range of applications shell, virtual
services, plugins
Applications can be developed and release
independent from Network OS release cycles
Application Examples: Plug-in 1 Plug-in 1

Plug-in 2 Plug-in 3
v1.17 v2.13
Cisco Virtual Services:
Integrated Appliance: ISR4451X-WAAS Container Container Container
Linux shell: Guestshell
Cisco Plugins:
Features with decoupled release cycles:
Puppet Plugin, Chef Plugin
Network OS
Case Third Party Services (onePK applications)
Integration With DevOps Tools
Puppet Master
REST
Puppet Plugin Puppet Agent Puppet Plugin Puppet Agent
Puppet Agent
Plugin
Container Switch Compute Switch Compute
Node Node
onePK API
Puppet agent hosted as a onePK plugin
Network OS Chef plugin works in a similar way
onePK configuration API to implement configuration change
Guestshell Application
Linux Shell Environment On Your Switch
Maintain NX-OS system integrity
Isolated User Space
Fault Isolation
Linux
Resource Isolation applications
Integrate into your Linux workflow

Guestshell
On-box rapid prototyping
Open Application Container
Device-level API Integration (onePK)
onePK
Scripting (Python)
Linux Commands Network OS
Integrated with NX-OS
CLI control of Shell (guestshell do <linux command>)
A Glimpse At Guestshell
Linux Container with Guestshell
Exec commands in the Guestshell from CLI

List the directory
Look at a file
Run a program
Log into guestshell and play further
Applications

API API API
Infrastructure
Protocol Reality Service
Functions
Functions Functions
OpenFlow Protocol
API

Platform APIs and Agents

(Overlays and Network Function Virtualization)
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.4.0) focused on Forwarding Plane Abstraction.
OpenFlow Protocol: A communications protocol that provides access to the forwarding plane of an OpenFlow Device
OpenFlow is an example of imperative control logic

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 pre-
established IP-connectivity
Source: OpenFlow 1.4.0 specification, figure 1
* TLS, TCP OF 1.3.0 introduced auxiliary connections, which can use TCP, TLS, DTLS, or UDP.
OF Processing Pipeline
OF 1.0 model OF 1.1 and beyond model
(single lookup) (multiple lookups)
Ingress Port Packet+

Ingress Port +
Metadata Execute
Table 0 Table 1 Table n Packet
Action Packet OUT
CONTROLLER
Packet IN

Action Set
Set
Action Set {} Action Set
Packet IN Single Packet OUT

Table
Packet DROP
Source: OpenFlow 1.3.2 specification, figure 2

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
OpenFlow Actions
Output
Set-Queue* (for QoS)
Drop
Group
Push-Tag/Pop-Tag*
Set-Field* (e.g. VLAN)
Change-TTL*
*Optional
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*
* Optional
OpenFlow Ports
Simplified View
CONTROLLER port
Physical Port
Logical Port (representing a VLAN)
Logical Port (representing a VLAN)
OF-Switch
part Logical Port
(representing link aggregation group)
TABLE
IN_PORT LOCAL Port
Classic Switch
NORMAL Port part
OpenFlow Ports
CONTROLLER port and NORMAL port
CONTROLLER NORMAL
Forward packets to Controller More of a concept than a real port: Hand
For reactive mode of operation packets to classic part of the switch
Considerations Forwarding operation in the classic part is
Latency for decision making TBD
Bandwidth between OF-switch and OF- Xconnect?
controller L2-Bridge (use Dest-MAC to forward
Speed at which rules can be packet to o/if)?
installed/removed L3-Route (requires L3-next hop info as meta-
data from OF, or rely on classic routing
protocol)?
Integration with Existing Networking Devices

The 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 e.g. maximum scale, node & link diversity,
availability combined with optimizations which follow business metrics
(e.g. $-cost, geographic/political considerations, ..)
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
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
Hybrid Switch:
Ships in the Night vs. Integrated
Ships-in-the-Night Integrated
(aka vertical partitioning*) (aka horizontal partitioning)
Control Plane
Control
OpenFlow OpenFlow
Plane
Router Router
A subset of ports controlled by OF, another subset Use OF for feature definition
controlled by routers native CP physical resources augment the native control plane
are partitioned No longer partitioning of resources
Some level of integration: OF_NORMAL: Can operate at different abstraction levels (low-level
Implementer free to define what normal is like OF1.0 or higher level)
May or may not be what router normally does
* See: ONF Architecture Draft 0.0.1

OpenFlow Versions
Status
Approved on
Dec 31, 2009 Feb 28, 2011 Dec 5, 2011 Apr 19, 2012 Jun 7, 2012 Sep 6, 2012 Apr 25, 2013 Oct 14, 2013 Dec 18, 2013 Mar 27 2014
OF 1.0 OF 1.1 OF 1.2 OF 1.3.0 OF 1.0.1 OF 1.3.1 OF 1.3.2 OF 1.4.0 OF 1.3.3 OF 1.3.4
Single Table Multiple Tables IPv6 802.1ah PBB Bug fixes Bug fixes Bug fixes Flexible ports Bug fixes Bug fixes
L2, IPv4 focused MPLS, VLAN Flexible TLV Multiple parallel Synch across
matching matching matching channels between flow tables
Groups: Multiple Switch and Controller Enhanced
{Any-,Multi-}cast Controllers Clustering
ECMP Flow-Monitoring
Evolution of the specification: Mature and Evolve
Working code before new standards
ONF should not anoint a single reference implementation but instead encourage open-source
implementations; ONF board encourages multiple reference implementations
OpenFlow 1.3.X: long term support
OpenFlow 1.4: extensibility, incremental improvements
OpenFlow 1.0.X : no work planned
Applications

API API API
Infrastructure
Programmatic APIs Service
Functions
Functions Functions
IETFs Interface to the Routing System

API


Towards the Interfaces to the Routing System

Approach
Dynamically augment the Routing System /
Control Plane based on
Policy
Flow & Application Awareness
Time & External Changes
Leverage Program Measure/

Topology (active & potential) Analytics
Events
Traffic Measurements

Feedback Loop: Control & Information

IETF I2RS: 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)
I2RS Framework
I2RS Client
I2RS Agent
Application
RIB Manager Subscription and

Routing and
Policy Topology Configuration Templates
Signaling
Database Database for Measurement,
Protocols FIB Events, QoS, etc
Manager
See also:
draft-ward-irs-framework, draft-atlas-irs-problem-statement,
draft-amante-irs-topology-use-cases, draft-keyupate-bgp-services,
I2RS - Key Aspects & Anticipated Features
Multiple Simultaneous Asynchronous Installed state can have different lifetime

Operations models:
Ephemeral (until reboot)
Duplex Communication Persistent
High-Throughput Time-based Persistent:
Expires after specified time
Highly Responsive Time-based Ephemeral:
Expires after specified time
Multi-Channel (readers/writers)
Operations to install state have different
Capabilities Negotiation/Advertisement install-time models:
(self-describing) Immediately
Time-Based
Triggered by an Event
See also: I2RS Charter

Applications

API API API
Infrastructure
Functions
Functions Functions
NETCONF and RESTCONF

API


What is NETCONF? RFC 6241
NETCONF is an IETF network management
protocol (originally defined in RFC 4741 in 2006) Configuration data
designed to support management of configuration,
including: <get-config>, <edit-config>, <notification>
Distinction between configuration and state data

<rpc>, <rpc-reply>
Multiple configuration data stores (candidate, running,
startup) BEEP, SSH, SSL, console
Configuration change validations
Configuration change transactions XML payload, modeled in YANG.
Selective data retrieval with filtering <get>, <get-config>, <edit-config>, <copy-
Streaming and playback of event notifications config>, <delete-config>, <lock>, <unlock>,
<close-session>, <kill-session>,
Extensible remote procedure call mechanism <notification>, <commit>
NETCONF server runs on networking device and

client runs as part the management application.
Basic NETCONF Operations
Get configuration <get-config>
Retrieve all or part of a specified configuration from a named data store
Get all information <get>
Retrieve running configuration and device state information
Edit configuration <edit-config>
Loads all or part of a specified configuration to the specified target configuration
Copy configuration <copy-config>
Create or replace an entire configuration datastore with the contents of another complete
configuration datastore
Delete configuration <delete-config>
Delete a configuration datastore (not applicable to running)
Lock and unlock <lock>, <unlock>
Short-lived lock and unlock of the configuration system of a device
Close and kill session <close-session>, <kill-session>
Graceful (close) or forced (kill) termination of a NETCONF session
From Screen-scraping to NETCONF
Example EEM/TCL snippet for getting info
show dhcp ipv4 proxy binding mac-address aaaa.bbbb.cccc What if we change this?
foreach line [split $cmdresult \n] {

if [regexp {^Access Interface:} $line] { Or this?
set access_if [ string range $line 29 end ]
}
if [regexp {^VLAN Id:} $line] {
set outer_vlan [ string range $line 29 end ]
}
if [regexp {^ReceivedRemote ID:} $line] {
set remote_id [ string range $line 29 end ] Or what if we move this?
}
if [regexp {^ReceivedCircuit ID:} $line] {
set circuit_id [ string range $line 29 end ]
}
if [regexp {^IP Address:} $line] {
set ce_ip [ string range $line 29 end ]
}
if [regexp {^MAC Address:} $line] {
set ce_mac [ string range $line 29 end ] And if we reformat this?
}
}
action_syslog priority info msg "DHCP Detail:#MAC:$ce_mac#IP:$ce_ip#ACCESS-
IF:$access_if#VLAN:vlan#Remote-ID:$remote_id#Circuit-ID:$circuit_id#PE-ID:$pe_id"
From Screen-scraping to NETCONF
The same data rendered in NETCONF/YANG Versioned
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2014-02-14T01:28:43UTC</eventTime>
<attachment-circuit-up xmlns="urn:cisco:params:xml:ns:yang:access-topology">
<attach-id>172.23.29.104:GigabitEthernet0/0/0/6.5:5</attach-id>
Modeled
<atp:information-source xmlns:atp="urn:cisco:params:xml:ns:yang:access-
topology">atp:ac-information-dhcp</atp:information-source>
<pe-id>172.23.29.104</pe-id> Self-Describing
<ce-id>
<ce-mac>00:11:00:ff:dd:02</ce-mac>
<ce-ip>192.168.5.128</ce-ip>
</ce-id>
<remote-id>0x00-06-50-17-ff-5b-ae-80</remote-id>
<circuit-id>0x00-04-00-05-01-05</circuit-id>
<vlan-stack>
<outer-vlan>5</outer-vlan>
</vlan-stack>
</attachment-circuit-up>
</notification>
RESTCONF
NETCONF with REST-flavor
IETF draft - draft-bierman-netconf-restconf-04
Use REST principles to get at device data
RPC etc.
Support for scoping and sub-tree filtering
2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential
Applications

API API API
Infrastructure
Functions
Functions Functions
OpFlex Control Protocol

API


OpFlex - Overview
Distributed control system based on a declarative policy information model.
Key components:
logically centralized policy repository (PR)
distributed policy elements (PE)
OpFlex Control protocol runs between PRs and PE
Communicate policy, events, statistics, and faults
JSON-XML (JSON-RFC 1.0, over TCP) or OpFlex-Binary-RPC as transport protocol
DevOps inspired Builds on Promise Theory (similar to Puppet, CFEngine):

PEs act as autonomous agents (pulling policy from PRs)
PEs retrieve an intent/a policy from the PR; In response promise to the PR to implement the intent
Policy is uncertain, or is considered to have a lifetime, hence is refreshed at regular intervals
(defined by the policy refresh rate)
No hierarchy assumed (peering-style protocol)
IETF Draft http://tools.ietf.org/html/draft-smith-opflex-00
OpFlex Architecture Key Components
Endpoint Registry
Store operational state of Endpoints Endpoint
Policy
Observer Registry
Observer Repository
(EPR)
Monitoring subsystem, system performance
Policy Repository
Source of all policies within a domain OpFlex Protocol
Policy Element
Logical functional abstractions of member Policy Policy Policy
elements (physical or virtual devices) Element Element Element
Renders policy to configuration of the
underlying subsystem
Continuous health and performance monitoring EndPoint EndPoint EndPoint
Administrative Domain
How OpFlex Works
A policy authority (e.g. APIC,

OpenDaylight Controller) Policy
manages a logical model of Repository
desired state
Policy Resolution Policy Update
Policy Element (Agent/Plugin) Subset of Policy

The policy endpoint interprets
the policy and maps it to its Device Render to configuration
hardware capabilities
Operating System
Device Config
(VLANs, Ports, )
OpFlex Control Protocol
RPC Methods
Identity: Identify the participant; Must be sent as the first protocol method "method": "resolve_policy"
"params": [
Policy Resolution: Retrieve policy associated with a given policy name
"subject": <string>
Policy Update: Communicate changed policy to elements that have "context": <string>
requested a particular policy before. prr parameter describes policy "policy_name": <string>
refresh rate. "on_behalf_of": <URI>
"data": <string> ]
Echo: Keep-alive "id": <nonnull-json-value>
Policy Resolution Request
Policy Trigger: Sent from PE to PE: Trigger policy resolution in target PE
Endpoint Declaration: Indicate attachment/detachment of an endpoint

"result": [
Endpoint Request: Query EPR for the registration of a particular EP "policy": <mo>+,
"prr": <integer>]
Endpoint Policy Update: EPR communicates a change relating to the "error": null
EP declaration for an EP PE has requested
"id": same "id" as request
Status Report: Provide fault, event, statistics, and health information Policy Resolution Response
from PE to Observer
OpFlex In The Context Of Open Source Community
Group Policy Model defined by Open Daylight community

Contributors
Group Policy API Group Policy API developed in OpenDaylight
OpFlex Protocol Plugin OpFlex Plugin and Reference Implementation in OpenDaylight
draft-smith-opflex OpFlex IETF Internet Draft
OpFlex Protocol Agent OpFlex agent created for Open vSwitch
See also: OpFlex Whitepaper


Centralized or Distributed Control?
Evolution Subsidiarity In Networking
Virtualization
Logically Centralized and Fully Distributed Control Tasks:
Controllers and Device-Plugins
Controller typical tasks Controllers
Gather, Analyze, Receive Requests
Promises to applications and agents
Analyze
Makes a decision and pushes it to the
agent(s); ephemeral and configuration data
Plugin/Agent typical tasks Gather Act
Act, Observe, Notify

Promises to the controller or other agents
Deployment dependent, Controller can delegate
rules to Agent to enable the Agent to take local Notify Observe
decisions
Plugin
Distributing Control
Tradeoffs
Control loop requirements differ per Logically centralized
(using Controller-Agent pairs)
function/service and deployment domain
As loose as possible, as tight as needed
Latency, Scalability, Robustness, Consistency,
Availability Deal with uncertainty Services-Plane
Different requirements per use case

Example: Control-Plane
Topology for Visualization (Network Management) vs.
Topology for Path-Computation/Routing
Data-Plane
The faster the speed, the larger the number of
elements to control, the harder for a centralized
element to keep its promises
Fully distributed
How to decide which functionality is well suited
a particular control paradigm? Note: Example only Not all network planes shown
Subsidiarity is an organizing principle that matters ought to be
handled by the smallest, lowest or least centralized competent
authority.
http://en.wikipedia.org/wiki/Subsidiarity
87
Decision making feedback loop

Considerations Applying Subsidiarity to Networking
Locations of event/state-source, state-processing, decision-making, action-
taking 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)
Evolving the Control Plane Environment
Deployment Considerations Applying Subsidiarity to Networking
fully distributed logically centralized
(on-box) (servers)
Small scale, rapid prototyping (TTM vs. performance)
Algorithms which require coordination between instances, benefit from a global view
Large scale tables with relatively infrequent updates (ARP,..)

Software/Algorithm for tightly coupled homogeneous environments (slow changes)
Dynamic environments with fast changes (differing views of state between observers)
Large scale design with scale across multiple dimensions (number, time, location..)
Rapid response to data-plane events / packet forwarding / topology changes
Simplicity of Control- and Data-Plane Integration*
* Past experience (e.g. PSTN AIN, Softswitches/IMS, SBC): CP/DP split requires complex protocols between CP and DP.
System Relationship Graph And Hierarchies
Hierarchy is just a specific spanning tree for a specific task/problem
Generic relationships Hierarchy for system load Hierarchy for application

(CPU) monitoring controlled flow steering
Legend: A: Application Node, C: Controller Node, D: Network Device (Router, Switch)

Software Architecture Perspective
Programmability needs to support hierarchical and peering models
Applications,
Applications Control Programs
Physical Controller
Device API
Controller
API
Virtual
Controller API
Device
Physical Virtual and Physical Devices
Device
Peering Model Hierarchical Model (used by SDN)

(East-West) (North South)
Applications

API API API
Infrastructure
Service
Functions Functions
Controllers Functions
API


Resource Orchestration and Control Software
Task Specific Solutions and Generic Controller Infrastructure
Session Border Wireless LAN Path Applications
Control Control Computation
Infrastructure Service Orchestration Management
SIP-proxy/ API API API API API API API API API
WLC PCE Ctrl. Ctrl. Ctrl. Ctrl. Ctrl. Ctrl. Ctrl. Ctrl. Ctrl.
SBC
SW SW SW SW SW SW SW SW SW
H.248 CAPWAP PCEP API

Elementary Infrastructure - Controller Layer
onePK PCEP OF I2RS BGP
SBC SBC SBC AP AP AP PCC PCC PCC

B2BUAB2BUA B2BUA
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 Controller-Plugin 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
EcoSystem of Network Software
Developer Focus: Consumable as a Software Platform
Applications and Frameworks
System Applications
API API API
Infrastructure Services Orchestration Management
Path-Comp. Server Orch. Appliances (p/v)
Placement Network Orch. Network (p/v)
Analytics Storage Orch. Servers
Identity Overlay/Chaining Storage
API
Elementary Infrastructure Functions Controller Layer
Device/Forwarding Device Mgmt/ Data/Event Network Security,

Programming Discovery Collection Database Policy
BGP I2RS PCEP onePK CLI OpenFlow CLI, other,..

EcoSystem of Network Software

End-User Focus: Turn-key Products/Application Suites
Applications and Frameworks
System Applications System Level Orchestration
Application Suite Application Suite Application Suite Application Suite

E.g. APIC-EM,.. E.g. WAE,.. E.g. APIC-DC,.. E.g. Network Management -
Cisco Prime,
API
Elementary Infrastructure Functions Controller Layer
Device/Forwarding Device Mgmt/ Data/Event Network
Security
Programming Discovery Collection Database
BGP I2RS PCEP onePK CLI OpenFlow CLI, other,..

Multi-Domain Resource & Service Orchestration
Data Center and/or Cloud WAN Campus
PE
Service PE
PE
Overlay
Network
(L2 or L3) PE
Un-Constrained
Un-Constrained
Constrained Bandwidth Bandwidth
Bandwidth
Un-Constrained Topology Partially Un-Constrained
Regular Topology
Topology
Multi-Domain Resource & Service Orchestration
Data Center and/or Cloud WAN Campus
PE
Service
Overlay PE
Network PE
(L2 or L3)
PE Workflow Management & Orchestration

APIC, ESP
ESP/WAE APIC EM Fixed & Wireless:
Elastic Services, Service Chains,
Traffic Optimization, Demand Engineering ZTD, QoS-Mgr, ACL-Mgr,
Fabric/Overlay Control
Controller-base Controller-base Controller-base
NfV: L2/L3 L2/L3 Overlay L2VPN/L3VPN L2/L3 Overlay L2VPN/L3VPN

vPE, N1kV, CSR, ..
Switching/Routing Edge/Core Routing Campus Routing/Switching
vASA, vNAM,..
Applications

API API API
Infrastructure
Controller Base-Layer Service
Functions
Functions
API
Functions
Open DayLight Controller Elementary Infrastructure Functions


Orchestration & Control: Components
Elementary Infrastructure Functions: Project OpenDaylight
Daylight is an open source project formed by industry leaders and others

under the Linux Foundation with the mutual goal of furthering the adoption
and innovation of Software Defined Networking (SDN) through the creation
of a common vendor supported framework.
OpenDaylight by the Numbers
Note: Statistics per May/15/2014

BRKRST-2051 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public Source: http://www.ohloh.net/p?ref=homepage&q=opendaylight
OpenDaylight Architecture
Projects in the Hydrogen Release (1.0)

Project Description Originator (others)
Controller Modular, extensible, scalable, and multi-protocol SDN controller based on OSGi Cisco
(IBM, RedHat, NEC, etc.)
Virtual Tenant Network Multi-tenant network virtualization application using OpenFlow NEC
YANG Tools Java-based NETCONF and YANG tooling for OpenDaylight projects Cisco
OpenFlow Protocol Library OF 1.3 protocol library implementation Pantheon
(IBM, Cisco, Ericsson)
OpenFlow Plugin Integration of OpenFlow protocol library in controller SAL Ericsson, IBM, Cisco
Affinity Metadata Service APIs to express workload relationships and service levels Plexxi
Defense4All DDoS detection and mitigation framework Radware

BGP-LS/PCEP Support for traffic engr with BGP-LS (BGP protocol library and topology model) Cisco
and PCEP (path programming model)
OVSDB OVSDB configuration and management protocol support (e.g., for Open vSwitch Univ. of Kentucky
and other OVSDB servers)
LISP Flow Mapping LISP (locator/identifier separation protocol) plugin, LISP mapping service (can be ConteXtream
used to implement virtual networks)
SNMP4SDN SNMP protocol support; APIs to manage commodity Ethernet switches Industrial Technology Research Inst.
Open DOVE Multi-tenant network virtualization based on overlays, including ctrl plane and IBM 102
OVS-based data plane
Model Driven Controller Architecture
Controller naturally exposes all APIs: Devices and Network APIs
Northbound API = SUM (Device APIs) + Controller-Services APIs
APIs Device, API

API API API API API
Network
Network, Services Policy
Inventory Topology Routing Device-ACL Device-QoS
User
Automatically generated APIs based on models

Network Network
Device, Network Inventory Topology Device-ACL Device-QoS

Policy Routing
Service Models Model Model Model Model
Model Model
Controller
Device models loaded into Controller
Device Device Device

Routing Device-ACL Device-QoS
Inventory Topology
Models Model Model Model
Device Model Model
OpenDaylight Architecture
Model Driven SAL
Applications
Northbound APIs (Generated & Handcrafted)
Network Service Platform Service Transformer/ Internal Plugin

Plugin Plugin Adapter
Java & REST SAL APIs (Generated)

Network
Abstraction
Layer NE NE NE
Topology
Tunnels
System Flows

Nodes Links
Stats Config
Table

Table
Stats
Config
Table
Table
Table
Paths
Flow Flow Flow Flow Flow Flow
Java SAL APIs (Generated)

SB Protocol OF-Config/OVSDB OF x.y PCEP BGP-LS
Network Elements
Policy Approach
Group policy for generic end points
Application-focused policy expressions:
Policies mirror application semantics. Capture policy
requirements without detailed knowledge of
networking.
Improved automation: Grouping constructs allow
higher level automation tools to easily manipulate
groups of network endpoints simultaneously.
Consistent policy by grouping end points and applying
policy to groups
Extensible because of implementation independence,
hence applicable to policy for connectivity, security,
L4-7, QoS, etc.
OpenDaylight Project
See also: https://wiki.opendaylight.org/view/Group_Policy:Main

Application Policy Plugin Architecture

Application Application Application
RESTCONF
Model Model Model Model Model
Forwarding
Endpoint Contract Affinity Inventory Rules
Registry Composer Service Manager
EP DB C DB Aff. DB IDB SAL
Model Model Model Model Model

Native Classic
Decomposer
Affinity
Decomposer
NETCONF CLI OF
Native Traditional Network Elements
Policy Primitives
Groups: Groups include sets of network
endpoints (potentially but not limited to
virtual machines) with the same policies
and requirements.
Policies: Policies consist of sets of rules
that govern how groups interact.
Policy rules: Rules capture specific
requirements about how groups interact.
For example, a policy rule may allow HTTP
traffic to a group of web servers for
example. While rules capture a specific
requirement, they must remain abstract
and not tied to a specific hardware or
software implementation.
Group-Based Policy in OpenStack Neutron
Objective: Extend OpenStack Neutrons networking model with new policy APIs (evolve from Layer 2
and Layer 3 behavior to a flexible and intuitive mechanism for describing networking requirements using
a language of groups and contracts
Openstack Sister-project to group based policy in OpenDaylight: Active participants include Big Switch
Networks, Cisco IBM, Juniper, Midokura, Nuage, One Convergence, Red Hat.
Delivery of Solutions Stacks to Solve Problems
Applications
Modules: Domain Functions, services or interfaces

specific app suites specific to a market segment or industry
Bundled
Common functions and services like
Solution
Controller Base inventory, topology, security
OpenDaylight Controller and
Enhancements
Infrastructure
OpenDaylight Controller - Enhanced
Commercial version of OpenDaylight Controller
Focused Apps Applications and Frameworks
Monitor Manager Resource Orchestration & Management
API API API
Transit Selection Infrastructure Services Orchestration Management
(Custom Routing)
Flexible Network Partitioning Transit Monitoring Slicing Trouble-
Shooting
and Provisioning (Slicing) Selection Manager Manager Manager
APIs
Controller Base:
https://developer.cisco.com/ OpenDaylight Controller +
Enhancements
site/networking/one/xnc/get-
started/index.gsp
onePK OpenFlow PCEP
Example: Monitor Manager Solution
Tools Production Network

With SDN Monitor Manager Solution
NEW CUSTOM
TOOLS
Optical
Taps
Wireshark Dynamic Filter and Forwarding

Event Driven / Real Time
Video Openflow Enabled

Monitor Nexus 3000s
Applications

API API API
Infrastructure
Domain Specific Modules Service
Functions
Functions
API
Functions
Data-Center Elementary Infrastructure Functions


Application Centric Infrastructure

Service graph abstraction from the network
Web App DB
QoS QoS QoS

Outside
(Tenant VRF) Filter Service Filter
Decouple Application from Infrastructure APIC
Application Policy
Infrastructure
Controller
ACI Fabric
Non-Blocking Penalty Free Overlay
Application Policy Infrastructure Controller (APIC)
Group-based Policy:Logically centralized
definition of application-centric network policies
(physical, virtual, cloud)
Fabric image management and inventory
Troubleshooting - Detailed visibility, telemetry,
and health scores by application and by tenant
Control of multi-tenant security, quality of
service (QoS), and high availability
Integration with management systems such as
VMware, Microsoft, and OpenStack
Extend the principle of Cisco UCS Manager
service profiles to the entire fabric
Control application only: No interaction with the
data-path on the switches. Fabric can still
forward traffic even when communication with
the Cisco APIC is lost.
ACI Network Profile

Policy-Based Fabric Management
Application
Group-policy based approach
Policies defined for End-Points (can be servers, Storage Storage
VMs, service nodes, virtual, physical various

identifiers) Web Tier App Tier DB Tier
Extend the principle of Cisco UCS Manager The network profile fully describes the application connectivity
service profiles to the entire fabric requirements
## Network Profile: Defines Application Level Metadata (Pseudo Code Example)
Network profile: stateless definition of
<Network-Profile = Production_Web>
application requirements <App-Tier = Web>
<Connected-To = Application_Client>
Application tiers, Connectivity policies, Layer 4 7 services <Connection-Policy = Secure_Firewall_External>
<Connected-To = Application_Tier>
XML/JSON schema
<Connection-Policy = Secure_Firewall_Internal & High_Priority>
...
Fully abstracted from the infrastructure <App-Tier = DataBase>
<Connected-To = Storage>
implementation <Connection-Policy = NFS_TCP & High_BW_Low_Latency>
...
Removes dependencies of the infrastructure
Portable across different data center fabrics
Inter-EPG Communication Example

Application Container Web Application Container "Database
Default Subnet Default

Subnet
Gateway Gateway
192.168.0.0/24 192.168.0.1 10.1.1.0/24 10.1.1.1
192.168.1.0/24 192.168.1.1
Policy Contract Web Database

Service Actions
TCP/23(Telnet) Deny
EPG EPG
TCP/22 (SSH) Allow
Web DB
Redirect to
TCP/1400
Web Database
Any Deny
Service Chain
Web DB
Applications

API API API
Infrastructure
Functions
Functions
API
Functions
Enterprise/Campus Elementary Infrastructure Functions


Enterprise/Campus Controller Overview
APIC-Enterprise Module (APIC-EM)
Enterprise specific set of
turn-key solutions, focusing
Ease of Operations / Simplicity
Consistent Network Behavior
Brownfield and Greenfield
Wired-Wireless
Application Visibility
and Control
Examples
Inventory/Topology:
Wireless-Wireline
Security (ACL, ThreatDefense)
QoS, ZTD
IWAN (PfR, ..)
Applications

API API API
Infrastructure
Functions
Functions
API
Functions
SP WAN-Controller Elementary Infrastructure Functions


SP WAN Orchestration
WAN Controller
Quantum WAVE Areas of Focus WAN
Optimization Automation Service

Enablement PE
Global & tactical Programmable Bandwidth PE

PE
policies TE/SR Tunnel + Calendaring
Demand Admission MATCH/Forward Customer Portal
Multi-layer policy routing (via Cross Domain
PE
coordination Openflow or onePK) Service
Improvement over Closed Loop Orchestration
sub-optimal head- enabled
end operations
WAN Control
Deployments typically combine Device-APIs, device delivered Network-APIs, and
controller delivered Network APIs for a particular solution
Example: Data-Center Interconnect L3 IP/MPLS Stateful PCE
across two providers with granular PCEP, OF, IRS, CLI
Demand Admission API
traffic forwarding control Device Control
Path/Demand
Placement Engine
Collector VNTM
Tunnel 1
BGP-LS, SNMP, OF, CLI, I2RS
Topology
Tunnel 2
Tunnel 1
GMPLS UNI
Optical Stateful PCE
Demand Admission API
TL1, I2RS, OF
Provider 1 Path/Demand
Datacenter 1 Datacenter 2 Device Control Placement Engine
Provider 2
Tunnel 2 VNTM
Collector
TL1, BGP-LS
WAN Automation Engine (a.k.a. WAN-Controller)
Apps
Application platform for MATE Bandwidth Tunnel DC-WAN
3rd Party
placing traffic demands and paths Design/Live Services Manager Orchestration
across an NGN WAN
Java/REST/Thrift NB API Java/REST/Thrift APIs
Integrates Cisco, open-source Visualization & Bandwidth
(OpenDaylight), and Cariden MATE

Analytics WAN- Orchestration
technologies Collector &

Controller
App Engine & Model Programming
BGP-LS, PCEP, NeXt UI, ODL, MATE Modeling
algorithms, etc.
Collector API Deployer API
Multi-vendor enabled & extensible
Collector Topo/Tunn API Deployer
BGP PCEP Netconf OF
Physical/Virtual Network Elements

Distributed Systems Control Theory Domain-specific Network
Architecture Evolution
Evolution
Virtualization
Re-assessing the Network Control Architecture
Evolving Design Constraints on the Control Plane
Generic Network Domain specific networks

Internet (DC, SP Access/Agg, Branch, ..)
Operate w/o communication guarantees Domain specific qualities of these networks

distributed system with arbitrary failures, relax or evolve network design constraints
nearly unbounded latency, Well defined topologies,
highly variable resources, little variety in network device-types,
unconstrained topologies no arbitrary changes in connected end-hosts, ..
Optimize for reliability *and* Optimized for reliability *and*

universal applicability domain specific performance metrics
Solutions for domains differ:
DC != WAN, TOR != PE
Domain-Specific Optimizations
Example: Leaf-Spine (fat-tree) Topologies In Application Centric Infrastructure
Reduce Broadcasts
Location-independent forwarding for L2 and L3
(e.g. directed ARP, no flooding)
Very Large Scale
Inline Hardware Mapping DB
1,000,000+ Hosts
Efficient Equal Cost Multipath
Focus on the Application Response Time;
Flowlet-Switching
Detailed Telemetry
Atomic Counters
Fabric Latency Measurements
Examples of Domain Specific Optimizations:

Large Scale: Large Lookup Tables, no Flooding
Leaf switch table: Address Leaf
Address_i Leaf_j
Split: Local and global part
Global Station Table Proxy Proxy Proxy
Global is a cached part of the contains a local cache A A B
entire global table of the fabric endpoints
Address Leaf Proxy Station Table
Fat-tree offers obvious default Address_x Leaf_y contains addresses
next hop of all hosts attached
* Proxy A to the fabric
Address Port
Scale to 1,000,000+ hosts Address_a Port_q
Local Station Table

contains addresses of
all hosts attached
directly to the Leaf

Large Scale: Efficient ARP
Gratuitous ARP and Gratuitous ARP and

Device Movement Device Movement
2
Leaf uses dest. IP 3
address in ARP ARP Frame Traffic to original Leaf ASIC forwards GARP packet
header to perform forwarded to VTEP destination is to Leaf which had the VM
VTEP lookup for destination end point bounced to new Leaf originally attached
forwarding
ARP Frame Host relocated

1 sourced to new leaf
from end
point
Efficient Equal Cost Multipath
Flow-based ECMP Flowlet* Switching Packet-based ECMP
d2
d1
Gap |d1 d2|
*Flowlet Switching (Kandula et al 04)


Telemetry / Detailed Traffic Statistics
Congestion Monitoring Atomic Counters
Update Performance Information at every hop Atomic Counters: Increment counters

Next packet sent back to the originating leaf with respect to the packet and not with
will carry with it feedback information on the respect to time
max load recorded on the ingress path Atomic Counters counted based on
identification of the packet

Distributed Systems Control Theory Virtualization
Evolution
Virtualization
Physical, Virtual, Cloud Evolution
PURPOSE COMMON VIRTUAL ELASTIC
BUILT HARDWARE MACHINES - NfV CLOUD
COMMON PLATFORM: Consistency of Policy, Features, Security, Management
HYPERVISOR
Platform
Hardware Software
Deployment HA
Redundancy Resiliency
Manual Automatic
BRKRST-2051 Evolve: Engineering, Operations, Architecture

2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 131
Network Function Virtualization
Movement of Network functions to the cloud
Control, services and data plane components ETSI NFV Architectural Framework
NFV is not applicable to all network applications

However most service functions are in the frame
High performance plumbing is not at the moment
NFV is an architecture rather than simply
virtualizing functions
Virtual services, compute
service chaining, overlays
Orchestration and redirection
Covered a number of use cases
See also: http://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.01.01_60/gs_NFV002v010101p.pdf
We have already been leading the way in terms of virtualizing many
capabilities. And there is a sample list here for all of you in terms of what
are the things that we have already virtualized. Everything from Nexus
1000V to cloud services router, to security appliances, to virtual wireless
LAN controllers, mobility services engine, identity services engine, prime
portfolio, as well as our Quantum portfolio, are essentially all virtualized
elements today that you can purchase and deploy.
Kelly Ahuja
SVP and GM, Mobility Business Group, Cisco
Physical and Virtualized Network Functions
Network Function Virtualization NFV: Examples
Nexus/Catalyst ASR/ISR/CRS Identity/Policy - ISE Firewall - ASA

vSwitch vRouter vFW
(Nexus 1000v) (CSR1000v) vISE (ASA 1000v)
WAAS Email Security - ESA Wireless LAN Controller Security Gateway
vWAAS vESA vWLC VSG
Network Analysis -
Video Cache Web Security - WSA IOS/XR RR
NAM
vVideoCache vWSA vNAM vRouteReflector
Service Provider Multi-Service Cloud
Network SLA, Cloud SLA, Service-Chaining - Combined
Multi-Service Cloud
SP OSS- Application Policy
Datacenter
Virtual Private Cloud
WAN Orchestration DC Orchestration
NfV Services
FW NAM IPS
DPI CPE WAAS
SP WAN SP DC GI-LAN | Consumer

FW CDN IPS
DPI CGN WWW
Guaranteed Network SLA Cloud SLA

Service and Dataplane Details:
Multi-Tenancy, Varied Topologies
DB WEB NAT
NAT
Bob Alice
SP WAN
(L3VPN,
L2VPN,
DCI
IPv4/v6,
Internet)
vPE-F L3 vPE-F L3 vPE-F L3 vPE-F L3

Server-3
Server-3
Server-3
Server-3
VM Alice VM Bob VM Alice VM Bob VM VM Bob VM VM Bob
NAT NAT FW FW Alice WEB Alice DB
Server 1 Server 2 Server 3 Server 4
Control Plane - Details
1 Application Service Policy / Specification
2
System Orchestration VM Orchestrator
SP WAN
(L3VPN, Service Address Management;
DCI Routing;
L2VPN, 7 5 Route 4 DHCP
DCI BGP
IPv4/v6, Provisioning
Internet)
3 Service VM management
Service
6 Configuration
vPE-F L3 vPE-F L3 vPE-F L3 vPE-F L3

Server-3
Server-3
Server-3
Server-3
VM Alice VM Bob VM Alice VM Bob VM VM Bob VM VM Bob
NAT NAT FW FW Alice WEB Alice DB
Server 1 Server 2 Server 3 Server 4
Service Provider Multi-Service Cloud
Build, Deliver, And Deploy Network, Storage, Compute
Cisco Modeling Labs
(a.k.a. Virtual Internet Routing Lab VIRL)
Cisco Modeling Labs is a multi-purpose
network virtualization platform
Brings virtual machines running Cisco
Network Operating Systems to the
customer
The same operating systems as used on
physical Cisco products: IOS, IOS-XR, NX-
OS
Virtual Machine orchestration

capabilities enables:
Creation of highly-accurate models of real-
world or future networks
scales to thousands of virtual network
devices
Developer Portal and Sandbox
DevNet and dCloud
developer.cisco.com dcloud.cisco.com
/dev/innovate: One Kit to Accelerate Innovation
Comprehensive product kit of hardware, software, use-cases and documentation,
coupled with technical support, community and business development resources
For Customers, Partners & Users;
Universities, Labs & More
Accelerates Innovation & New Solution
& Market Development at Low-Cost
(Low Risk)
New Cisco Solutions in Your Hands
Faster with support for Architecture,
Technology, Software & Business
Development
Innovation & Co-Creation with top Cisco
resources.
Faster Time-to-Market & Revenue
www.dev-innovate.com
Overlay and Transport Networks

Network Host Hybrid
Instance Scale
VM Mobility & LAN Extension
Agile Operations
Overlay Hypervisor-agnostic (ESX, HyperV, KVM, Xen,..)
Network / Host / Hybrid
NfV Service Chains
Service Placement / Topology
Multi-Segment Integration (DC-WAN)
OAM Correlate Overlay and Transport
Traffic Forwarding Control (Flow-Steering, Multicast)
Speeds & Feeds (e.g. low latency forwarding)
Fast Convergence (50ms), Segment Routing
Transport Statistics / Events (e.g. latency measurement)
Buffering / Scheduling / QoS
System resiliency
Example: Segment Routing
Evolving Forwarding Technology
Nodal Segment (NS) to C:
Application Enabled Forwarding Globally significant top
label defines destination NS to C
Scalable per-flow resource reservation
Efficient use of resources A B C D
(no per flow state in the network)

Virtualization Z
Leverage ISIS as Control Plane M N O P
Adj. Segment (AS):

Integrated with MPLS data-plane Label specifies link
Attain 50msec FRR service level Advertise labels via ISIS
guarantees Source Routing: Source computes path
potentially with help of central optimization
Attain MPLS scale, functionality, and Path is encoded by the source in the
performance packet header as a label stack
a path is an ordered list of segment
Each hop along the path forwards
See also: draft-previdi-filsfils-isis-segment-routing-00 according to classic MPLS data-plane
Correlating Overlay and Transport Network
C
F
B
E
A
BRKRST-2051
D
2014 Cisco and/or its affiliates. All rights reserved. Cisco Public
Correlating Overlay and Transport Network
C
F
B
E
A
BRKRST-2051
D
2014 Cisco and/or its affiliates. All rights reserved. Cisco Public
Example: Segment Routing & Tracing

Traffic Steering: Concept Outline
1 C 2
2
2
1
F
1 B
2
3
2
1
E
1
A3 2
1
BRKRST-2051
D
2014 Cisco and/or its affiliates. All rights reserved. Cisco Public See also: http://www.segment-routing.net/home/ietf
Applications

API API API
Infrastructure
Summary Service
Functions
Functions
API
Functions


Industry Standards & Forums & Initiatives
SDN WG
Open Network Research
802.1 Overlay Networking Projects Center at Stanford
University
Technical Advisory Group,
Open Daylight:
Working Groups:
ODL Controller
Config, Hybrid, Extensibility,
Futures/FPMOD/OF2.0
OpenStack:
Neutron (a.k.a. Quantum)
Open Source Cloud
Computing project
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 working group:
ETSI SGI on I2RS Interface to the Routing System
Network Function
Virtualization
The Customer Journey
Always On Demand
Seamless On Services Anywhere
Application
Experience Interaction
NAS
Accelerate New Services Business

Simplify/ Automate Applications Integration
Convergence / Consolidation Policy Control The network proactively adjusts to
Network Function Virtualization Bandwidth on Demand the application needs in real time
Service Chaining Security
Service Orchestration Data Recovery
A Few References
Cisco Application Centric Infrastructure www.cisco.com/go/aci
onePK - http://www.onepkdeveloper.com
EEM - https://supportforums.cisco.com/community/netpro/network-infrastructure/eem
ONE Forums - https://developer.cisco.com/site/devnet/forums/index.gsp#L2CiscoONE
XNC -
http://software.cisco.com/download/release.html?mdfid=285963706&softwareid=285978967&release=1.0.0&relind=AVAILABLE&re
llifecycle=&reltype=latest
APIC-EM - https://developer.cisco.com/site/networking/one/apic/enterprise-module/
APIC-DC
APIs - https://developer.cisco.com/site/networking/routers-switches/nexus9000/documents/
GitHub - https://github.com/datacenter/nexus9000
OpenDayLight
www.opendaylight.org
DevNet
developer.cisco.com
Related Sessions
May 19, 8:00-9:30 - BRKOPT-2102 - Software Innovations and Control Plane Evolution in the new SDN Transport Architectures
May 19, 10:00-12:00 - BRKRST-2117 - The Hitchhiker's Guide to onePK
May 19, 10:00-12:00 - BRKCRS-3011 - APIC-EM - SDN in the Enterprise
May 19, 13:00-15:00 - BRKSDN-1014 - Introduction to Software-Defined Networking (SDN) and Network Programmability
May 19, 13:00-15::00 - BRKNMS-3021 - Advanced Cisco IOS Device Instrumentation
May 20, 8:00-9:30 - BRKSDN-2777 - Open Network Environment (ONE) Software Development Lifecycle (SDLC)
May 20, 12:30-14:30 BRKPCS-2048 - Software-Defined Networking: People, Process, and Evolution
May 20, 12:30-14:30 - BRKRST-2051 - SDN From Concepts To Reality
May 21, 8:00-17:00 - LTRNMS-3601 Advanced Network Programming and Automation
May 22, 8:00-10:00 - BRKSPG-2722 - SDN deployment in ASR9000
May 22, 12:30-14:00 - BRKCRS-3090 - Implementing Network Programming and Automation
May 22, 14:30-16::00 - BRKCDN-2303 - DevOps in Programmable Network Environment
Participate in the My Favorite Speaker Contest
Promote Your Favorite Speaker and You Could be a Winner
Promote your favorite speaker through Twitter and you could win $200 of Cisco
Press products (@CiscoPress)
Send a tweet and include
Your favorite speakers Twitter handle @brockners
Two hashtags: #CLUS #MyFavoriteSpeaker
You can submit an entry for more than one of your favorite speakers
Dont forget to follow @CiscoLive and @CiscoPress
View the official rules at http://bit.ly/CLUSwin
Complete Your Online Session Evaluation
Give us your feedback and you
could win fabulous prizes. Winners
announced daily.
Complete your session evaluation
through the Cisco Live mobile app
or visit one of the interactive kiosks
located throughout the convention
center.
Dont forget: Cisco Live sessions will be available

for viewing on-demand after the event at
CiscoLive.com/Online
Continue Your Education
Demos in the Cisco Campus
Walk-in Self-Paced Labs
Table Topics
Meet the Engineer 1:1 meetings

SDN From Concept To Reality

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

SDN From Concept To Reality

Transféré par

Droits d'auteur :

Formats disponibles

SDN From Concept to Reality

Software Defined Networking (SDN) is a new approach to networking, complementing

open standard that enables researchers

Routing, access control, etc.

Global Network View

Federating different Network Control Points

Combined operations, developer and QA roles

Integrate: Simplify & Automate & Move Fast

Enable Cross-Layer Relations: Consistent Experience, Simpler Operations,

Enable Cross-Layer Relations:

Domain-specific Network Architecture

Scale-out, Fast & Flexible Deployments

Hybrid Control plane:

Resource Orchestration & Management

Physical and Virtual Infrastructure Embedded

Enable Cross-Layer Relations:

Mark Burgess, In Search of Certainty, July 2013

Deal with Uncertainty

Obligations represent strong couplings (hard dependencies) that make systems

Declarative programming is a programming paradigm which expresses what the program

Imperative vs. Declarative Example

for(var i = 0; i < numbers.length; i++) { var doubled = numbers.map(function(n) {

var newNumber = numbers[i] * 2 return n * 2

} console.log(doubled) //=> [2,4,6,8,10]

console.log(doubled) //=> [2,4,6,8,10]

Set indicator, pull clutch, Lets meet at Moscone,

Open World Assumption Closed World Assumption

Mark Burgess, April 2014

Enable Cross-Layer Relations:

App Fast App

Abstractions arent always generic

L2-Segments, L3-Segments, Service-Chains

Topology, Positioning, Analytics Positioning (ALTO)

L2/L3 Forwarding Control, Interfaces,

Device configuration, Life-Cycle

Choice of programmable layer

COMPREHENSIVE SERVICE SETS Data Path Policy Element Route

CONSISTENT PLATFORM SUPPORT

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

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

Discovery L2 topology (CDP/LLDP) and local service discovery

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

Network Wiring Verification (Python)

Network Configuration Automation w/ Puppet, Chef (Python)

Custom Encryption (C)

Mission Critical Application Monitoring & Analytics (by Starview)

Enabling security for classified information (by Pramacom)

GeoLocation Security Features for Router Management (by Glueware)

Mapping SAP HANA to network conditions (by SAP)

Load Balancer Management (by Citrix)

DDoS Protection as an SDN Network Service (by Arbor)

Extend Operate Configure

onePK SDK C, Java, Python NETCONF, REST, Puppet/Chef

Extend the functionality of the network Provisioning/Configuration/Operations

C Java Python Netconf REST

Auto-generated bindings from data models

Data-Model to Feature Wiring

Model Driven Architecture

Data model structure

Resource Orchestration & Management

Elementary Infrastructure Functions

Platform APIs and Plugins

Physical and Virtual Infrastructure