Followers of Software Defined Networking (SDN) might recognize a sort of market maturation. We don’t mean maturity of the product sets, or even how SDN is technically achieved. Those elements are still coming along. We mean vendor SDN strategies are settling in.
Cisco is firmly committed to its Application Centric Infrastructure (ACI) strategy, aggressively marketing the new technology as it gets ready for ACI’s general availability. VMware’s NSX SDN approach has the distinction of running in production environments. And even startups like Big Switch Networks and Plexxi continue to find matches for their technology with customer needs.
That said, the most interesting part of SDN isn’t SDN itself; these days, what’s grabbing attention is the rich functionality SDN is enabling. Network engineers have grabbed hold of the fact that automation of network provisioning is a critical function enabled by SDN.
Another function SDN enables is dynamic reaction to changing network conditions. An interesting example of this is the rise of the software defined WAN, in which a major value proposition is the ability to route traffic across a mix of Internet, private WAN circuits, or LTE dynamically, depending on the quality of the transport. Software defined WAN solutions are able to react to changing network conditions in real-time with no manual intervention on the part of network operators.
Yet another key function of SDN, and the function we’ll focus on for the rest of this article, is the ability for applications to interact with the network. The key here is the development of APIs that provide a way for applications that traverse a network to communicate their needs to that network. We’ll look at some examples of this in a bit.
Software defined networking is important not because it’s clever, difficult for vendors to create, or academically interesting. Rather, SDN is an enabling technology. Much like a foundation enables a building to be erected, SDN is a foundation that enables new network functionality. A key to understanding why an organization should invest in an SDN-capable network is because of what will be possible as more and more applications are developed that interact with the network.
A network becomes a living thing when powered by applications. SDN is the catalyst allowing applications and networks to react to each other. Network vendors are well aware of this and have built ecosystems around their SDN platforms. By “ecosystems,” we mean vendors have formed strategic partnerships with third-party vendors to enable applications and other network devices to take part in their SDN system. Let’s take a look at some of the SDN ecosystems, note the partnerships, and highlight some key functionality brought about as a result.
HP has been a leader in the SDN space for sometime, delivering OpenFlow functionality across more than 50 of the switches in its portfolio, as well as an SDN controller it calls the Virtual Application Networks (VAN) SDN controller. HP has built its partner ecosystem around VAN, as well as an SDN app store that is unique in the network industry.
Like Apple does with apps that are submitted for inclusion in its app store, HP certifies SDN apps that are submitted to its app store so enterprise customers can be confident the apps will work reliably on their HP network infrastructure. What HP has done is build an SDN consumption model that makes adding SDN functionality to the network as simple as could be imagined for IT departments. While this is an HP-specific ecosystem, the model underscores the power of SDN: improve network functionality by adding applications to an extensible network framework.
One example of a third-party that is leveraging HP’s SDN ecosystem is Guardicore. Guardicore has developed a security function it describes as an active honeypot. In security, a honeypot is a fake host intended to capture the attention of a probing intruder. The intruder is occupied, thinking it has found a point of vulnerability, when in fact the honeypot neither houses nor provides a gateway to valuable data. The honeypot is a trap. The problem with legacy honeypots is that they wait for intruders to stumble upon them. In the Guardicore/HP active honeypot model, intruders are purposely directed to the honeypot, making the honeypot a much more effective trap.
The way the Guardicore solution works, network traffic is profiled; network mapping behavior is detected by monitoring connections dropped by existing security check points in the network. Rather than allowing the dropped connections to be blocked, Guardicore asks the VAN controller to redirect that traffic to the active honeypot, which then holds the interest of the malware app. As the app continues to probe the honeypot, Guardicore algorithms can infer the malware’s behavior and work with VAN to contain the threat and install tighter security policies to further mitigate it.
With Application Centric Infrastructure (ACI), Cisco has created a broad SDN vision that will eventually be capable of managing the entire data center. While ACI execution is still early, Cisco is already working with a large number of partners to integrate their applications and services with an ACI-capable network. Cisco has termed this an “open ecosystem,” clearly eyeing the industry at large as potential partners. This makes sense, as Cisco has a great deal of competition in the SDN space. A large partner ecosystem is a possible encouragement towards adoption, enticing consumers to spend their network upgrade dollars on ACI-enablement.
Part of the partner enablement strategy is OpFlex, which Cisco describes as a protocol used to express policy between network devices up and down the stack, as well as to a network controller. OpFlex is important, because Cisco has opened it to the industry as an IETF draft, meaning vendors that wish to integrate with ACI can use OpFlex. If OpFlex sees wide industry adoption, the ACI ecosystem will continue to grow. This is key to understand, as many third-party vendors believe Cisco ACI is an appropriate technology to integrate with. Why? It’s hard to bet against Cisco, especially when it’s clear that the ACI vision is gathering momentum.
One example of a third-party vendor that has integrated with ACI is Embrane. Embrane is an SDN startup tackling the challenge of virtual application life-cycle management. The setup, teardown and license management of virtual appliances is a complex task.
Initially a concern for cloud providers and IaaS shops, the problem has trickled down into enterprises as organizations continue to virtualize their infrastructure. Practically speaking, the tracking of hundreds or thousands of virtual appliances with transient existences must be automated. The Embrane Elastic Services Manager (ESM) does this work, and integrates with ACI while doing so.
The integration between Embrane and ACI is achieved via ESM and Cisco’s APIC (Application Policy Infrastructure Controller). ESM and APIC know about each other, using bi-directional communication to make the other aware of their capabilities and state. For example, as new services are added to ESM, ESM notifies APIC so the new service is added to the ACI services catalog. The result is a virtual infrastructure that can be automatically deployed. Not only will ESM spin up and down virtual network appliances as required, it will also request network resources from APIC, such that a completely virtualized application environment will be created across the physical network infrastructure.
Big companies aren’t the only ones developing ecosystems. SDN startup Plexxi has partnerships with a growing number of vendors that integrate with its controller and photonic switching environment. Plexxi’s SDN logic is built around the concept of affinities, where Plexxi traffic analysis can automatically determine the requirements of traffic flows between two endpoints and implement appropriate policies across its optical backbone. Plexxi’s core algorithms build an optical topology between its switches that “fit” the network requirements. This process of fitting the network based on discovered affinities can be informed directly by applications traversing the Plexxi network.
One vendor taking advantage of Plexxi affinities is SolidFire. SolidFire makes SSD storage clusters, and the storage nodes in the cluster demand a guaranteed path between them across the network infrastructure. Plexxi discovers SolidFire endpoints via a connector using a REST API that reads the SolidFire topology published in JSON format. The Plexxi controller receives this data from the connector and learns where all the SolidFire cluster members are in the network. The Plexxi controller then builds affinities between the SolidFire cluster members to guarantee their traffic flows. The result is a self-contained storage network with a guaranteed QoS without having to build a physically separate network.
There are other SDN vendor ecosystems. For instance, VMware has a list of strategic partners for its NSX platform, an SDN solution that has been shipping since late 2013. One NSX ecosystem partner is Palo Alto Networks, whose virtual firewall appliance can be inserted into the data stream of a virtual NIC by NSX, allowing PAN’s application layer firewall to secure virtual hosts.
Big Switch Networks is another. This SDN startup has an interesting partner ecosystem, including a long-standing relationship with F5 Networks. One of Big Switch’s main applications is its “Big Virtual Switch” which presents an OpenFlow-capable network infrastructure as one logical switch that can be managed centrally.
Users of F5’s application delivery controller are aware that the platform functions not only as a simple load-balancer, but also as an application level service delivery platform.
An F5 Local Traffic Manager (LTM) is able to deliver a rich set of data manipulations and application delivery templates. Integration between Big Virtual Switch and F5 LTM enables the Big Virtual Switch to steer traffic to the LTM, tracking all of the IP addresses and MAC addresses of the LTM infrastructure, as well as informing the LTM of the network topology. The result is automation of network infrastructure configuration inside of the Big Virtual Switch to support an F5-based application deployment.
In the open source community, the OpenDaylight (ODL) project continues to attract new members who wish to leverage the ODL controller for their applications. As ODL grows in scope and matures in usability, it could become the de-facto standard for application integration in the SDN world. The ODL membership list is one to watch.
What’s a consumer to do?
Consumers shopping for an SDN solution need to keep an eye on vendor ecosystems as they continue to develop. Since SDN is a means to an end, but not the end in itself, the partnerships become quite significant. What, exactly, can be achieved with the SDN capabilities of a given network? The answer should map to an organization’s specific needs. Not every vendor will have an SDN solution that makes sense for every organization; SDN is decidedly not one-size fits all. Therefore, organizations evaluating SDN should carefully investigate vendor ecosystems to understand how they fit into their other network service alignments. It’s possible that a customer’s existing relationship with a third-party vendor will direct them towards one vendor’s SDN solution or another.