Google “SDN” and you’ll find a number of excellent resources like this page on Tech Target’s SearchSDN that explain the key objective of software-defined networking is to deliver cost-effective automated orchestration of networks that matches the level of automation and performance in cloud computing. But that’s a philosophy, not a solution. That doesn’t turn networking into a single problem that needs to be solved, it just provides a high-level description of how we want the network to function. Just as cluster computing and cloud computing kind of look the same but have very different characteristics, so too do the diverse uses of networks drive the requirement for differentiated solutions. So let me propose a simpler explanation of what SDN should represent.
What we’re really looking for is a network that can be managed and orchestrated like a cloud computing environment, but that has the right performance characteristics at each point in the network – the characteristics are there, the orchestration layer can function properly without hitting limitations based on the physical network. And make no mistake, the physical network really matters.
Data center, ISP, and service provider network architects need to migrate to networks that meet three requirements. They need performance (the ability to move data quickly), flexibility (the ability to reconfigure quickly and easily to meet changing demands) and internet scale (the ability to deal with millions of flows and very lumpy traffic patterns without dropping traffic). The industry has responded with software-defined networking (SDN).
As I mentioned in my last post “Performance SDN,” most SDN offerings come in one of three flavors, value-SDN, bolt-on SDN or software-controlled networking (SCN).
Selecting one of these always leaves you with a compromised solution. No matter which one you pick, you must also choose which one of the three requirements to sacrifice – which doesn’t make sense.
We eliminate that Sophie’s Choice with our suite of performance SDN products that offer performance, flexibility, and scale. However, we need to implement one more key capability in order to deliver the “real” part of “real SDN.”
We offer the total solution with open interfaces, which enables the hardware to communicate with any software solution, no matter if it’s vendor-coded or open-source. This capability delivers cost-effective, automated, and dynamic networking along the same lines as cloud computing.
A common issue we hear from customers from a requirements perspective is that they have 5 key attributes for an open SDN WAN solution. Interestingly, these attributes are a mix of physical performance requirements that are WAN-specific, not SDN-specific, that must be combined with SDN attributes to make the network “real” SDN.
Let’s take a look at these five requirements straight from our customers’ mouths:
- 100G ports that are SDN-enabled.
- Deep packet buffers – to deal with congestion and session windows that are dropping large amounts of traffic which seriously reduces the effective bandwidth of the link.
- Fully open SDN programmability in order to define a service offering – the ability to control the hardware via an open interface to deploy the right protocols at the right places to offer efficient, differentiated services, which requires enormous flexibility on both the match capabilities and the action capabilities.
- Internet scale flow table capacity – if you think of BGP for example, you need to deal with over a half million ipv4 addresses.
- Very fast flow update capability – in the 10’s of thousands of flow mod updates per second if you are offering real-time orchestration capabilities.
This is where the Corsa solution shines – we designed it from the ground up to have the physical attributes required for the WAN – the high-speed ports, the deep packet buffers, but we then designed the forwarding plane to be incredibly open and flexible at the software/firmware and hardware levels so customers could define multiple personalities in the same piece of hardware.
To that end, customers have deployed the same hardware as a BGP Gateway, as an MPLS LER, as a router bypass solution for big data flows, as a bandwidth on demand solution, and in a multi-vendor, multi-layer packet optical network application based on ONOS, just to name a few.
What do you think about the five requirements to make the WAN edge real SDN – do you agree all five are a “must have,” and are we missing any additional requirements?