SDN NFV: and All That
SDN NFV: and All That
SDN NFV: and All That
NFV
and all that
Presented by:
Yaakov (J) Stein
CTO
SDNFV Slide 1
* Introduction
Outline * SDN
* NFV
* Hype and doubts
* OpenFlow
* Alternatives
SDNFV Slide 2
Introduction to NFV and SDN
SDNFV Slide 3
Today’s communications world
Today’s infrastructures are composed of many different Network Elements (NEs)
• sensors, smartphones, notebooks, laptops, desk computers, servers,
• DSL modems, Fiber transceivers,
• SONET/SDH ADMs, OTN switches, ROADMs,
• Ethernet switches, IP routers, MPLS LSRs, BRAS, SGSN/GGSN,
• NATs, Firewalls, IDS, CDN, WAN aceleration, DPI,
• VoIP gateways, IP-PBXes, video streamers,
• performance monitoring probes , performance enhancement middleboxes,
• etc., etc., etc.
New and ever more complex NEs are being invented all the time,
and RAD and other equipment vendors like it that way
while Service Providers find it hard to shelve and power them all !
In addition, while service innovation is accelerating
the increasing sophistication of new services
the requirement for backward compatibility
and the increasing number of different SDOs, consortia, and industry groups
which means that
it has become very hard to experiment with new networking ideas
NEs are taking longer to standardize, design, acquire, and learn how to operate
NEs are becoming more complex and expensive to maintain SDNFV Slide 4
Trends over time *
cost /
revenue
revenue
Service Provider
bankruptcy point
margin
P EX
+ O + OPEX
E X b le CA P E X
CAP desira
time
* thanks to Prodip Sen from Verizon for ideas behind this slide
SDNFV Slide 5
Two complementary solutions
Network Functions Virtualization (NFV) Note: Some people call NFV
This approach advocates replacing hardware NEs Service Provider SDN
or Telco SDN !
with software running on COTS computers
that may be housed in POPs and/or datacenters
Advantages:
• COTS server price and availability scales well
• functionality can be placed where-ever most effective or inexpensive
• functionality may be speedily deployed, relocated, and upgraded
SDNFV Slide 7
Function relocation
NFV and SDN facilitate (but don’t require) relocation of functionalities to
Points of Presence and Data Centers
Many (mistakenly) believe that the main reason for NFV
is to move networking functions to data centers
where one can benefit from economies of scale
And conversely, even nonvirtualized functions can be relocated
Some telecomm functionalities need to reside at their conventional location
• Loopback testing
• E2E performance monitoring Optimal location of a functionality needs
to take into consideration:
but many don’t • economies of scale
• routing and path computation • real-estate availability and costs
• billing/charging • energy and cooling
• traffic management • management and maintenance
• • security and privacy
DoS attack blocking
• regulatory issues
The idea of optimally placing virtualized network functions in the network
is called Distributed-NFV
SDNFV Slide 8
Example of relocation with SDN/NFV
How can SDN and NFV facilitate network function relocation ?
In conventional IP networks routers perform 2 functions
• forwarding
– observing the packet header
– consulting the Forwarding Information Base
– forwarding the packet
• routing
– communicating with neighboring routers to discover topology (routing protocols)
– runs routing algorithms (e.g., Dijkstra)
– populating the FIB used in packet forwarding
SDNFV Slide 10
Y(J)S taxonomy
While we have been using 2 buzz-words SDN and NFV,
there are actually 5 distinguishable trends :
• Computications
– blurring of division between communications and computation
• Physics - Logic
– spectrum of implementation options between HW and SW
– virtualization
• Philosophy
– touchless, configurable, and fully programmable devices
• Geography
– location of functionality (locally or remotely)
• Politics
– distributed control planes vs. centralized management planes
SDNFV Slide 11
Computications
Once there was no overlap
between communications (telephone, radio, TV)
and computation (computers)
Actually communications devices always ran complex algorithms
but these are hidden from the user
SDNFV Slide 12
Physics-Logic and Virtualization
Virtualization is the opposite (although frequently reserved for the extreme case of HW → SW)
Justifications are initially harder to grasp:
• lower development efforts and cost
• flexibility and ability to upgrade functionality
SDNFV Slide 13
Software Defined Radio
An extreme case of virtualization is Software Defined Radio
Transmitters and receivers (once exclusively implemented by analog circuitry)
can be replaced by DSP code
enabling higher accuracy (lower noise) and more sophisticated processing
For example, an AM envelope detector and FM ring demodulator
can be replaced by Hilbert transform based calculations
reducing noise and facilitating advanced features
(e.g., tracking frequency drift, notching out interfering signals)
SDR enables downloading of DSP code for the transmitter / receiver of interest
thus a single platform could be an LF AM receiver, or an HF SSB receiver, or a VHF FM receiver
depending on the downloaded executable software
Cognitive radio is a follow-on development
the SDR transceiver dynamically selects the best channel available
based on regulatory constraints, spectrum allocation, noise present at particular frequencies,
measured performance, etc.)
and sets its transmission and reception parameters accordingly
SDNFV Slide 14
Philosophy
flexibility
SDNFV Slide 15
Geography
NFV and SDN facilitate (but don’t require) relocation of functionalities to
Points of Presence and Data Centers
Optimal location of a functionality needs to take into consideration:
• economies of scale
• real-estate availability and costs
• energy and cooling
• management and maintenance
• security and privacy
• regulatory issues
Some telecomm functionalities need to reside at their conventional location
• Loopback testing
• E2E performance monitoring
but many don’t
• routing and path computation
• billing/charging
• traffic management
• DoS attack blocking
SDNFV Slide 16
Relocation without SDN/NFV
Just as virtualization in computation facilitated cloud computing
SDN/NFV facilitates relocation of network functions
However, there are relocation cases that do not depend on it
Examples:
• CPRI
– relocation of eNodeB processing to PoP
– leaves only mixer and A/D at antenna location
• MOCA
– relocation of WiFi Access Point to closet
– leaves only amplifier at antenna position
• IPS as a service (e.g., RADWARE’s DefenseFlow)
– relocation of DefensePro functionality to data center
– leaves only basic detection at router
SDNFV Slide 17
Relocation with SDN/NFV - RouteFlow
How do SDN and NFV facilitate network function relocation ?
In conventional IP networks routers perform 2 functions
• forwarding
– observing the packet header
– consulting the Forwarding Information Base
– forwarding the packet
• routing
– communicating with neighboring routers to discover topology (routing protocols)
– runs routing algorithms (e.g., Dijkstra)
– populating the FIB used in packet forwarding
SDNFV Slide 19
Data, control, and management planes
service plane
Note: some SDN proponents control plane
are now proposing a 4-plane model
data plane
with evolutionary introduction from top to bottom
SDNFV Slide 20
SDN
SDNFV Slide 21
Why SDN ? Abstractions
SDN was triggered by the development of networking technologies
not keeping up with the new user applications requiring networking
Computer science theorists theorized
that this derived from a lack of abstractions
In CS an abstraction is a representation
that reveals semantics needed at a given level
while hiding implementation details
thus allowing a programmer to focus on necessary concepts
without getting bogged down in unnecessary details
Much of the progress in CS resulted from finding new abstractions
Example:
Programming languages with higher and higher layers of abstraction have been developed
It is very slow to code directly in assembly language (with 1 abstraction : mnemonics for opcodes)
It is a bit faster to coding in a low-level language like C (additional abstractions : variables, structures)
It is much faster coding in high-level imperative language like Python
It is much faster yet coding in a declarative language (coding has been abstracted away)
It is fastest coding in a domain-specific language (only contains the needed abstractions)
SDNFV Slide 22
Control plane abstractions
The CS theorists came to the conclusion that 1 :
• The data plane has a useful abstraction – layering
• There is no unified control plane or useful abstractions
instead each network application has its own tailored-made control plane
with its own element discovery, state distribution, failure recovery, etc.
Note the subtle change of terminology
instead of calling switching, routing, load balancing, etc. network functions
to the CS theorists they are network applications (like SW apps, they can be easily added)
SDN principle 1 APIs instead of protocols
Replace control plane protocols with well-defined APIs to network applications
This would hide details of the network from the network application
revealing high-level concepts
such as requesting connectivity between A and B
but hiding details unimportant to the application
such as details of switches through which the path A → B passes
1
I personally believe that this insight is mostly misguided, but here I am reporting history SDNFV Slide 23
Network Operating System
Abstractions in computer science hide details not useful at a given level
For example, an operating system
• sits between user programs and the physical computer hardware
• reveals high level functions (e.g., allocating a block of memory or writing to disk)
• hides hardware-specific details (e.g., memory chips and disk drives)
We can think of SDN as a Network Operating System
Note: apps
user user user can be network network network
application application application added
without application application application
changing OS
SDNFV Slide 24
Packet forwarding abstraction
Continuing the CS-theorist’s argument
another abstraction relates to how a network element forwards packets
• A switch observes MAC addresses and VLAN tags and performs exact match
• A router observes IP addresses and performs longest prefix match
• A firewall observes multiple fields and performs regular expression match
We can hide these details and state :
SDN principle 2 Packet forwarding as a computational problem
The function of any Network Element is to
• receive a packet
• observe packet fields
• apply algorithm (classification, decision logic)
• optionally edit packet
• forward or discard packet
SDNFV Slide 25
Flows
It would be too slow for a Network Element
to query the central algorithm
for every packet received
So, it needs to store some network state
In order to reduce the amount of state it needs to store
we identify packets as belonging to flows
SDN principle 3 Flows (as in OpenFlow)
Packets are handled solely based on the flow to which they belong
Flows are thus just like Forwarding Equivalence Classes
Thus a flow may be determined by
• an IP prefix in an IP network
• A label in an MPLS network
• VLANs in VLAN cross-connect networks
The granularity of a flow depends on the application
SDNFV Slide 26
Network state and graph algorithms
In order to perform the forwarding algorithm on a packet belonging to a flow
NEs need to know something of the network state
(this may be complete knowledge or very limited local knowledge)
The best decisions can be made when there is full global knowledge
but it would be expensive for every NE to acquire and store such state
With full knowledge of topology and constraints
the flow routing problem can be solved by a graph algorithm
While it is possible to perform the decision algorithms in a distributed manner
it makes more sense to perform them centrally
The algorithm may be the same Dijkstra,
but performed in a central location by an entity with full knowledge
SDN principle 4 Eliminate distributed protocols
Replace distributed routing protocols with graph algorithms
performed at a central location
However, if the algorithm is not performed at the NE,
how does it know how to forward packets ?
SDNFV Slide 27
Configuration
The optimal amount of network state to be stored at the individual NE
is just a flow table describing how to forward a packet belonging to a flow (FIB)
Conventional NEs have two parts:
1. smart but slow CPUs that create the FIB
2. fast but dumb switch fabrics that use the FIB
Since the algorithms to build the FIB are performed elsewhere
SDN brings the added bonus that we don’t need the CPU
Such a simplified NE is called an SDN switch
We populate the flow table by direct configuration
The entity that communicates with the SDN switch to send configuration
is called an SDN controller
SDN principle 5 Configuration
SDN switches are dumb and flows are configured by an SDN controller
SDNFV Slide 28
SDN as a compiler
We have discussed the popular model of SDN as a Network Operating System
An alternative abstraction (advocated by Contrail, recently acquired by Juniper)
views SDN as a compiler
The idea is that the network user describes its requirements/constraints
in a high level declarative description
The SDN compiler
parses the requirements
compiles them to low level instructions for a NE (which may be an SDN switch)
SDNFV Slide 29
Robustness
SDN academicians complain about
the brittleness / fragility of communications protocols
As opposed to the robustness their approach can bring
SDNFV Slide 30
Robustness (cont.)
SDNFV Slide 31
OpenFlow SDN (pre)history
2005 ● 4D project Greenberg, Hjalmtysson, Maltz, Myers, Rexford, Xie, Yan, Zhan, Zhang
2005-2006 ● Stanford PhD student Martin Casado develops Ethane
(with Michael Freedman, Nick McKeown, Scott Shenker, and others)
2008 ● OpenFlow: Enabling Innovation in Campus Networks paper
Authors: Nick McKeown, Guru Parulkar (Stanford), Tom Anderson (U Washington), Hari Balakrishnan (MIT),
Larry Peterson, Jennifer Rexford (Princeton), Scott Shenker (Berkeley), Jonathan Turner (Washington U St. Louis)
• Stanford establishes OpenFlow Switching Consortium
2009
• reporter Kate Greene coins term SDN (after SDR) in interview with McKeown
• Nicira raises $575k funding
• OpenFlow 1.0 spec published by Standford
2010
• Big Switch raises $1.4M in seed funding
2011
• NEC, HP, and Marvell announce OpenFlow products
• Cisco, Juniper and others start talking about SDN
• first Open Networking Summit
• ONF founded, OpenFlow 1.1 and 1.2 and OF-CONFIG 1.0 specs published
2012 ● OpenFlow 1.3 and OF-CONFIG 1.1 specs published SDNFV Slide 32
Ethane – precursor to OpenFlow
Ethane was an enterprise network architecture
where connectivity is governed by high-level global fine-grained policy, e.g.,
• users can only communicate if allowed
• traffic of untrusted users may be required to pass through an IDS
• traffic or rogue hosts can be blocked upon entry
• certain traffic types may be given preferential treatment
Ethane had 2 components :
1. centralized omniscient controller that manages flows
2. simple (dumb) flow-based Ethane switches
Ethane was built to be backwards-compatible with existing hosts and switches
and thus enables hybrid topologies and migration
The controller
• knows the global network topology
• explicitly grants access by enabling flows
• performs route computation for permitted flows
Ethane switches are simpler than Ethernet switches, consisting of
• a flow table
• a secure channel to the controller SDNFV Slide 33
Ethane in action
Bootstrapping
• switches and controller form spanning tree with controller as root
Registration
• all users, hosts, and switches must be authenticated
• users are mapped to hosts, hosts to switch+port (mobility is part of policy)
Flow setup
• A sends packet to B via switch
• switch forwards packet to controller
• controller consults policy and decides whether to allow /deny and path
• controller adds flow entry to all switches along the path
• controller sends packet back to switch
• switch forwards packet
Forwarding
When a packet arrives to an Ethane switch
• if in flow table, forwarded according to matching flow entry
• if not in the flow table, it is sent to controller
SDNFV Slide 34
SDN interfaces
SDNFV Slide 38
SDN vs. conventional NMS
So 1) is OF/SDN simply a new network management protocol ?
and if so 2) is it better than existing NMS protocols ?
1) Since it is replaces both control and management planes
it is much more dynamic than present management systems
2) Present systems all have drawbacks as compared to OF :
SNMP (currently the most common mechanism for configuration and monitoring)
is not sufficiently dynamic or fine-grained (has limited expressibility)
not multivendor (commonly relies on vendor-specific MIBs)
Netconf
just configuration - no monitoring capabilities
CLI scripting
not multivendor (but I2RS is on its way)
Syslog mining
just monitoring - no configuration capabilities
requires complex configuration and searching
SDNFV Slide 39
SDN case study - Google
SDNFV Slide 42
Ofelia
OFELIA is an EU FP7 project
Participants : EICT, DT, I Bristol, i2CAT, TU Berlin, NEC, iMinds, Leland Stanford U, ADVA, CNIT,
CREATE-NET, CTTC, Lancaster U, ITAV, U Sao Paulo, UFU,
The project set up a OF-controlled optical network that
can be dynamically controlled and extended by researchers over the web
The network
• extends SDN into optical and wireless technologies
• allows flexible control down to individual flows
• is protocol agnostic
and allows non-IP experiments such as content-based addressing
• allows deployment and test of new controllers and apps
• supports automatic creation of slices
• enables multi-domain extensions of controllers (for federation of islands)
SDNFV Slide 43
Some more SDN projects
Comprehensive Switches
• OpenDaylight • Open vSwitch (Nicira/VMware)
• Indigo (Big Switch)
• Snabb (Open Source)
SDN controllers: • Pantou / OpenWRT (Standford)
• NOX, POX (ICSI)
• FloodLight (Big Switch)
• Beacon (Stanford) Testing
• Trema (Open Source) • Mininet (Stanford)
• Cbench (Stanford)
• NICE (EPFL, Princeton)
NOS and routing • OFTest (Big Switch)
• Maestro (Rice U)
• RouteFlow (CpqD) Extensions
• Ofelia
SDNFV Slide 44
NFV
SDNFV Slide 45
Virtualization of computation
In the field of computation, there has been a major trend towards virtualization
Virtualization here means the creation of a virtual machine (VM)
that acts like an independent physical computer (or other hardware device)
A VM is software that emulates hardware (e.g., an x86 CPU)
over which one can run software as if it is running on a physical computer
The VM runs on a host machine
and creates a guest machine (e.g., an x86 environment)
A single host computer may host many fully independent guest VMs
and each VM may run different Operating Systems and/or applications
For example
• a datacenter may have many racks of server cards
• each server card may have many (host) CPUs
• each CPU may run many (guest) VMs
A hypervisor is software that enables creation and monitoring of VMs
SDNFV Slide 46
Cloud computing
Once computational and storage resources are virtualized
they can be relocated to a Data Center
as long as there is a network linking the place the user to the DC
DCs are worthwhile because
• user gets infrastructure (IaaS) or platform (PaaS) or software (SaaS) as a service
and can focus on its core business instead of IT
• user only pays for CPU cycles or storage GB actually used (smoothing peaks)
• agility – user can quickly upscale or downscale resources
• ubiquitousness – user can access service from anywhere
• cloud provider enjoys economies of scale, centralized energy/cooling
A standard cloud service consists of
• Allocate, monitor, release compute resources (EC2, Nova)
• Allocate and release storage resources (S3, Swift)
• Load application to compute resource (Glance)
• Dashboard to monitor performance and billing
SDNFV Slide 47
Network Functions Virtualization
Computers are not the only hardware device that can be virtualized
Many (but not all) NEs can be replaced by software running on a CPU or VM
This would enable
• using standard COTS hardware (e.g., high volume servers, storage)
– reducing CAPEX and OPEX
• fully implementing functionality in software
– reducing development and deployment cycle times, opening up the R&D market
• consolidating equipment types
– reducing power consumption
• optionally concentrating network functions in datacenters or POPs
– obtaining further economies of scale. Enabling rapid scale-up and scale-down
For example, switches, routers, NATs, firewalls, IDS, etc.
are all good candidates for virtualization
as long as the data rates are not too high
Physical layer functions (e.g., Software Defined Radio) are not ideal candidates
High data-rate (core) NEs will probably remain in dedicated hardware
SDNFV Slide 48
Distributed NFV
The idea of optimally placing virtualized network functions in the network
is called Distributed-NFVTM
Optimal location of a functionality needs to take into consideration:
• resource availability (computational power, storage, bandwidth)
• real-estate availability and costs
• energy and cooling
• management and maintenance
• other economies of scale
• security and privacy
• regulatory issues
For example, consider moving a DPI engine from where it is needed
this requires sending the packets to be inspected to a remote DPI engine
If bandwidth is unavailable or expensive or excessive delay is added
then DPI must not be relocated
even if computational resources are less expensive elsewhere!
SDNFV Slide 49
D-NFV orchestration
Data center orchestration systems decide where to place computational tasks
based on constraints, costs, present CPU/memory loading, etc
Similarly, with D-NFV we need to solve the VNF placement problem
i.e., to compute the optimal location to insert a virtual function
taking into account constraints, costs, CPU/memory load, …
For function chaining (placement of multiple VNFs)
there are frequently (partial) order rules as well
It is suboptimal to perform path computation and D-NFV placement separately
so we need to perform joint path computation and D-NFV placement
This is a novel and challenging graph optimization problem !
SDNFV Slide 50
RAD D-NFV : ETX2 with VM
x86 module
SDNFV Slide 51
ETX2 with VM
VNF VNF
OpenStack
Hypervisor Controller
Customer Site
Data Center
Customer
Network Network
ETX2
SDNFV Slide 52
Firewall with ETX/VM
• 1 Gbps 3rd party firewall app
• Data paths are directed to the VM per VLAN
• Local filtering at customer firewall maximizes upstream BW
Hypervisor
Firewall Firewall
VLANs VLANs
Customer Network
Network UNI NNI
Pass-through VLANs
SDNFV Slide 53
Packet collection with ETX/VM
• Packet collector monitors traffic to analyze network
behavior, performance and applications
• Hardware forwarding with Flow Mirroring ensures VM
does not introduce delay and is not a bottleneck
TCPdump Management PC running PuTTY
for activating
TCPdump VNF SSH to activate/ deactivate TCPdump TCPdump and
SFTP for file transfer retrieving the file
Open vSwitch OpenStack
Hypervisor
Monitored Monitored
VLANs VLANs
Customer
Network
Network UNI NNI
Pass-through VLANs
SDNFV Slide 54
Distributed Application Awareness with ETX/VM
Central Site(s)
DPI Client/Server traffic
DPI Display Policy
Application Performance information Engine DB Server Application Server
DB presentation information SQL
Policy information
PM Engine
AAw-NID
Customer
Network Network
AAW SFP
• AAw-NID – Ethernet/IP CLE sends new application samples to the DPI engine, and then
handles traffic per application policy
• DPI server – identifies the application based on sample traffic sent by the CPE
• DB server – collects application-related information and statistics
• Display application – generates graphs and reports based on collected application
information
• Policy server – distributes policies to the AAw-NIDs
SDNFV Slide 55
RAD D-NFV : VNFs
The next step will be in-house and partner development of VNFs
RAD will create an ecosystem of software vendors
writing for RAD VM devices
Service Providers will also be able to write their own VNFs
Virtual functions that are not network functions may also be hosted
FM MEP Y.1731/802.1ag compliant “light” MEP for FM
FM MIP Y.1731/802.1ag compliant MEP
PM MEPfull Y.1731 compliant MEP
TWAMPGEN TWAMP generator
Example VNFs
SDNFV Slide 57
Is NFV a new idea ?
Virtualization has been used in networking before, for example
• VLAN and VRF – virtualized L2/L3 infrastructure
• Linux router – virtualized forwarding element on Linux platform
But these are not NFV as presently envisioned
Possibly the first real virtualized function is the Open Source network element :
• Open vSwitch
– Open Source (Apache 2.0 license) production quality virtual switch
– extensively deployed in datacenters, cloud applications, …
– switching can be performed in SW or HW
– now part of Linux kernel (from version 3.3)
– runs in many VMs
– broad functionality (traffic queuing/shaping, VLAN isolation, filtering, …)
– supports many standard protocols (STP, IP, GRE, NetFlow, LACP, 802.1ag)
– now contains SDN extensions (OpenFlow)
SDNFV Slide 59
Potential VNFs
OK, so we can virtualize a basic switch – what else may be useful ?
SDNFV Slide 60
NFV deployments and PoCs
Open vSwitch widely deployed in DCs
Colt has partnered with Juniper to deliver a virtual L3 CPE
Telefonica is partnering with NEC in a migration scenario study
to virtualize IP edge network elements
Participants
ADVA, AEPONYX, Affirmed Networks, ARM, Brocade, Cavium, CenturyLink, China Mobile, Ciena, CIMI, Colt,
Connectem, ConteXtream, Cyan, DELL, DESS, Dialogic, Embrane, EMC, EnterpriseWeb, EANTC,
Everything Everywhere, F5 Networks, Genband Ireland, IDT Canada, Infinera, Intune Networks, IP Infusion, Ixia,
KDDI, Lancaster U, Layer123, LSI, Mellanox, Metaswitch, Mojatatu, Netronome, Netsocket, Noviflow,
Openwave Mobility, Overture, PeerApp, Plexxi, PMC Sierra, Qosmos, RAD Data, Red Hat, Radware, Saisei Networks,
SCILD Communications, Shenick, SingTel Optus, SK Telecom, Softbank Telecom, Sunbay, Symantec, Tail-f, Tekelec,
Telco Systems, Telstra, Tieto Sweden, Tilera, Ulticom, Visionael, VMware, Windstream, Wiretap Ventures, 6WIND
NFV infrastructure
SDNFV Slide 64
Hype and Doubts
SDNFV Slide 65
Are SDN and NFV really solutions ?
Many in the industry seem to think so
• VMware acquired Nicira for $1.26 billion
• Cisco acquired Cariden for $141M and Meraki for $1.2B
• Juniper acquired Contrail for $176m
• In the OpenDaylight consortium many competitors, including
– Brocade, Cisco, Citrix, Ericsson, IBM, Juniper, Microsoft , Redhat
– NEC, Vmware
– Adva, Arista, Ciena, Cyan, Dell, Fujitsu, Guavus, HP, Huawei, Inocybe,
Intel, Nuage, Pantheon, Plexxi, Plumgrid, RADware, Versa
are working together and donating their work as Open Source
There have PoCs showing that showing that NFV is just around the corner
The reasoning is :
• general purpose CPUs can not economically perform
the required network function right now
• but, because of Moore’s law they will be able to do so soon
SDNFV Slide 66
Doubts
SDNFV Slide 67
Moore’s law vs. Butter’s law
SDNFV Slide 68
SDN layer violations
SDN’s main tenet is that packet forwarding is a computational problem
• receive packet
• observe fields
• apply algorithm(classification, decision logic)
• optionally edit packet
• forward or discard packet
SDNFV Slide 69
Consequences of layer violations
Client/server (G.80x) layering enables Service Providers
• to serve a higher-layer SP
• to be served by a lower-layer SP
SDNFV Slide 70
The CAP Theorem
SDNFV Slide 71
CAP: the SP Network Choice
SPs pay dearly for lack of service
not only in lost revenues, but in SLA violation penalties
SP networks are designed for1 :
AP
X
• high availability (five nines) and
• high partition tolerance (50 millisecond restoration times)
So, consistency must suffer
C
• black-holed packets (compensated by TTL fields, CV testing, etc.)
• eventual consistency (but steady state may never be reached)
1
This applies to services that have already been configured.
When commissioning a new service Availability is sacrificed instead
which is why service set-up is often a lengthy process.
SDNFV Slide 72
CAP: the SDN Choice
SDN has emphasized consistency (perhaps natural for software proponents)
So such SDNs must forgo either availability or partition tolerance (or both)
X
Either alternative may rule out use of SDN in SP networks
Relying solely on a single1 centralized controller
AP
(which in communications parlance is a pure management system)
may lead to more efficient bandwidth utilization
but means giving up partition tolerance
C
However, there are no specific mechanisms to attain availability either !
Automatic protection switching needs to be performed quickly
which can not be handled by a remote controller alone2
1
Using multiple collocated controllers does not protect against connectivity failures.
Using multiple non-collocated controllers requires synchronization, which can lead to low availability.
2
There are solutions, such as triggering preconfigured back-up paths,
but present SDN protocols do not support conditional forwarding very well.
SDNFV Slide 73
Scalability
In centralized protocols (e.g., NMS, PCE, SS7, OpenFlow)
all network elements talk with a centralized management system (AKA Godbox)
that collects information, makes decisions, and configures elements
In distributed protocols (e.g., STP, routing protocols)
each network element talks to its neighbors
and makes local decisions based currently available information
Distributed protocols are great at discovering connectivity
but are not best for more general optimization
Distributed protocols scale without limit
but may take a long time to completely converge (only eventual consistency)
Centralized protocols can readily solve complex network optimization problems
but as the number of network elements increases
the centralized element becomes overloaded
Dividing up the centralized element based on clustering network elements
is the first step towards a distributed system (BGP works this way)
SDNFV Slide 75
Open Networking Foundation
In 2011 the responsibility for OpenFlow was handed over to the ONF
ONF is both an SDO and a foundation for advancement of SDN
ONF objectives
• to create standards to support an OpenFlow ecosystem
• to position SDN/OF as the future or networking and support its adoption
• raise awareness, help members succeed
• educate members and non-members (vendors and operators)
ONF methods
• establish common vocabulary
• produce shared collateral
• appearances
• industry common use cases
The ONF Inherited OF 1.0 and 1.1 and standardized OF 1.2, 1.3.x, 1.4.x
It has also standardized of-config 1.0, 1.1, 1.2, of-notifications-framework-1.0
OF produces Open interfaces but not Open Source and does not hold IPR
but no license charges to all members, no protection for non-members SDNFV Slide 76
ONF structure
Management Structure
• Board of Directors (no vendors allowed)
• Executive Director (presently Dan Pitt, employee, reports to board)
• Technical Advisory Group (makes recommendations not decisions, reports to board)
• Working Groups (chartered by board, chair appointed by board)
• Council of Chairs (chaired by executive director, forwards draft standards to board)
ONF Board members
• Dan Pitt Executive Director
• Nick McKeown Stanford University
• Scott Shenker UC Berkeley and ICSI
• Deutsche Telecom AG
• Facebook
• Goldman Sachs
• Google
• Microsoft run giant data centers
• NTT Communications
• Verizon
• Yahoo
SDNFV Slide 77
ONF groups
Working Groups
• Architecture and Framework
• Forwarding Abstraction
• Northbound Interface (new)
• Optical Transport (new)
• Wireless and Mobile (new)
• Configuration and Management
• Testing and Interoperability
• Extensibility
• Migration
• Market Education
• Hybrid - closed
Discussion Groups
• Carrier grade SDN
• Security
• L4-7
• Skills Certification
• Wireless Transport
• Japanese
SDNFV Slide 78
ONF members
6WIND,A10 Networks,Active Broadband Networks,ADVA Optical,ALU/Nuage,Aricent Group,Arista,
Big Switch Networks,Broadcom,Brocade,
Centec Networks,Ceragon,China Mobile (US Research Center),Ciena,Cisco,Citrix,CohesiveFT,Colt,Coriant,Cyan,
Dell/Force10,Deutsche Telekom,
Ericsson,ETRI,Extreme Networks,F5 / LineRate Systems, Facebook,Freescale,Fujitsu,
Gigamon,Goldman Sachs,Google, Hitachi,HP,Huawei,IBM,Infinera,Infoblox / FlowForwarding,
Intel,Intune Networks,IP Infusion,Ixia, Juniper Networks, KDDI,KEMP Technologies,Korea Telecom,
Lancope,Level 3 Communications,LSI,Luxoft,
Marvell,MediaTek,Mellanox,Metaswitch Networks, Microsoft,Midokura,
NCL,NEC,Netgear,Netronome,NetScout Systems,NSN,NoviFlow,NTT Communications,
Optelian,Oracle,Orange,Overture Networks,
PICA8,Plexxi Inc.,Procera Networks, Qosmos,
Rackspace,Radware,Riverbed Technology,
Samsung, SK Telecom,Spirent,Sunbay,Swisscom,
Tail-f Systems,Tallac,Tekelec,Telecom Italia,Telefónica, Tellabs,Tencent,
Texas Instruments,Thales,Tilera,TorreyPoint,Transmode,Turk Telekom/Argela,TW Telecom,
Vello Systems,Verisign,Verizon,Virtela,VMware/Nicira, Xpliant, Yahoo, ZTE Corporation
SDNFV Slide 79
OpenFlow
The OpenFlow specifications describe
• the southbound protocol between OF controller and OF switches
• the operation of the OF switch
The OpenFlow specifications do not define
• the northbound interface from OF controller to applications
• how to boot the network
• how an E2E path is set up by touching multiple OF switches
• how to configure or maintain an OF switch (see of-config)
Table matching
• each flow table is ordered by priority
• highest priority match is used (match can be made “negative” using drop action)
• matching is exact match with certain fields allowing bit masking
• table may specify ANY to wildcard the field
• fields matched may have been modified in a previous step
SDNFV Slide 87
OF switch ports
The ports of an OpenFlow switch can be physical or logical
The following ports are defined :
• physical ports (connected to switch hardware interface)
• logical ports connected to tunnels (tunnel ID and physical port are reported to controller)
• ALL output port (packet sent to all ports except input and blocked ports)
• CONTROLLER packet from or to controller
• TABLE represents start of pipeline
• IN_PORT output port which represents the packet’s input port
• ANY wildcard port
• LOCAL optional – switch local stack for connection over network
• NORMAL optional port sends packet for conventional processing (hybrid switches only)
• FLOOD output port sends packet for conventional flooding
SDNFV Slide 88
Instructions
Each flow entry contains an instruction set to be executed upon match
Instructions include
• Metering : rate limit the flow (may result in packet being dropped)
• Apply-Actions : causes actions in action list to be executed immediately
(may result in packet modification)
• Write-Actions / Clear-Actions : changes action set associated with packet
which are performed when pipeline processing is over
• Write-Metadata : writes metadata into metadata field associated with packet
• Goto-Table : indicates the next flow table in the pipeline
if the match was found in flow table k
then goto-table m must obey m > k
SDNFV Slide 89
Actions
OF enables performing actions on packets
• output packet to a specified port
• drop packet (if no actions are specified) mandatory to support
• apply group bucket actions (to be explained later)
• overwrite packet header fields
• copy or decrement TTL value
optional to support
• push or pop push MPLS label or VLAN tag
• set QoS queue (into which packet will be placed before forwarding)
Action lists are performed immediately upon match
• actions are accumulatively performed in the order specified in the list
• particular action types may be performed multiple times
• further pipeline processing is on modified packet
SDNFV Slide 90
Meters
OF is not very strong in QoS features, but does have a metering mechanism
A flow entry can specify a meter, and the meter measures and limits the
aggregate rate of all flows to which it is attached
The meter can be used directly for simple rate-limiting (by discarding)
or can be combined with DSCSP remarking for DiffServ mapping
Each meter can have several meter bands
if the meter rate surpasses a meter band, the configured action takes place
Possible actions are
• drop
• increase DSCP drop precedence
SDNFV Slide 91
OpenFlow statistics
OF switches maintain counters for every
• flow table
• flow entry
• port
• queue
• group
• group bucket
• meter
• meter band
Counters are unsigned and wrap around without overflow indication
Counters may count received/transmitted packets, bytes, or durations
See table 5 of the OF specification for the list of mandatory and optional counters
SDNFV Slide 92
Flow removal and expiry
Flows may be explicitly deleted by the controller at any time
However, flows may be configured with finite lifetimes
and are automatically removed upon expiry
Each flow entry has two timeouts
• hard_timeout : if non-zero, the flow times out after X seconds
• idle_timeout : if non-zero, the flow times out
after not receiving a packet for X seconds
SDNFV Slide 93
Groups
Groups enable performing some set of actions on multiple flows
thus common actions can be modified once, instead of per flow
Groups also enable additional functionalities, such as
• replicating packets for multicast
• load balancing
• protection switch
ID type counters action buckets
Group operations are defined in group table
Group tables provide functionality not available in flow table
While flow tables enable dropping or forwarding to one port
group tables enable (via group type) forwarding to :
• a random port from a group of ports (load-balancing)
• the first live port in a group of ports (for failover)
• all ports in a group of ports (packet replicated for multicasting)
Action buckets are triggered by type:
• All execute all buckets in group
• Indirect execute one defined bucket
• Select (optional) execute a bucket (via round-robin, or hash algorithm)
• Fast failover (optional) execute the first live bucket SDNFV Slide 94
Slicings
Network slicing
Network can be divided into isolated slices
each with different behavior
each controlled by different controller
Thus the same switches can treat different packets in completely different ways
(for example, L2 switch some packets, L3 route others)
Bandwidth slicing
OpenFlow supports multiple queues per output port
in order to provide some minimum data bandwidth per flow
This is called slicing since it provides a slice of the bandwidth to each queue
Queues may be configured to have :
• given length
• minimal/maximal bandwidth
• other properties
SDNFV Slide 95
OpenFlow protocol packet format
OF runs over TCP (optionally SSL for secure operation) using port 6633
and is specified by C structs
OF is a very low-level specification (assembly-language-like)
Ethernet header
IP header (20B)
Transaction ID (4B)
Type-specific information
SDNFV Slide 96
OpenFlow messages
The OF protocol was built to be minimal and powerful (like x86 instruction set )
and indeed it is low-level assembly language-like
Symmetric messages
• hellos (startup)
• echoes (heartbeats, measure control path latency)
• experimental messages for extensions
SDNFV Slide 97
OpenFlow message types
Symmetric messages Controller command messages Queue Configuration messages
0 HELLO 13 PACKET_OUT 22 QUEUE_GET_CONFIG_REQUEST
1 ERROR 14 FLOW_MOD 23 QUEUE_GET_CONFIG_REPLY
2 ECHO_REQUEST 15 GROUP_MOD
3 ECHO_REPLY 16 PORT_MOD Controller role change request messages
4 EXPERIMENTER 17 TABLE_MOD 24 ROLE_REQUEST
25 ROLE_REPLY
Switch configuration Multipart messages
5 FEATURES_REQUEST 18 MULTIPART_REQUEST Asynchronous message configuration
6 FEATURES_REPLY 19 MULTIPART_REPLY 26 GET_ASYNC_REQUEST
7 GET_CONFIG_REQUEST 27 GET_ASYNC_REPLY
8 GET_CONFIG_REPLY Barrier messages 28 SET_ASYNC
9 SET_CONFIG 20 BARRIER_REQUEST
21 BARRIER_REPLY Meters and rate limiters configuration
Asynchronous messages 29 METER_MOD
10 PACKET_IN = 10
11 FLOW_REMOVED = 11
12 PORT_STATUS = 12
Interestingly, OF uses a protocol version and TLVs for extensibility
These are 2 generic control plane mechanisms,
of the type that SDN claims don’t exist …
SDNFV Slide 98
Session setup and maintenance
An OF switch may contain default flow entries to use
before connecting with a controller
The switch will boot into a special failure mode
An OF switch is usually pre-configured with the IP address of a controller
An OF switch may establish communication with multiple controllers in order
to improve reliability or scalability. The hand-over is managed by the controllers.
OF is best run over a secure connection (TLS/SSL),
but can be run over unprotected TCP
Hello messages are exchanged between switch and controller upon startup
hellos contain version number and optionally other data
Echo_Request and Echo_reply are used to verify connection liveliness
and optionally to measure its latency or bandwidth
Experimenter messages are for experimentation with new OF features
If a session is interrupted by connection failure
the OF switch continues operation with the current configuration
Upon re-establishing connection the controller may delete all flow entries
SDNFV Slide 99
Bootstrapping
How does the OF controller communicate with OF switches
before OF has set up the network ?
The OF specification explicitly avoids this question
• one may assume conventional IP forwarding to pre-exist
• one can use spanning tree algorithm with controller as root,
once switch discovers controller it sends topology information
CE manager Fc
CE Fr CE
Fp
NE Fp Fp
FE manager Ff FE Fi
FE
… …
FE
Config SET LFB
n attributes
Config Response
…
on
Event notificati
Agent 1 Agent 2