SDN Myth Busters - The SDN Soup of Alternatives
Earlier posts in this mini-series discussed “why SDN,” what SDN is all about, and we examined SDN “components.” There are many “big” concepts in the SDN arena, so before we continue, let’s take a second to reflect on what we’ve already discussed.
- I have the sense that many people have a predefined concept of SDN as being a protocol or a product. When I’m faced with these kinds of situations, I ask people to step back and ask, “What do we need to get done and how can SDN do it more efficiently?” It’s perhaps no surprise that people struggle to answer this question. That’s possibly because administrators are focused on the technology implementation, so new acronyms and protocols sound cool – especially when they are making claims that promise something akin to a networking utopia.
- The reality is that the first step to SDN needs to be a business process design. Can OpenFlow by itself radically improve business operations? Is the investment required to leverage OpenStack’s capabilities going to deliver a tangible ROI (return on investment)? I think that many SMB Enterprises might well find out that the answer is a “No, maybe, perhaps, I just don’t know.”
- In 2010, Alcatel-Lucent Enterprise launched its Application Fluent Network (AFN) strategy. The fundamental concept of AFN is that networks need to better understand business applications in an intelligent, dynamic manner, whilst optimizing the configuration and maintenance of services. If that sounds familiar then you’d be right. This is the essential aim of SDN.
- A key to developing a successful SDN methodology is keeping in mind the balance between what your strategy costs in terms of investment versus the real benefits that can be achieved.
In this next section, we’ll look at a couple of AFN solutions that provide exactly what SDN means - visibility, agility and intelligent networking.
With ever-increasing access to wireless networks, users expect their experience will be identical, independent of whether or not they connect to via a wired or wireless medium. Already some years back, we introduced the User Network Profile (uNP) for OmniSwitch. A uNP is an object that contains all the connectivity parameters (VLAN, QoS, ACLs) that are required for user access and connectivity to the network. When a user connects, a uNP is returned to the switch and all network parameters are dynamically configured. Now doesn’t that sound a lot like a guiding principal of SDN?
Unified Access brings homogeneity to this process to both the LAN and WLAN environments. In other words, the network is aware of a user’s connection parameters for both environments. Remember that this is not just a VLAN we’re talking about here, but also all the QoS required for a user’s business applications, such as voice, multimedia, and the Internet. OmniVista 2500 provides a singular portal to configure uNP and track users across both mediums.
OmniVista 2500 Virtual Machine Manager (VMM)
Compute virtualization is one of the major reasons why networks need to evolve. Virtualization means that compute resources are elastic and can be rapidly deployed and even redeployed to meet business needs. The problem is that networks aren’t so elastic (see Part II) and typically network and server operations are independent teams. To address this we leveraged the uNP concept, to deliver Virtual Network Profiles (vNP). Again, this is a network object that acts as a container for all networking parameters for a virtual machine (VM).
However in this case, vNP means that the glass might be seen as only half full (or half empty – depending on who you ask). How would the network know what vNP needs building for what VM? This is the job of OmniVista 2500 Virtual Machine Manager (VMM). It seamlessly integrates with virtualization hypervisors and has a complete picture of what VMs exist. As VMM also has simultaneous visibility into the network, it is in a unique position to blend together information about the VM’s requirements as well as the network resources available to deliver the necessary connectivity, QoS and ACL control. With all this data in hand, the network administrator can easily build vNPs that dynamically adapt the network for the VMs. I don’t want to say it, but doesn’t this all sound terribly familiar?
If you think about it for a moment, the intelligence, programmability and visibility afforded by uNP, vNP and VMM are just what SDN looks to achieve, however they are features and tools that come “canned” out of the box. If I had to summarize SDN here, then I would conclude that whatever methodology you choose to adopt, really think about what the tangible benefits of it are for your network, applications and users. SDN doesn’t have to mean that we forget everything we have, but rather use it in a better, more efficient manner than ever before.