Are you looking to get up to speed on the benefits of a Software Defined Network? This post will save you some time by providing 8 areas where SDNs promise to deliver. It will also provide you with a few links where you can learn even more about the technology.
1. Inexpensive: The ability to purchase inexpensive switches that have very little resident software and processing needs may not be realized by all companies. Certainly we want to save money however, you can bet that switch vendors will build in proprietary features into their SDN offerings in an effort to rise above the sea of “me to” offerings. These features include things like authentication, NetFlow, IPFIX, behavior analysis, etc. Although SDNs promise the ability to work with less expensive switches, in all likely hood, many consumers will opt for a bit more pricey system in order to gain:
A. Security: a more secure infrastructure by distributing the threat detection effort. SDNs could scale the cyber threat monitoring responsibility to add-on protection appliances.
B. Performance: insight into traffic will help us confirm that both the control and data planes are doing their job to optimize performance. NetFlow and IPFIX support will allow administrators to verify load balancing, latency levels and other responsibilities. Nothing I’ve seen to date comes close to rivaling Cisco’s AVC flow export.
2. Centralization: Centralization of the forwarding Information Base or FIB, allows optimum routes to be calculated deterministically for each flow: end-to-end across the topology. Because the controller has complete visibility, it can see what traffic looks like end to end for a connection request. Based on priorities, it can program the ideal route through the infrastructure.
Despite claims by some hard core SDN advocates that all forwarding decisions will be made by the controller, there are equally convincing positions on why much of the forwarding logic will remain at the switch/router (e.g. application recognition). Regardless of where the final path decision is made, both sides agree that the controller will play a major role in standardizing the policies (e.g. Access Control Lists) of which all networking gear adheres to.
3. Dynamic: SDNs dynamically respond to application requirements. Here is one place where vendors will set themselves apart. Depending on the application, a Software Defined Network promises to optimize end user experience based on configurable policies. Since many applications seem to mimic each other’s behavior, often times several packets must be observed before the application can be identified. The switch, router or firewall will have to perform Deep Packet Inspection (DPI) to make this assertion. Examples of applications include: Salesforce.com, YouTube, Amazon, Akami, iTunes, etc. Applications like these will receive different priorities an in all likely hood, the controller won’t be figuring this out. If connection speeds are a business concern, ascertaining the application involved will likely be performed at the switch. Consumers will want to ask for features like Cisco NBAR.
4. Optimize: SDNs optimize the utilization of the network without sacrificing service quality. For business critical applications, SDNs provide optimal connections. If a path becomes saturated whereby end user experience starts to slip, connections can be dynamically rerouted. The big goal here is to maintain service quality. Few business managers want connections to Salesforce.com to be fighting against the iPhone requests to iTunes. Non-essential traffic can take a back seat in Software Defined Networks. This can be compared to Performance Routing.
5. Filter: SDNs can filter packets as they enter the network and hence these switches can act as simple firewalls at the edge of the network. Again, this is another area where some intelligence needs to remain at the switch. For example, end systems shooting out nonsense broadcasts can be isolated at the ingress interface and the decision to do so will likely be made at the switch. The thought of pushing this type of traffic up to the controller for a decision is almost asinine. Without some filtering being performed at the switch, a type of connection request throttling at the edge will be necessary.
6. Redirect: SDN switches can redirect certain suspicious traffic flows to higher-layer security controls, such as IPS systems, application firewalls, and Data Loss Prevention (DLP) devices. There is no doubt that security will play a more significant role in SDNs. If the controller or switch observes a suspicious traffic pattern, the traffic could be redirected or perhaps even replicated over to a threat detection appliance for further analysis. Behavior monitoring and signature matching functions are likely to stay independent of the controller.
7. Load-Balancing: SDN switches that support the modification of packet headers will also be able to function as a simple, cost-effective load-balancing device. With SDNs delivering more control over the network, companies can do a better job optimizing bandwidth consumption and potentially gaining greater ROI as google has done.
“we're able to run our wide-area lines at close to 100% utilization, just through careful traffic engineering and prioritization. In other words, we can protect the high-priority traffic in the case of failures with elastic traffic that doesn't have any strict deadline for delivery. We can also route around failed links using non-shortest path forwarding, again with the global view of network topology and dynamically changing communication characteristics.”
8. Fault Tolerance: SDN Controllers can be clustered for fault tolerance and high availability.
Since failure is not an option, SDNs deliver on redundancy with no single point of failure.
Take 5.21 minutes and watch this YouTube video which answers the question “What is a Software Defined Network”.
It also touches on the 8 benefits listed above but, with animation to help explain technical concepts.
On a final note: Some of you might have hear about OpenFlow which is not synonymous with Software Defined Networks. OpenFlow rather, is a control protocol which will likely be supported by most vendors. However, because it is the proprietary features that set competing vendors apart, expect unique flavors of control protocols to emerge. This is a good thing.