Software Defined Networking
Software Defined Networking
Software defined networking (SDN) is an emerging architecture for computer networking. SDN separates the
control plane from the data plane in network switches and routers. Under SDN, the control plane is implemented in
software in servers separate from the network equipment and the data plane is implemented in commodity network
equipment. OpenFlow is a leading SDN architecture.
Thus SDN allows for
1. quick experimenting and optimization of switching/routing policies, and for
2. external access to the innards of switches and routers that formerly were closed and proprietary.
Background
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. The AS principle works much like the traditional post office service,
where a postal worker in London does not need to know all the tenants of all the streets in San Francisco in order to
choose a reasonable next hop for a letter at [Link] approach to networking is simple, and has proven resilient and
scalable.
The AS principle however has a few known drawbacks. It does not allow the designated destinations, or tenants with
home mail-boxes, 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 ishard 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. Adding such
incremental standards tends to build-up complexity in network elements specifications and it translates to
increasingly complex configuration of network interfaces by network operators, interfaces where most of these
specifications must be coupled with.
As elastic cloud architectures and dynamic resource allocation evolves, and as mobile computer operating systems
and virtual machines usage grows, the need rose 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.
Software-defined networking decouples network control (learning and forwarding decisions) from network topology
(junctions, interfaces, and how they peer).
The basic approach to achieve that is by applyingglobally aware and topology decoupled software control at the
edges of the network. The assumption is that traditional topology-coupled bridging & routing drives the core of the
network so that scalability, interoperability, high-availability, and extendability of IP networks can be maintained.
Using the analogy of a postal service, the way SDN controllers would work is - for any given street location, all the
letters from all the tenants would first be aggregated by an SDN edge. This edge function would examine the current
location for each of the letter-destinations using a global non-autonomous lookup mechanism. Based on that global
lookup and on other globally defined and globally measured considerations - such as access control or remote
Software Defined Networking
location load conditions - the SDN edge places one or more of the original letters in an additional envelope
addressed to each of the street locations where the destinations currently [Link] then uses the normal postal service
which works like traditional IP to get these outer envelopes to the remote locations. This is done based on the
existing and scalable hop-by-hop forwarding [Link] postal service. The outer letters are then opened
by the remote SDN edge and the original envelopes are delivered to the destinations.
The global software defined control also tracks specific flow contexts based on source and destination identity
aspects. Using the analogy example this Edge overlay service will differentiate between a remote chess game carried
over small, non-urgent yet lossless postcards Vs a massive transfer of consecutive legal documents that need to be
rushed one after the other to the remote destination.
A mechanism for driving network hardware is has been added and adopted by network gear 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 (OF). The OpenFlow
protocol enables globally aware centralized or distributed software controllers to drive the network edge hardware in
order to create an easily programmable identity based overlay on top of the traditional IP core.
SDN deployment models variants
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 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 down sides 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 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
Software Defined Networking
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 [Link] 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.
Market applications
One of the most talked about applications of SDN is the consolidated data-center. The first use-case example has
been Infrastructure as a Service (IaaS). In this example organizations and individuals are buying virtual machines
(VM) whenever they need to. This dynamic pattern creates a complete shuffle of where these VMs are located in the
IaaS provider data-center, yet these need to function as if they were neatly organized in groups per IaaS customer is
spite of the random order by which they were allocated.
The above basic use of SDN can be extended to almost any application, carrier or enterprise, in a private cloud or
Application as a Service cloud. 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. Such
behavior spells movement of resources while retaining original IPC identity.
Other uses in the consolidated data-center include consolidation of spare capacity stranded in static partition of racks
to pods. These partitions are put up mostly in order to control and scale connectivity based on traditional networking.
Spare capacity in each one is used for software upgrades, broken gear, and temporary growth. Pooling these spare
capacities results in significant reduction of compute 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.
Key uses of SDN are emerging in the carrier space, specifically in access services. Carriers support public access by
millions of subscribers. A need that inherently has a large degree of mobility, movement, and change. A considerable
amount of in-line processing, that makes public network access controlled, safe, and economically viable, is placed
based on anticipated capacity of where subscribers would "show-up". Such static mapping requires complex
planning and creates a slow rollout process, and is typically expensive and built for anticipated peak usage in each
location. An SDN design can steer traffic based on subscriber and application to the right in-line processing using
global overlays that share these resources between locations. This reduces the costs and expedites the roll-out of
fixed and mobile access services.
Other anticipated carrier access use of SDN relate to what has been coined as the Internet of Things (IoT) or
Machine to Machine (M2M). Under this vision the amount of end-points accessing the Internet will grow to include
"things" such as home-appliances, cars, doors, lights, personal health monitors etc. This will increase significantly
the amount of addressable identities connected to the net, but it has to be done in extreme efficiency and low cost. In
this scenario traditional networking is still used to reach the existing access locations but the complexity of increase
in the number of identities and end-to-end polices applied to these identities will be handled by the distributed global
software abilities of SDN.
Software Defined Networking
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
moves-adds-changes, mergers & acquisitions, and movement of users. Based on SDN principles, it expected that
these identity and policy management challenges could be addressed using global definitions and decoupled from the
physical interfaces of the network infrastructure. In place infrastructure on the other hand of potentially thousands of
switches and routers can remain intact.
Access Control in SDN
Remote access to the control plane is made available to administrators or users of the network, typically with a
role-based access system (RBAC) in order to provide security.
Decoupling between data plane access and control plane access
In one configuration of SDN, the network control plane hardware can be 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 rationale for this approach is twofold. First, the decoupling allows for the control plane to be implemented using
a different distribution model than the data plane. Second, it allows the control plane development and runtime
environment to be on a different platform than the traditionally low-powered management CPUs found on hardware
switches and routers.
SDN requires some method for the control plane to communicate with the data plane. One such mechanism is
OpenFlow which is a standard interface for controlling computer networking switches. OpenFlow is often
misunderstood to be equivalent to SDN, but there is no requirement for the use of OpenFlow within an SDN.
Definition and marketing of SDN and OpenFlow is managed by the Open Networking Foundation.[1]
The term was coined by Kate Greene[2].
References
[1] "Open Networking Foundation" (http:/ / www. opennetworking. org/ ). .
[2] Kate Greene (March/April 2009). "TR10: Software-Defined Networking" (http:/ / www. technologyreview. com/ biotech/ 22120/ ).
Technology Review (MIT). . Retrieved November 20, 2011.
External links
Software-Defined Networking: The New Norm for Networks ([Link]
stories/downloads/white-papers/[Link])
Article Sources and Contributors
Article Sources and Contributors
Software Defined Networking Source: [Link] Contributors: Alain Pannetier, Andyjsmith, Back ache, Bearcat, Dougher, Glaucus, Heading,
JnRouvignac, Kvng, Malcolma, Martincasado, MeekMark, Mild Bill Hiccup, Morning Sunshine, Mwehle, Nageh, Nyavatar, Phileasson, SlubGlub, W Nowicki, 27 anonymous edits
License
Creative Commons Attribution-Share Alike 3.0 Unported
//[Link]/licenses/by-sa/3.0/