From Wikipedia, the free encyclopedia
Software-defined networking (SDN) is an approach to computer networking which evolved from work done at UC Berkeley and Stanford University around 2008. SDN allows network administrators to manage network services through abstraction of lower level functionality. This is done by decoupling the system that makes decisions about where traffic is sent (the control plane) from the underlying systems that forward traffic to the selected destination (the data plane). The inventors and vendors of these systems claim that this simplifies networking.
SDN requires some method for the control plane to communicate with the data plane. One such mechanism, OpenFlow, is often misunderstood to be equivalent to SDN, but other mechanisms could also fit into the concept. The Open Networking Foundation was founded to promote SDN and OpenFlow, marketing the use of the term cloud computing before it became popular.
Internet Protocol (IP) based networks were initially built based on the notion of Autonomous Systems (AS). This notion allows networks to scale and extend by connected junctions that forward packets to a reasonable next hop based on partial need-to-know information. This approach to networking is simple, and has proven resilient and scalable. The AS principle does not allow the designated destinations to move without changing their identity as far as the packet delivery service is concerned. The topological location of destinations, which is the network interface they are attached to, dictates their identity. In addition, using only basic AS, it is hard to specify other identity qualities, such as logical grouping, access control, quality of service, intermediate network processing, or to specify aspects that relate to a sequence of packets that form a flow or networked conversation.
Complementary standards by the Internet Engineering Task Force (IETF) were put in place to augment identity-specific needs, standards such as virtual LANs and virtual private networks, among many others. These incremental standards have increased complexity in network element specifications and configuration of network interfaces by network operators.
As elastic cloud architectures and dynamic resource allocation evolve and as mobile computer operating systems and virtual machines usage grows, the need has arisen for an additional layer of software-defined networking (SDN). Such a layer allows network operators to specify network services, without coupling these specifications with network interfaces. This enables entities to move between interfaces without changing identities or violating specifications. It can also simplify network operations, where global definitions per identity do not have to be matched to each and every interface location. Such a layer can also reset some of the complexity build-up in network elements by decoupling identity and flow-specific control logic from basic topology-based forwarding, bridging, and routing.
The global software defined control also tracks specific flow contexts based on source and destination identity aspects. A mechanism for driving network hardware has been added and adopted by network equipment manufacturers for the purpose of sharing edge driving between software-defined edge and vendor-specific bridging and routing. A set of open commands for forwarding was defined in the form of a protocol known as OpenFlow. The OpenFlow protocol enables globally-aware software controllers, which may be centralized or distributed, to drive the network edge hardware in order to create an easily programmable identity-based overlay on top of the traditional IP core.
SDN is a step in the evolution towards programmable and active networking. SDN allows network administrators to have programmable central control of network traffic via acontroller without requiring physical access to the network’s switches.  A configuration of SDN can create a logical network control plane where hardware is physically decoupled from the data forwarding plane hardware, i.e. a network switch can forward packets and a separate server can run the network control plane. The decoupling allows for the control plane to be implemented using a different distribution model than the data plane. Control plane development and runtime environment tasks can then be run on a different platform (other than the low-powered management CPUs found on hardware switches and routers).
SDN deployment models
- Symmetric vs asymmetric
- In an asymmetric model, SDN global information is centralized as much as possible, and edge driving is distributed as much as possible. The considerations behind such an approach are clear, centralization makes global consolidation a lot easier, and distribution lowers SDN traffic aggregation-encapsulation pressures. This model however raises questions regarding the exact relationships between these very different types of SDN elements as far as coherency, scale-out simplicity, and multi-location high-availability, questions which do not come up when using traditional AS based networking models. In a Symmetrically distributed SDN model an effort is applied to increase global information distribution ability, and SDN aggregation performance ability so that the SDN elements are basically one type of component. A group of such elements can form an SDN overlay as long as there is network reachability among any subset.
- Floodless vs flood-based
- In a flood-based model, a significant amount of the global information sharing is achieved using well known broadcast and multicast mechanisms. This can help make SDN models more Symmetric and it leverages existing transparent bridging principles encapsulated dynamically in order to achieve global awareness and identity learning. One of the downsides of this approach is that as more locations are added, the load per location increases, which degrades scalability. In a FloodLess model, all forwarding is based on global exact match, which is typically achieved using Distributed Hashing and Distributed Caching of SDN lookup tables.
- Host-based vs Network-centric
- In a host-based model an assumption is made regarding use of SDN in data-centers with lots of virtual machines moving to enable elasticity. Under this assumption the SDN encapsulation processing is already done at the host HyperVisor on behalf of the local virtual machines. This design reduces SDN edge traffic pressures and uses “free” processing based on each host spare core capacity. In a NetworkCentric design a clearer demarcation is made between network edge and end points. Such an SDN edge is associated with the access of Top of Rack device and outside the host endpoints. This is a more traditional approach to networking that does not count on end-points to perform any routing function.
- Some of the lines between these design models may not be completely sharp. For example in data-centers using compute fabrics “Big” hosts with lots of CPU cards perform also some of the TopOfRack access functions and can concentrate SDN Edge functions on behalf of all the CPU cards in a chassis. This would be both HostBased and NetworkCentric design. There may also be dependency between these design variants, for example a HostBased implementation will typically mandate an Asymmetric centralized Lookup or Orchestration service to help organize a large distribution. Symmetric and FloodLess implementation model would typically mandate in-network SDN aggregation to enable lookup distribution to a reasonable amount of Edge points. Such concentration relies on local OpenFlow interfaces in order to sustain traffic encapsulation pressures.
One application of SDN is the infrastructure as a service (IaaS).
This extension means that SDN virtual networking combined with virtual compute (VMs) and virtual storage can emulate elastic resource allocation as if each such enterprise application was written like a Google or Facebook application. In the vast majority of these applications resource allocation is statically mapped in inter process communication (IPC). However if such mapping can be expanded or reduced to large (many cores) or small VMs the behavior would be much like one of the purpose built large Internet applications.
Other uses in the consolidated data-center include consolidation of spare capacity stranded in static partition of racks to pods. Pooling these spare capacities results in significant reduction of computing resources. Pooling the active resources increases average utilization.
The use of SDN distributed and global edge control also includes the ability to balance load on lots of links leading from the racks to the switching spine of the data-center. Without SDN this task is done using traditional link-state updates that update all locations upon change in any location. Distributed global SDN measurements may extend the cap on the scale of physical clusters. Other data-center uses being listed are distributed application load balancing, distributed fire-walls, and similar adaptations to original networking functions that arise from dynamic, any location or rack allocation of compute resources.
Other uses of SDN in enterprise or carrier managed network services (MNS) address the traditional and geo-distributed campus network. These environments were always challenged by the complexities of additions, changes, mergers, acquisitions, and movement of users. Based on SDN principles, it is expected that these identity and policy management challenges could be addressed using global definitions decoupled from the physical interfaces of the network infrastructure. On the other hand, existing infrastructure of potentially thousands of switches and routers can remain intact.
It has been noted that this “overlay” approach raises a high likelihood of inefficiency and low performance by ignoring the characteristics of the underlying infrastructure. Hence, carriers have identified the gaps in overlays and asked for them to be filled by SDN solutions that take traffic, topology, and equipment into account.
Remote access to the control plane is made available to administrators or users of the network, typically with a role-based access control (RBAC) in order to provide security.
- Software-defined data center
- Frenetic (programming language)
- Network Functions Virtualization
- Active Networking
- Intel Data Plane Development Kit (DPDK)
- Jump up^ “Prof. Scott Shenker – Gentle Introduction to Software-Defined Networking – Technion lecture”. YouTube. 2012-06-26. Retrieved 2014-01-23.
- ^ Jump up to:a b “Software-Defined Networking: The New Norm for Networks”. White paper. Open Networking Foundation. April 13, 2012. Retrieved August 22, 2013.
- Jump up^ “What is software defined networking (SDN)?”. Networkworld.com. 2012-08-29. Retrieved 2014-01-23.
- Jump up^ http://yuba.stanford.edu/~jnaous/papers/ancs-openflow-08.pdf
- Jump up^ “Reactive, Proactive, Predictive: SDN Models | F5 DevCentral”. Devcentral.f5.com. Retrieved 2014-01-23.
- Jump up^ Tom Nolle (2013-04-26). “Three models of SDN explained”. Searchcloudprovider.techtarget.com. Retrieved 2014-01-23.
- Jump up^ “Google’s software-defined/OpenFlow backbone drives WAN links to 100% utilization”. Networkworld.com. 2012-06-07. Retrieved 2014-01-23.
- Open Networking Foundation’s definition of SDN
- Prof. Nick Feamster’s Coursera Course on SDN
- Floodlight, an open source Java based OpenFlow controller
- Network Function Virtualization (NFV)
- Decoding SDN
- Open Daylight Project
- Original Patent
- Original Patent
- Software Defined Networking (SDN) for the non-technical
- Contextream – The first cloud-based network virtualization framework for carriers
- Operational Opportunities and Challenges of SDN/NFV Programmable Infrastructure – a report from the ATIS Technology and Operations Council