software defined networks and openflow

© 2012 Cisco and/or its affiliates. All rights reserved. BRKRST-2051 Cisco Public

Software Defined Networks and OpenFlow BRKRST-2051 Frank Brockners

2


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.

3


“…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…”

4

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.openflow.org/wp/learnmore/


“A pla'orm for developing new control planes” “An open solu8on for VM

mobility in the Data-‐Center”

“An open solu8on for customized flow forwarding control in and between Data Centers”

“A means to do traffic engineering without MPLS”

“A way to scale my

firewalls and load

balancers”

“A solu8on to build a very large scale layer-‐2 network”

“A way to build my own security/encryp8on solu8on”

“A way to reduce the CAPEX of my network

and leverage commodity switches”

“A way to op8mize broadcast TV delivery by op8mizing cache placement and

cache selec8on”

“A means to scale my fixed/mobile gateways and op8mize

their placement”

“A solu8on to build virtual topologies with op8mum mul8cast

forwarding behavior”

“A way to op8mize link u8liza8on in my network enhanced, applica8on driven rou8ng”

“A means to get assured quality of experience for

my cloud service offerings”

“A way to distribute policy/intent, e.g. for DDoS preven8on, in the network” “A way to configure my en8re network as

a whole rather than individual devices” “A solu8on to get a global view of the

network – topology and state”

“Develop solu8ons at soTware speeds: I don’t want to work with my network vendor or go through

lengthy standardiza8on.”

Simplified Opera?ons – Enhanced Agility – New Business Opportuni?es

“A solu8on to automated network configura8on and control”


Classes of Use-Cases “Leveraging APIs and logically centralized control plane components”

Custom Routing (incl. business logic) Online Traffic Engineering

Consistent Network Policy, Security, Thread Mitigation

Custom Traffic Processing (Analytics, Encryption)

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)


Edge

Core Mobile

CPE

Appliance

Service

Service Service

Service

Towards Programmatic Interfaces to the Network Approaching Today’s Application Developer Dilemma

7

  Many Network Applications today: •  OTT – for speed and agility

•  Avoid network interaction – complex and slow innovation

  New Model for Network Applications •  Keep speed and agility •  Full-‐duplex interac?on with the network across mul?ple planes – extract, control, leverage network state

A New Programming Paradigm is Needed

CLI(s)

“Fast” App App

“Slo

w” “N

ew”


Re-assessing the Network Control Architecture

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

Evolving Design Constraints on the Control Plane

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


Towards the Open Network Environment for SDN

  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

Implementation Perspective: Evolve the Control-Plane Architecture

Tradi?onal Control Plane Architecture

Control Plane Architecture with SDN (Examples)

Control-‐plane component(s) Data-‐plane component(s)

…


Resource Orchestration & Analytics “Network Middleware”

Server

Server

Server

Server

Open Network Environment Approaching a Definition

physical

virtual

virtual virtual

virtual

physical

physical

physical

Programmatic Interfaces

API

API API

Integrated Physical & Virtual Infrastructure

API

API

Cisco Confiden?al


Resource Orchestration & Analytics “Network Middleware”

Programmatic Interfaces

Open Network Environment Approaching a Definition

“Controllers and Agents”

“Virtual Overlays”

“Platform APIs”

Cisco Confiden?al

Integrated Physical & Virtual Infrastructure


Open Network Environment   Open Network Environment – Complementing

the Intelligent Network ‒ Preserve what is working:

Resiliency, Scale and Security, Comprehensive feature-set

‒ Evolve for Emerging Requirements: Operational Simplicity, Programmability, Application-awareness

  The Open Network Environment integrates with existing infrastructure ‒ Software Defined Network concepts are a

component of the Open Network Environment ‒ The OpenFlow protocol can be used to link agents and

controllers, and as such is component of SDN as well

Simplified Opera?ons

Enhanced Agility Network Mone?za?on

Network Virtualiza<on Infrastructure

Resource Orchestra<on -‐ Agents and Controllers

Open Network Environment

Programma<c APIs


Programmatic Network Access – Multiple Layers

  Enable a holistic Network Programming model

  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

Full-Duplex access to the network at multiple layers and networking planes

13

Forwarding

Control

Network Service

Management

Orchestra?on

Transport/Device

Applica?ons/Developm. Applica8on development frameworks, e.g. Spring,…

Programma8c network automa8on, e.g. Cisco Pulse,..

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

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

