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
- quick experimenting and optimization of switching/routing policies, and for
- external access to the innards of switches and routers that formerly were closed and proprietary.
Contents |
Background
| This article or section reads like an editorial or opinion piece. (May 2012) |
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 hand. This 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 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. 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 applying globally 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 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 are. It 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 country.state.zip.street 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 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.
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.
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].
See also
References
- ^ "Open Networking Foundation".
- ^ Kate Greene (March/April 2009). "TR10: Software-Defined Networking". Technology Review (MIT). Retrieved November 20, 2011.
扫一扫
854
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
