Software Defined Networking is re defining some IT scenarios. The network can "de facto" support applications in a novel and centralized way. Some ideas presented in the Consultation on Future Network Technologies Research and Innovation in HORIZON 2020

1. Software Defined Networking
The network becomes part of the application
A contribution to the Consultation on Future Network Technologies
Research and Innovation in HORIZON 2020
Eduardo Jacob <Eduardo.Jacob@ehu.es>
Campus of International
Excellence

2. Outline
Introduction
Facts
Technical Research and Innovation in SDN?
SDN based Research and Innovation
Conclusions
Eduardo.Jacob@ehu.es - Jun 29th 2012
2/13

3. Introduction
Activities
Deployment and management of EHU‐OEF (2011‐2013).
Basque Government Strategic Project: Future Internet II (2011‐2013)
IOT and SDN.
Experimental platform.
Basque Government Thematic Network: RedSOC (2011‐2012)
Software Defined Networking applied to eScience.
Spanish Ministry of Science: A3RAM‐NG (2011‐2013)
AAA in Next Generation Access Networks
FP7 project should start really soon
Eduardo.Jacob@ehu.es - Jun 29th 2012
3/13

4. Facts
1st: A disclaimer: I am not in the ONF, so perhaps some of these
comments don’t apply at all…
SDN is OpenFlow (at least by now)
Although some vendor implementations could also apply for the
term (with limitations in scope).
Huge efforts (lead by ONF) which include the whole IT ecosystem
and mayor vendors.
It’s the only widely available technology.
SDN concept is still in it’s infancy.
High‐performance implementations of “post V1.1” not available.
Some drawbacks and limitations are still implementation‐
dependent.
We still don’t know limitations of actual implementation.
Software Driven Networking vs Software Defined Networking.
Eduardo.Jacob@ehu.es - Jun 29th 2012
4/13

5. Is there still place for technical
research and innovation in SDN?
It depends…
Eduardo.Jacob@ehu.es - Jun 29th 2012
5/13

6. Is there still place for technical
research and innovation in SDN?
The OpenFlow Ecosystem
Eduardo.Jacob@ehu.es - Jun 29th 2012
6/13

7. Is there still place for technical
research and innovation in SDN?
SDK.
Frameworks.
API.
Software.
Eduardo.Jacob@ehu.es - Jun 29th 2012
7/13

8. Is there still place for technical
research and innovation in SDN?
Network Operating
System.
System Applications.
Performance.
Eduardo.Jacob@ehu.es - Jun 29th 2012
7/13

9. Is there still place for technical
research and innovation in SDN?
OpenFlow Extensions…
Standardization?
Eduardo.Jacob@ehu.es - Jun 29th 2012
7/13

10. Is there still place for technical
research and innovation in SDN?
Performance.
Specific Hardware.
Eduardo.Jacob@ehu.es - Jun 29th 2012
7/13

11. Standardization
ONF is actually involved in OpenFlow protocol and OF‐CONFIG.
Not clear how (if possible) to interact with ONF not being part of it.
Northbound interface, possible candidate…
There is place for alternative Higher Levels (Network Operating Systems
and upwards)…
There are many well known cases of Open Source Operating systems
running over standard hardware.
Other traditional standardizing bodies slowly getting into SDN…
Nevertheless, respecting the standard, we should expect different:
Performance.
Completeness of implementation.
Vendor extensions and functionalities.
Nevertheless, there are, in Europe, many research institutions, industrial
and telecomm operators that are dealing with SDN, that should aggregate
efforts to multiply results to strength European SDN presence.
Eduardo.Jacob@ehu.es - Jun 29th 2012
8/13

12. SDN based Research and
Innovation
Our experience:
The network becomes another part of the solution.
Everything becomes possible (at least in theory…)
Interaction between controllers and switches present certain
problems (being tackled?):
Synchronization issues other kind of equipment.
Interaction between several runs of processes.
Variable performance in low level interactions.
Software/Hardware limits (number of rules).
Not only Ethernet based solutions can benefit.
A great potential!!!
Eduardo.Jacob@ehu.es - Jun 29th 2012
9/13

13. SDN based Research and
Innovation
Our vision:
The network becomes another part of the application.
A SDN based access network can:
Support enriched user application that can manage finely
grained flows.
“shortcut” local end to end connections (P2P, Skype…).
Run protocols directly over Ethernet (ie: ROCE).
Implement very finely grained traffic Engineering.
Ease and efficient (time to market) creation of dynamic
services based on user or operator requests.
Support through Virtualization, new service paradigms
Promote adhoc application development and correspondent
business opportunities.
Eduardo.Jacob@ehu.es - Jun 29th 2012
10/13