Device configura8on, state monitoring, logging, debugging

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

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

Harvest Network

Intelligence

Program for Op8mized Experience

“SDN”

“ONE”

Open Network Environment Qualities Programmatic APIs

Programma?c APIs

Resource Orchestra?on

Network Infrastructure Virtualiza?on


The Need for Abstractions

  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 Internet’s success

  Abstractions for the other planes (control, services, management, orchestration,..) … are missing

Consequences include: Notorious difficulty of e.g. network management solutions

Difficulty of evolving software for these planes

Abstractions in Networking

“Modularity based on abstrac8on is the way

things get done”

Barbara Liskov Turing Award Winner


“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.”

16

h&p://en.wikipedia.org/wiki/Abstrac?on_Computer_Science


Approaching abstractions for Networking

  Abstractions allow the definition of associated APIs ‒ Enable API platform kit across all

platforms, to integrate with development environments

‒ 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.. 17

Device focused abstrac?ons Service/Network focused abstrac?ons

Device Capabili?es Debugging Diagnos?c

Events

Network Topology

Service Path

Network Stats

Service Placement

Interface, Tunnel

Data-‐Path/ Packet Access

Service Discovery Rou?ng

Addressing/ Mapping

Neighbor Discovery

Forwarding Policy, QoS

Tenant Provisioning

Security Thread Control

Segment Federa?on Authen?ca?on

Tenant Control


APIs make Abstractions available to Programmers Example: Cisco’s onePK (one Programming Kit) – Get your build on!

Any Cisco Router or Switch

Applica?ons That YOU Create

onePK

Flexible development environment to: •  Innovate

•  Extend

•  Automate

•  Customize

•  Enhance

•  Modify

Cisco Confiden?al


Evolu?on Tradi?onal Approach

Evolving How We Interact With The Network Operating System

App C

Java …

IOS

Events

App EEM (TCL) Ac?ons

Rou?ng

Data Plane

Policy

Interface

Monitoring

Discovery

CLI

AAA

SNMP

HTML

XML

Syslog

Span

Neglow

CDP

Rou?ng Protocols Anything you

can th

ink of

Cisco Confiden?al


onePK Architecture

C, JAVA Program

onePK API Presentation

onePK API Infrastructure

IOS / XE (Catalyst, ISR, ASR1K)

NXOS (Nexus Platforms)

IOS XR (ASR 9K, CRS)

Cisco Confiden?al


Process Hos?ng

Write Once, Run Anywhere

onePK Application Hosting Options

Blade Hos?ng End-‐Point Hos?ng

Container

onePK Apps

Network OS

Blade onePK

Apps External

Server

Network OS

Container

Network OS

onePK Apps


onePK APIs are Grouped in Service Sets

Cisco Confiden?al

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, next-hop info, etc.)

Developer Debug capability, CLI extension which allows application to extend/integrate application’s CLIs with network element


Yes, it is secure Security Five Ways

App Security

Admin Security

Container Security

Runtime Security

Code Security

Digital Signing Certification Process

CLI Control Resource Allocation

Isolation Resource Consumption

Code Isolation Strong Typing

AAA (PKI) Encryption (TLS)

Cisco Confiden?al


Not all Networking APIs are created the same Classes of Networking APIs following their Scope

24

  Classify Networking APIs based on their scope ‒  API Scopes:

Location independent; Area; Particular place; Specific device

‒  Alternate approaches like device/network/service APIs difficult to associate with use cases

‒  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

U?lity

Area/Set

Place in the Network

Element

Example: Get Auth, Publish Log,.. Scope: Loca?on independent

Example: Domain, OSPF-‐area,.. Scope: Group/Set/Area

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

Example: interface sta?s?cs Scope: Specific element


APIs at work – Element APIs

  Objective: ‒ Provide operators/

administrators/ support engineers with details about how packets flow through the network.

‒ Reveal network issues

  Approach ‒ NMS application leverages

onePK APIs to show path of flow, timestamp, ingress/egress interfaces, interface packet counts

Example: Statistics, Diagnostics & Troubleshooting

25

onePK

Applica?on using onePK

Flow Switching Details Start Trace

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


APIs at work – Place in the Network APIs Example: Dynamic Bandwidth/QoS Allocation

26

Ingress PE Egress PE

SP Network

Policy Server

1 2 2

3

  Business Problem ‒  Enable superior experience for

