The document discusses a panel at a conference on Software Defined Networking (SDN). The panel will discuss whether SDN is a promise or a reality, and features panelists from industry and academia including representatives from Datacom, UFSCar, Algar, and NIC.BR.
1. Painel 1
SDN - Promessa ou Realidade?
Moderador: Christian Esteve Rothenberg (Unicamp)
Panelistas:
Marcelo Barcelos (Datacom)
Cesar Marcondes (UFSCar)
Joao Henrique de Souza Pereira (Algar)
Julio Sirota (NIC.BR)
XXXII Simpósio Brasileiro de
Redes de Computadores e Sistemas Distribuídos
Florianópolis, 5 a 9 de Maio de 2014
2. Networking as Learned
in School (text books)
Source: Martin Casado CS244 Spring 2013, Lecture 6, SDN
5. Networking in Practice
“in theory, theory and practice are the same;
in practice they are not...”
Source: Martin Casado CS244 Spring 2013, Lecture 6,
13. SDN definitions
• With the original definition, SDN represented a network architecture
where the forwarding state is solely managed by a control plane and
is decoupled from the data plane.
• The industry, however, has moved on from the original academic
purist view of SDN to referring to anything disruptive or
fundamentally new as part of SDN.
At least two definitions for SDN:
1. academic
(purist view : strict decoupling
of the data and control plane)
2. industry
(many-fold business-driven views)
SDN – Evolving Definition
14. What is SDN?
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.
-- Open Networking Foundation white paper
Software Defined Networking (SDN) refactors the relationship
between network devices and the software that controls them.
Open interfaces to network switches enable more flexible and
predictable network control, and they make it easier to extend
network function.
-- HotSDN CFP
15. What is SDN?
OpenFlow is SDN, but SDN is not OpenFlow
-- Networking community
(Does not say much about SDN)
Don’t let humans do machines’ work
-- Networking Professional
Let’s call whatever we can ship today SDN
-- Vendor X
SDN is the magic buzzword that will bring us VC funding
-- Startup Y
SDN is the magic that will get my paper/grant accepted
-- Researcher Z
16. “Canonical/Purist/Open” SDN
SDN is NOT:
•The ability to run code on switches
(e.g. open-source data planes)
•A single centralized controller
•OpenFlow
•Network Functions Virtualization (NFV)
•Distributed Control Plane + “SDN Hook”
•Unchanged Switches + “SDN Glue”
SDN is:
•An architecture for network control (not mgm) that
provides apps with a network view,
•with behavior defined (in SW) outside the
forwarding boxes.
Control-plane component(s) Data-plane component(s)
Source: SDN Academy
17. Industry-driven SDN definitions
Specifically, the definition of SDN has been broadened by the industry
to include the following additional directions:
•Overlay-networking using software tunnels:
– Vendors offer reconfigurable overlay networking rebranded as SDN
•Fabric-based networking:
– Network design governed by single policy front
•Open-source dataplanes:
– Using open-source software for firmware, router / vSwitch
implementations, programmable HW devices
•Extensible network management planes:
– Solutions that provide orchestration of services to automate integrated
network/cloud configurations
•Network-as-a-service:
– Solutions that make connectivity (e.g. VPN) more flexible and dynamic,
through a cloud service.
18. “Will OpenFlow commoditize networks? Impact Cisco margins?”
—Several media publications, Bloggers
“Google revamps networks with OpenFlow”
—ZDnet
Headlines
“Hype around SDN/OpenFlow getting way out of Control. Where have I seen this
before…” —Ethereal mind, Blogger
“.We share a more pragmatic view, noting Cisco (for example) is likely to view
SDN as a TAM expansion opportunity…” —Deutsche Bank Research note,
Wired, April 2012
“SDN needs a bigger definition”
—Lippis report, 2012
“Prediction: OpenFlow Is Dead by 2014; SDN Reborn in Network
Management”
—Mike Fratto, Network Computing
Source: Adapted from A. Retana @ Lacnog’12
SDN - Software Defined Not-working”
“SDN - Smells Dollars Now”
“SDN - Still Does Nothing”
19. SDN: The Frontier of Networking?
Existing
• CLIs
• Closed Source
• Vendor Lead
• Classic Network
Appliances
New
• APIs
• Open Source
• Customer Lead
• Network Function
Virtualization (NFV)
Adapted from: Kyle Mestery, Next Generation Network Developer Skills
20. SDN & Single Throat to Choke
Who provides solution support in a
decoupled SDN???
Switch Vendor?
Controller Provider?
Application Developer?
Apresentada pelos seus defensores como uma revolução na área de redes de computadores, até o momento sua grande aplicação é em redes de datacenter associada com a necessidade de virtualização da computação em nuvem. Não há clareza sobre a adequação de SDN para outros ambientes, como WAN, embora já existam alguns esforços, como a rede WAN interna do Google. Este painel irá discutir a situação atual do desenvolvimento de SDN, com as promessas, a realidade atual e as perspectivas para o futuro.
Source: Martin Casado CS244 Spring 2013, Lecture 6, SDN
Traditional distributed networks as we study in school, follow a clear layered design (OSI model) and a distributed model where
Forwarding: data plane
Directing a data packet to an outgoing link
Individual router using a forwarding table
Routing: control plane
Computing paths the packets will follow
Routers talking amongst themselves
Individual router creating a forwarding table
Compute: path costs to all nodes
From a source u to all other nodes
Cost of the path through each link
Next hop along least-cost path to s
Example: Link-state routing: OSPF, IS-IS
Flood the entire topology to all nodes
Each node computes shortest paths
Dijkstra’s algorithm
Source: Martin Casado CS244 Spring 2013, Lecture 6, SDN
Networks in practices add Management Plane to influence the network behavious
Broad definition of “network management”: Everything having to do with the control plane
Indirect control
Changing weights instead of paths
Complex optimization problem
Uncoordinated control
Cannot control which router updates first
Interacting protocols and mechanisms
Routing and forwarding
Naming and addressing
Access control
Quality of service
…
Networking suffers from the existing protocol “soup” that makes networking a complex engineering task.
The dependencies and interactions among these protocols makes very hard the introduction of even small changes.
Network innovation is endangered by this model, which in addition is a costly proposition to the industry (and research community) in the long term.
Source: Martin Casado CS244 Spring 2013, Lecture 6, SDN
Per-SDN model of Ethernet switches.
Vendor bakes in features to the on-board control plane.
Iinterface to switch control plane limited to vendor-specific CLI, SNMP, and TFTP. Abstraction of user-controllable features typically limited to the CLI and constrained to the "normal" behavior of 802.3 switches.
The path that has taken as to this complex soup of protocols in an industry with mainframe practices is that for every new control need or business goal feature, new data plane mechanisms have been defined (requiring changes in the data plane implementations) for which a new control plane needs to specified and broadly supported in the infrastructure. This recipe for disasters follows from doing these steps all over and over for every new networking idea to become operational
In addition, networking design has been majorly driven by physical constraints split in simple administrative domains. Todays needs of multi-tenancy in massively shared network plus compute infrastructures are not well addressed by physical network designs and require new ways for network protocol designs.
The OpenFlow protocol, conceived in Stanford, rapidly captured the attention of the industry and a lot of hype surrounded OpenFlow and originated the SDN term (coined by a journalist to refer to the OpenFlow approach to control networks).
The hype around OpenFlow grew steadily and soon it was believed (by many, mostly in the media) that OpenFlow alone could solve any problem in networking.
Withou doubts, OpenFlow was a foundamental trigger to think different about networking by refactoring the control plane functions and foster the communications between networking devices and applications influencing the control of the network.
In a few words, SDN is all about high flexibility in programming forwarding devices and decoupling the control and data plane.
These two interesting characteristics, which can be considered as key features, make software defined networks attractive for industry and academy.
With such features one can build less complex and more robust networks, solving old aging networking problems such as routing and mobility of devices (e.g. firewalls, middleboxes, security appliances, servers, user stations) and users. This is a light at the end of the tunnel for effectively transforming static and hard to change network infrastructures into flourishing environments, where flexibility is the main driver of a new pace of innovation.
Software development now dictates the speed of evolution and innovation in networking infrastructures. In other words, network advancements are not anymore constrained by the design, upgrade and deployment of networking devices.
A Software Defined Networking (SDN) has two key characteristics. First, a programmable data plane, where devices do not have any intelligence and can be dynamically programmed through an open and standard interface. Secondly, a well defined decoupling between control and data plane, removing control functionalities from devices to an external software based controller. These two characteristics pave the way of more flexible networking infrastructures, where innovation takes place in a new pace. Withal, an easily programmable data plane fosters the development of new solutions to old problems, such as those afore mentioned.
Conceptually, an SDN has a clear separation of concerns through three well defined abstractions, distribution, specification and forwarding.
Network devices are dummy, yet efficient, forwarding elements.
The distribution takes place on a logically-centralized controller (a.k.a. network operating system), where control communications are established with network devices and programming instructions are send to them.
Finally, specification is achieved through virtualization (abstract topology versions) as well as higher-level (domain-specific) programming languages and management applications. In these layers, policies are defined and translated to programming instructions for data plane devices.
Clean Separation of Concerns
Control program: express goals on abstract view
VirtualizationLayer: abstract view <-> global view
NOS: global view <-> physical switches
The trend in networking towards SDN is commonly compared to the trend that faced the Computer Industry with the definition of a standard interface to the hardware (x86 instruction set, ISA to microprocessors in general), the advent of virtualization on top of which multiple, parallel Operating Systems can be run, on top of which a myriad of Applications can be developed using standard interfaces (e.g. POSIX) and building upon software libraries and a ton of helpful software tools to ease application development, testing, etc.
SDN may go that far along in opening up the network and creating a similar layered and modular industry with horizontalization, open interfaces, and altogether benefiting from an industry model with rapid innovation cycles.
As time passed, SDN took over the role of OpenFlow as the “saver” of all problems in networking, or at least, the way to look forward to networking.
SDN has different meanings to different people, but no player in networking is allowed anymore to be indifferent to these three letters. In each product (and research) portfolio (roadmap) SDN needs to appear somehow.
The term “Software-defined Networking” was originally picked in 2009 by the journalist Kate Greene from MIT Tech Review to represent the activities around OpenFlow at Stanford University.
Source: http://www2.technologyreview.com/article/412194/tr10-software-defined-networking/
We can differentiate to big definitions for SDN, one academic, and one in the industry. Within those (especially the industry interpretations) different views that lead to further definitions of SDN have been used. We will discuss the most relevant features (and some motivations) for the different views and definitions of SDN.
Different SDN definitions
ONF : Industry-led
HotSDN : academic view
SDN means different things to different people.
The relation of OpenFlow to SDN is also unclear for many.
Many will use SDN as a buzz word for its own “agenda” i.e. business interests.
SDN MEANS DIFFERENT THINGS TO DIFFERENT PEOPLE
Overlay-networking using software tunnels: Vendors offer reconfigurable overlay networking rebranded their products to be based on SDN (irrespective of whether the state was decoupled from the data plane)
Fabric-based networking: Network design where one or more physical-switches and virtual-switches work together to form a single policy front is considered to be SDN (irrespective of decoupled control plane)
Open-source dataplanes: Using open-source software in the firmware (e.g., Pica8 Xorplus, Quagga), specialized programmable hardware devices (e.g., NetFPGA), and Open vSwitch are considered SDN (even if there is no decoupled control plane)
Extensible network management planes: OpenStack and other extensible network management solutions (e.g. Cyan Blue Planet) that provide orchestration of services are also considered an instance of SDN.
Network-as-a-service: VPN services have existed for many years, yet suffer long customer creation time and poor orchestration. Making connectivity more flexible and dynamic, through a cloud service, is SDN.
Where are things headed?
Customers are much more involved.
ONF
Open Compute
Customer involvement in upstream projects