14. SDN based Research and
Innovation
Our vision:
A SDN based core network can:
Avoid tunneling and corresponding overheads.
Dynamically define aggregation criteria.
Ease traffic engineering.
Optimize link occupancy.
Support end to end applications.
…
Eduardo.Jacob@ehu.es - Jun 29th 2012
11/13

15. A joint effort
A common Forum?
Stakeholders Strength
GEANT and NRENs. Experimental platforms Provide an experimental platform that can
support massive experimentation to support
research and innovation in the SDN field in
the core and Ethernet access.
Experimental platforms should test more
disruptive techniques.
Universities and Research Institutions Use scientific methods to assess limitations of
current model, propose new solutions.
Industry. Telecomm Operators Orient research and experimentation.
Innovation (I,TO)
Provide user base and access tecnologies to
reach them (T)
SME Make profit of a new playground.
Innovate at lesser cost.
A new market opportunity.
Users Assess social benefits: Efficiency, cost, added
value
12/13

16. Conclussions
SDN is a promising technology.
There are technical areas that can support research and innovation in
the SDN field.
There are actual limitations that are still implementation dependent.
The new breed of hardware will probably open even more possibilities.
There is a clear opportunity for adhoc applications developing and
corresponding business opportunities.
The citizen should get the benefit.
The Network becomes part of the Application
Eduardo.Jacob@ehu.es - Jun 29th 2012
13/13

17. THANK YOU
Eduardo Jacob <Eduardo.Jacob@ehu.es>
Campus of International
Excellence

18. An quick primer on OpenFlow
Created in Stanford to support Clean Slate research on
Future Internet.
Originally targeting Research Networks, now interest
growing from other areas: Data center, mobile…
Based on the Flow Concept.
The Open Networking Foundation:
SDN and OpenFlow protocol development.
More than 60 companies, from every part of the IT ecosystem.
High speed and minimal standardization.
Not clear how Universities and Research Institutions can propose,
participate or perform oriented research.
Eduardo.Jacob@ehu.es - Jun 29th 2012

19. The Flow and the Flow Table
Very Simplified and old (v1.0)!!!
+ mask what fields to match
The Stanford Clean Slate Program
http://cleanslate.stanford.edu

20. Examples
Switching
Switch MAC MAC Eth VLAN IP IP IP TCP TCP
Action
Port src dst type ID Src Dst Prot sport dport
* * 00:1f:.. * * * * * * * port6
Flow Switching
Switch MAC MAC Eth VLAN IP IP IP TCP TCP
Action
Port src dst type ID Src Dst Prot sport dport
port3 00:20.. 00:1f.. 0800 vlan1 1.2.3.4 5.6.7.8 4 17264 80 port6
Firewall
Switch MAC MAC Eth VLAN IP IP IP TCP TCP
Forward
Port src dst type ID Src Dst Prot sport dport
* * * * * * * * * 22 drop
The Stanford Clean Slate Program
http://cleanslate.stanford.edu

21. Managing the flow table: The
Controller
The Stanford Clean Slate Program
http://cleanslate.stanford.edu

22. FlowVisor Creates Virtual Networks
Experiment PBD
Production
One Experiment
Slice
Controller Controller
Controller
OpenFlow
Protocol
OpenFlow
OpenFlow Protocol
Switch FlowVisor Slice
Policy
FlowVisor slices OpenFlow
OpenFlow OpenFlow networks, creating multiple
Switch Switch isolated and programmable
logical networks on the
same physical topology.
The Stanford Clean Slate Program
http://cleanslate.stanford.edu

23. Multiple OpenFlow Protocol versions
(and available implementations!!!)
Protocol Evolution (and before, there were 0.89 and 0.90)
Version 1.0 (the most widely deployed)
Version 1.1 adds: MAC subnetting, MPLS, Multiple
Table (goto), Multicast.
Version 1.2 adds: Basic IPv6 header support, extensible
matches (TLV).
Version 1.3 adds: IPv6 Extension header, per flow
meters, auxiliary connections, PBB tagging…
EHU‐OEF, uses 1.0 plus fixed MAC subnetting.
Back to the presentation
23/17