subscribers which access a particular cloud service

  Solution ‒  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 Subscriber-Gateway (BRAS/BNG, GGSN/PGW, ..) only

Common API like onePK enables control points on all key networking devices

Request premium service

Install customer policy on all key network elements

Customer traffic is gelng superior/specific treatment

Cloud Services


APIs at work – Area APIs

  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 ‒  Custom route application built

and deployed using onePK, communicating directly with the forwarding plane.

‒  Unique data forwarding algorithm highly optimized for the network operator’s application.

Example: Custom Routing

27

Data Center A

Secure Communica?ons Channel

Custom rou?ng applica?on hosted on a server, communicates securely with onePK infrastructure to route specific packets according to a custom policy.

Select packets take a custom policy-‐based route

Data Center B

App

API presenta?on layer


APIs at work – Area APIs

  Business Problem ‒  Several problems require a view of the

network topology (area, domain, or whole network)

‒  Examples: Locate optimal service out of a given list

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)

Examples: Topology graph

28

Topology API

Topology Visualiza?on

Hadoop Op?miza?on

Network Posi?oning System


Example: Custom Routing Data Center Traffic Forwarding Based on a Custom Algorithm

onePK Custom Rou?ng Applica?on

Unique Data Forwarding Algorithm Highly Optimized for the Network Operator’s Application

Topology

Discovery

Business Data & Logic


onePK and Agent Framework Enabling specific solutions/protocols (OpenFlow, IRS,…) on top of onePK

IOS / XE NX-OS IOS-XR

onePK APIs Presentation

onePK API Infrastructure

Agent Framework

Agent Implementation (e.g. OpenFlow)

Application Framework / Controller Agent Communication

Component

Solu?on defined protocol (e.g. OpenFlow)

Cisco Confiden?al

Open Network Environment Qualities Programmatic APIs ONF’s OpenFlow Protocol

Programma?c APIs




OpenFlow

  Original Motivation ‒ Research community’s 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


Nothing new under the sun

  Ipsilon Flow Switching Centralized flow based control, ATM link layer

GSMP (RFC 3292)

  AT&T “SDN” Centralized control and provisioning of SDH/TDM

networks

  A similar thing happened in TDM voice to VOIP transition

Softswitch Controller

Media gateway Switch

H.248 Device interface

Starting point of Data-Plane Abstraction & Data- and Control Plane separation isn’t new

33

  IETF ForCES WG Separation of control and data planes

RFC 3746 (and many others)

  GMPLS, MPLS-TP   PBB-TE   Multiple Cisco product examples, e.g.

Wireless LAN Controller (WLC) – APs

Nexus 1000V (VSM – VEM)

Remember RSM (7200 on a stick with Catalyst 5000 as dataplane)?


OpenFlow

  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

Basics

34

* TLS, TCP – OF 1.3.0 introduces auxiliary connec?ons, which can use TCP, TLS, DTLS, or UDP.

Source: OpenFlow 1.3.0 specifica?on, figure 1


OF Processing Pipeline

35

Table 0 Table 1 Table n Execute Ac?on Set

Ingress Port Packet+ Ingress Port + Metadata

Ac?on Set {} Ac?on Set

… Packet

Ac?on Set

Packet IN Packet OUT

Packet IN Packet OUT

Packet DROP

CONTROLLER

Single Table

OF 1.1 and beyond model (mul?ple lookups)

OF 1.0 model (single lookup)



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)

36


Packet Flow through an OpenFlow Switch

37



Required Match Fields

38

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


OF Match Fields

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

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

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

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

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

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

  OFPXMT_OFB_VLAN_VID = 6, /* VLAN id. */

  OFPXMT_OFB_VLAN_PCP = 7, /* VLAN priority. */

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

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

  OFPXMT_OFB_IP_PROTO = 10, /* IP protocol. */

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

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

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

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

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

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

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

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

  OFPXMT_OFB_ICMPV4_TYPE = 19, /* ICMP type. */

  OFPXMT_OFB_ICMPV4_CODE = 20, /* ICMP code. */

  OFPXMT_OFB_ARP_OP = 21, /* ARP opcode. */

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

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

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

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

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

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

  OFPXMT_OFB_IPV6_FLABEL = 28, /* IPv6 Flow Label */

  OFPXMT_OFB_ICMPV6_TYPE = 29, /* ICMPv6 type. */

  OFPXMT_OFB_ICMPV6_CODE = 30, /* ICMPv6 code. */

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

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

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

  OFPXMT_OFB_MPLS_LABEL = 34, /* MPLS label. */

  OFPXMT_OFB_MPLS_TC = 35, /* MPLS TC. */

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

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

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

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

39


OpenFlow Actions

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

40

*Op?onal


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

Physical Ports, Logical Ports, Reserved Ports

41

* Op?onal


OpenFlow Ports Simplified View

42

CONTROLLER “port”

Physical Port

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

LOCAL “Port”

NORMAL “Port”

TABLE IN_PORT

“Classic Switch part”

Logical Port (represen?ng a VLAN) “OF-‐Switch

part” Logical Port (represen?ng a VLAN)


OpenFlow Ports

  CONTROLLER ‒ Forward packets to Controller ‒ For “reactive” mode of operation ‒ Considerations

Latency for decision making

Bandwidth between OF-switch and OF-controller

Speed at which rules can be installed/removed

  NORMAL ‒ 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 meta-data from OF, or rely on classic routing protocol)?

43

CONTROLLER port and NORMAL “port”


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


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


Programmable Service Chains

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

Fine vs. Coarse Grained Flows Filtering vs. Routing Placement vs. Topology Addressing vs. Flows

  Additional Use Cases to be considered ‒ CDN, Optical xconnect,…

e2e: client-server, peer-to-peer

in-line service

endpoint service

in-line service chain


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”


Hybrid Switch: Ships in the Night vs. Integrated

Router Router

OpenFlow Control Plane

“Ships-‐in-‐the-‐Night”

•  A subset of ports controlled by OF, another subset controlled by router’s na?ve CP – physical resources are par??oned

•  Some level of integra?on: “OF_NORMAL”: •  Implementer free to define what “normal” is • May or may not be what router normally does

Control Plane

OpenFlow

“Integrated”

•  Use OF for feature defini?on – augment the na?ve control plane

•  No longer par??oning of resources •  Can operate at different abstrac?on levels (low-‐level like OF1.0 or higher level)


OpenFlow Versions Status

49

Dec 31, 2009

OF 1.0

Feb 28, 2011

OF 1.1 OF 1.2 OF 1.3.0

Dec 5, 2011 April 19, 2012

•  Single Table •  L2, IPv4 focused matching

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

source implementations”; ONF board encourages multiple reference implementations


OpenFlow Evolution

  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

Making OF functionally complete


OpenFlow Evolution Challenge Device Model: Getting the right abstraction is hard

Packet Filtering Basic sta?s?cs

Device capability exchange

Encapsula?on Control QoS Control

Packet Forwarding Control – Exact match lookup Packet Forwarding Control – LPM lookup

Example Device Models

“Future” / “hybrid” OpenFlow versions?

“Forwarder, Exact match lookup”

“Forwarder, Longest

prefix match lookup”

“Generic Forwarder”

“Forwarder with Packet Queuing/ QoS”

“Switch/ Router”

“VPN Switch/ Router”

Network Graph Traversal / Rou?ng

Address Transla?on

Mobility

Enhanced Traffic/Event repor?ng

Loca?on-‐based Services

Traffic Op?miza?on (WAAS,..)

Network Virtualiza?on/Topology Control Iden?ty

Security (Firewall,..)

OpenFlow 1.2/1.3 OpenFlow 1.1

…

Model complexity increases with set of use-‐cases/solu?ons covered

Open Network Environment Qualities Programmatic APIs IETF’s Interface to the Routing System (IRS)

Programma?c APIs




Towards the “Interface to the Routing System”

  Dynamically augment the Routing System / Control Plane based on

Policy

Flow & Application Awareness

Time & External Changes

  Leverage Topology (active & potential)

Events

Traffic Measurements

…

Approach

53

Feedback Loop: Control & Informa?on

Measure/ Analy?cs

Program


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)

54


IRS Framework

55

Application

IRS Client

IRS Agent

Policy Database

Subscription and Configuration Templates for

Measurement, Events, QoS, etc…

Routing and Signaling Protocols

Topology Database

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


IRS - Key Aspects & Anticipated Features

  Multiple Simultaneous Asynchronous Operations

  Configuration Not Re-Processed   Duplex Communication   High-Throughput   Highly Responsive   Multi-Channel (readers/writers)   Capabilities Negotiation/Advertisement

(self-describing)

  Installed State can have different lifetime models: ‒  Ephemeral (until reboot)

‒  Persistent

‒  Time-based Persistent: Expires after specified time

‒  Time-based Ephemeral: Expires after specified time

  Operations to install state have different install-time models: ‒  Immediately

‒  Time-Based

‒  Triggered by an Event

56

Open Network Environment Qualities Resource Orchestration/Controllers: Logically centralized and fully distributed Control

Programma?c APIs




Orchestration: Agents and Controllers

  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

  Controller

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

‒  Offer a control interface/API

  Agent

‒  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

Consolidate State Across Multiple Network Elements Controller Agent

APIs Agent APIs

Agent APIs

Agent APIs

APIs

Analyze

Act

Observe Notify

Gather

Controller

Agent


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 ‒ Different requirements per use case

Example: Topology for Visualization (Network Management) vs. Topology for Path-Computation/Routing

  How to decide which functionality is well suited a particular control paradigm?

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

59

Fully distributed

Logically centralized (using Controller-‐Agent pairs)

Data-‐Plane

Control-‐Plane

Services-‐Plane

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

60

h&p://en.wikipedia.org/wiki/Subsidiarity


Decision making feedback loop   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)

Considerations – Applying Subsidiarity to Networking

61


** Past experience (e.g. PSTN AIN, Sowswitches/IMS, SBC): CP/DP split requires complex protocols between CP and DP.

* See also: Mar?n Casado’s Blog: h&p://networkheresy.wordpress.com/2011/11/17/is-‐openflowsdn-‐good-‐at-‐forwarding/

logically centralized (servers)

fully distributed (“on-‐box”)

Rapid prototyping (TTM vs. performance)

Algorithms which require coordina?on between instances, benefit 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: Efficient “plain vanilla” Layer-‐3-‐style forwarding

Rapid response to data-‐plane events / packet forwarding

Simplicity of Control-‐ and Data-‐Plane Integra?on**

Evolving the Control Plane Environment Deployment Considerations – Applying Subsidiarity to Networking


Considerations for Control-Plane Evolution Decision making feedback loops – Example: Packet forwarding control

63

E.g. Link state change

E.g. Route computa8on

E.g. FIB programming E.g. Topology computa8on

Event/State Source

Decision Making

Ac?on Taking

State Distribu?on E.g. Link state distribu8on

State Processing


Packet Forwarding Decision Making

  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)

How much buffer do you have?

Drop the packet

Flood the packet

An obvious observation

64

Interframe Gap (IFG)

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


Forwarding decision making

  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)

Pro-Active and Re-Active Mode

65


Reactive Mode: Considerations

  Decision making delay and associated buffering requirements

  Flow-setup / Flow-teardown latency

  Scale ‒ Bandwidth/packet forwarding

requirements between forwarding entity and decision making entity

‒ Total number of flows, feasibility of rule aggregation

66

Forwarding

Decision Making

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

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

How quickly can you program the forwarding hardware? -‐ Large scale applica8ons -‐ Failure scenarios


Consistency and Availability

  Consistency and Availability Trade-off ‒ Typical databases are better at Consistency than

Availability, wide area databases cannot have both ‒ Trade-off typically domain specific

  Trade-off between concurrency, performance and consistency ‒ Strict consistency can come at cost in update/read

latency and lower throughput ‒ Trade-off typically domain specific

  Classic network protocols ‒ Designed for eventual consistency and partial failure;

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

New Trade-offs in specific/constrained domains?

67

Availability

Tolerance to network

Partitions

Consistency

“CAP Theorem”: You can have at most two of these proper?es for any shared data system

(Eric Brewer, UC Berkeley)


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

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

69

Open Network Environment Qualities Resource Orchestration/Controllers

Programma?c APIs




Orchestration: Controllers and Agents

  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

Task Specific Solutions and Generic Controller Infrastructure

Session Border Control

Wireless LAN Control

Path Computa<on

SIP-‐proxy/ SBC WLC

AP AP AP PCC PCC PCC

PCE

H.248 CAPWAP PCEP

Generic Controller Infrastructure

SBC B2BUA

SBC B2BUA

SBC B2BUA onePK

OF-‐Agent OF-‐Agent OF-‐Agent onePK onePK

App App App Control Programs leveraging the ONE Controller

ONE Controller


Controllers as Aggregation and Decision Points

  Computes the location of and distance between endpoints

‒  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

Example: Network Positioning System (NPS)

Network Unaware

Overlay-underlay Topology Correlation

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 )


Example: NPS

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

‒  Simple location & distance request by application to network

  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

ALTO as the API

73

Network Topology Rou?ng

Service Loca?on, Network Posi?oning

Server

Geo-‐ Loca?on

Perform-‐ ance

Policy

ALTO

P2P Swarms

OTT Overlay

Cloud *aaS

CDN

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

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

Network Devices


Orchestration   Take request to provide services to a

given Cloud Service   Control Traffic Routing traffic from Edge

to DC   Provision and manage

services in the DC

Service Cross-Connect – Network-Ramp to Cloud Services

Traffic flow Service

Services Cross Connect

Service Request

SP Network Data Center


Orchestration

  Route Traffic from Edge router into a DC switch

  Load Balance across a set of service instances

  Add more service instances when needed   Remove services when not needed

Elastic DC Services

Traffic flow Load Balancer

Service

Service

Service

Service

Service

Data Center

Services Controller Load Controller VM Controller

Load Monitor

SP Network


Complementing classic VPN technologies

  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

Network Partitioning, a.k.a. “Slicing”

76


Orchestration & Virtualization: Network Partitioning Example: Network Slicing for Research Environments

77

Slice 1: Classic Control Plane

Slice 2: Research team B

Slice 3: Research team A

Define Network Par??ons/Slices

Network Administrator

Research team A Research team B

Control Program/ Manager A

Control Program/ Manager B

Network Slicing Manager

  Business Problem ‒  University desires to “slice” the

network into multiple partitions: Production network – classic control

plane

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

  Solution ‒  Network Slicing Manager

partitions the network based on e.g. ports or VLANs

Provides northbound interfaces, incl. OpenFlow (Flowvisor-like)

Effects of a particular control function of a partition/slice limited to that partition/slice


Devices, Controllers – and APIs

  APIs represent abstractions at different layers – complementing each other ‒ 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

78

Service Path

Service Placement

Packet Data-‐Path Access

Network Topology

Forwarding Policy, QoS

Example abstrac8ons and associated APIs delivered through controllers

Example abstrac8ons delivered by individual device

API API

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

API API API Common consistent set of APIs


Orchestration & Control Cisco “ONE Controller”

79

OpenFlow 1.x Protocol onePK API

Flow Management Forwarding Logic Device Management

Network Slicing

Applications (Cisco) Applications (Customer) Applications (3rd party)

Northbound API

Controller built-‐in Applica8ons

Built-‐in

GUI for M

anagem

ent

Apps/Applica8ons

Network Troubleshooting

Controller Core Infrastructure

Southbound APIs (onePK, OneFlow,…)

Custom Routing

onePK onePK OpenFlow OpenFlow

…

  Platform for generic control functions – state consolidation across multiple entities

  Current Showcase Examples ‒ Flexible Network

Partitioning and Provisioning (“Slicing”)

‒ Network Troubleshooting ‒ Custom Routing

  Java-based


Orchestration & Path Computation

Example: Data-Center Interconnect across two providers with granular traffic forwarding control

Device Control

Provider 1

Provider 2 Datacenter 1 Datacenter 2

Tunnel 2

Tunnel 1

Tunnel 1

Tunnel 2

VNTM

Demand Admission API L3 IP/MPLS Stateful PCE

Collector

Path/Demand Placement Engine

BGP-‐LS, SNMP, OF, CLI, IRS

PCEP, OF, IRS, CLI

Device Control

VNTM

Demand Admission API Op<cal Stateful PCE

Collector

Path/Demand Placement Engine

TL1, BGP-‐LS

TL1, IRS, OF

GMPLS UNI

Topology

Deployments typically combine Device-APIs, device delivered Network-APIs, and controller delivered Network APIs for a particular solution


Orchestration Multi-Layer PCE with iOverlay

DWDM

IP/MPLS

Services

Service Tunnel

Fiber

λ

λ

λ

Fiber

Link

Tunnel Tunnel

Tunnel

Service Tunnel

ML-PCE DWDM Topology

(BGP-LS)

Setup λ’s (PCEP)

Setup Tunnels (PCEP)

L3 Link Topology (BGP-LS)

Service XCON

Setup Service Instances

Discovery, Status iOverlay


Example: Topology Exposure: Multi-Area IGP

  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

ALTO server exposes multi-area IGP topology

82


Full-Duplex Access across all Network Planes Example: SP Network Model and Technology Context

83

DC/Cloud

Wavelengths – Transport Topologies

IP/MPLS tunnels – Layer-‐3 Topologies

Service Wires – Service Chains/Topologies

Topologies, Sta?s?cs

Paths, Tunnels

NPS CDNI Mul?-‐Layer PCE, iOverlay

Service Control and Admin

Service Orchestra?on

•  Stateful PCEP: e.g. draw-‐crabbe-‐pce-‐stateful-‐pce •  NPS/ALTO: e.g. draw-‐ieg-‐alto-‐protocol •  CDN Internconec?on

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

•  virtual Service Appliances/Gateways •  Service Chaining, vPath •  OF-‐Hybrid devices

•  onePK APIs •  Protocols: NetConf/YANG, NetFlow, PCEP, Diameter, OF, … •  Topology exposure, e.g. BGP-‐LS

Examples of evolving technologies:

Open Network Environment Qualities Network Infrastructure Virtualization

Programma?c APIs




“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.”

85

h&p://en.wikipedia.org/wiki/Virtualiza?on


Network Abstractions support Virtualization

  Virtual Overlay Networks ‒ custom endpoint addressing

(e.g. for simple endpoint mobility) ‒ custom topologies/segmentation ‒ custom service chains

Example: vPATH

  Virtual Service Appliances/Gateways ‒ VSG, vWAAS

Blurring the lines between physical and virtual entities – networks and services

86

Map ‘n Encap approaches to allow for flexible 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

Common Abstractions and common APIs across physical and virtual network elements


Virtual Overlay Networks

  Large scale L2 domains: Tens of thousands of virtual ports

  Common APIs ‒  Incl. OpenStack Quantum API’s

for orchestration

  Scalable DC segmentation and addressing ‒  VXLAN

  Virtual service appliances and service chaining/traffic steering ‒  VSG (cloud-ready security), vWAAS (application acceleration), vPATH

  Multi-hypervisor platform support: ESX, Hyper-V, OpenSource Hypervisors   Physical and Virtual: VXLAN to VLAN Gateway

Example: Virtual Overlay Networks and Services with Nexus 1000V

87

Nexus 1000V

OpenStack Quantum API REST API

Any Hypervisor

Tenant 1

Virtual Services

vWAAS

VSG ASA 1KV

Tenant 3

ASA 55xx

Physical Workloads

Physical (VLAN) Network

VXLAN Gateway

Virtual Workloads

Tenant 2


Cloud technology stacks Multi-Hypervisor and Multi-Orchestration Strategy

Physical Network

vSphere Hyper-V Open Source (Xen, KVM)

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

UCS Compu<ng PlaUorm

Hypervisor vSphere, Hyper-V,

Xen, KVM

vCloud Director/

DynamicOps

System Center

Open Source

Cloud Portal and Orchestra<on

Storage PlaUorm

CIAC/ OpenStack/

Partners

Virtual Network Infrastructure

NSM/VNMC/ ONE Controller

ASA 1KV vWAAS

CSR 1KV

Nexus 1KV

ONE Controller/NSM

ASA 1KV vWAAS

CSR 1KV

Nexus 1KV

ONE Controller/NSM

ASA 1KV vWAAS

CSR 1KV

Nexus 1KV

ONE Controller/NSM

ASA 1KV vWAAS

CSR 1KV

Nexus 1KV vPath vPath vPath vPath

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

Man

agem

ent

Open Network Environments and Software Defined Networks


Summary: Open Network Environment Leverage Network Value

Network Services

Analy<cs Orchestration

Programm

ability

Inte

lligen

ce

Program for Op<mized Experience

Harvest Network

Intelligence


Some History…

  Define target distribution architecture upfront ‒ Assume that suitable

abstractions can be found

  Approach ‒ Data-plane abstraction as

starting point ‒ Network global view/state

abstraction (semantic free) ‒ Control-programs (deal

with task-specific semantics)

The early SDN architecture approach

91

Nypervisor

Abstract Network View

Global Network View

Network Operating System

Control Program

Picture courtesy Sco& Shenker


Observations on early SDN architecture view

  Finding the right (set of) device abstraction is hard ‒  Too simple and you can’t control important switch features, too complex and it becomes un-

implementable

‒  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 chicken-and-egg situation)

92


Defining Generic Abstractions is Hard

  Network visualization ‒  Loose timing and accuracy requirements

  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)

‒  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

Example: Network Graph Abstraction Layer

93

Accuracy/Consistency

Availability Performance

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


API infrastructure

Evolve the early SDN Model… … acknowledge the need for diverse abstractions

94 Network

Topo

logy

Rou?

ng

Forw

arding

Policy, QoS

Data-‐Path

Access

Interfaces

and Tunn

els

Confi

g &

Capabili?

es

Debu

gging

Diagno

s?cs,

Even

ts

Service

Discovery

Service

Path

Service

Placem

ent

Network stats

Analy?cs

Address

Mapping

API infrastructure Agents

Forw

arding

Policy, QoS

Data-‐Path

Access

Management Plane

Data Plane

Control Plane

Management Plane

Data Plane

Control Plane

OF-‐Agent

Generic Controller

APIs

App

App

App


Programmatic Network Control and the Gartner Hype Cycle

95

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

Phase 1

Phase 2

Technology Readiness Phases

Phase 3

Academic research (“OpenFlow”)

Value Proposi<on for mass market understood

Broad interest from technical community + use cases (“SDN”)

Entering Phase 3…


Open Network Environment for SDN

Applica?ons Management Orchestra?on

Loca8on/Topology (incl. ALTO, BGP-‐LS,…) Service-‐Path (incl. PCE, ..)

Network-‐Policy Service/Network Abstrac?ons

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

Physical Network Device Virtual Network Device

U5lity/Area/PIN APIs (e.g. ALTO,.. )

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


Open Network Environment for SDN Focus: Network/Service Abstractions and associated APIs

Loca8on/Topology (incl. ALTO, BGP-‐LS,…) Service-‐Path (incl. PCE, ..)

Network-‐Policy Service/Network Abstrac?ons

Physical Network Device Virtual Network Device


Orchestra?on Dy

namic

Service

Chains

Mul?-‐PO

D Network

containe

rs

…

Med

iaNet

Delivery

Network

Clou

d Cache

Network


Open Network Environment Focus: Network/Service Abstractions and associated APIs


Service/ Network

Abstrac?ons

Physical Network Element Virtual Network Element

Network

Topo

logy

Service

Discovery

Service

Path

Service

Placem

ent

Address

Mapping

Rou?

ng

…

NPS,.. ALTO LISP-‐ MS,..

BGP-‐LS, ALTO,.. PCE,..

Network stats

Analy?cs

IRS


Open Network Environment for SDN Focus: Device-level abstractions and associated APIs


Service/Network Abstrac?ons

Virtual / Physical Network Element

Device

Capabili?

es

Device

Confi

gura?o

n

Debu

gging

Diagno

s?c

Even

ts

Interfaces

and Tunn

els

Data-‐Path

Access

…

Neighbo

r Discovery

Forw

arding

Policy, QoS

API infrastructure Agents

Control Plane Management Plane Data Plane


Industry Standards & Forums

Technical Advisory Group, Working Groups:

Config, Hybrid, Extensibility, Futures/FPMOD/OF2.0

802.1 Overlay Networking Projects

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

Open Network Research Center at Stanford University

Initiatives: Quantum Donabe

Summary


Summary: Open Network Environment Cisco Innovations Summary announced at Cisco Live San Diego

  Complete developer’s kit for multiple Cisco Platforms, Servers, Blades

  Rapidly develop test and deploy Applications.

  Phased availability across IOS, IOS-XR and NX-OS platforms

  Engage with universities & research for campus slicing use case

  OpenFlow experimental support on select Cisco platforms

  Controller SW for experimentation on production networks

Controllers + Agent Support

Overlay Network Solu<ons

onePK Developer Kit

Programma?c APIs

Controllers and

Agents

Virtual Overlays

  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


Cisco Vision: Exposing The Entire Network Value Programmatic Control across Multiple Network Planes

103

Applica?on Developer Environment

Analysis and Monitoring, Performance and Security

Network Elements and Abstrac?on

SDN

CISCO

Harvest Network Intelligence

Program Policies for Op<mized Experience Any Object

Any Service

Any Layer

•  Switch/Router •  ASIC •  Network Fabric •  Compute

•  Cloud •  Collaboration •  Video •  Security •  Mobility

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


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

Open Network Environment – Summary

  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

The Industry’s Broadest Approach to Programmatic Access to the Network

104

www.cisco.com/go/one Open Network Environment

onePK

software defined networks and openflow

Documents

network vendor

network intelligence

en8re network

individual network devices

evolving network architectures

automated network congura8

open solu8on

cisco andor