Recently Cisco released their Application Centered Infrastructure (ACI) product line so all of the vendors in the SDN industry started to criticize them sharply for delivering both an hardware centered designed as well as being proprietary. What is going in the SDN world in terms of following standards? First of all Cisco is part of all the major standard bodies and is quiet very active.
Lets put this another way; are there any standard solutions out there in the market today? People talk a lot about VMware NSX but that is not standard its based on VMware own APIs and implementation of protocols. Taking that into consideration, what Cisco is doing is not so far off from the rest of the SDN industry.
Openflow is suppose to represent what is considered pure SDN but only smaller players like Big Switch and larger Cloud operators like Google are really embracing it full on. In fact, it seems that the mainstream vendors are way behind in this space. Broadcom recently released the OF-DPA SDK libraries that would allow better implementation of Openflow in hardware and solve some of the main challenges faced by the standard. However, I think the bigger question is whether the larger network vendors would step up and release complete solutions around this standard.
The moral of the story is that no one today is really embracing open standards in their solutions. Having an ecosystem is not being open and this in fact a challenge for the industry going forward. We should continue to push for standard and open solutions which allows full inter-operability based entirely on standards.
Openflow started out with the concept that all communication in the network would have its own flow installed in hardware. This means if two end points are communicating, they would have one flow for each direction. This amount of flows could increase significantly especially with the nature of networks today running with east-west traffic (N*(N-1) problem).
This approach is great as it allows full control of the network traffic which collects statistics for any communication happening between any two stations and policies. The challenge we have today is that current hardware designs are very limited to scale with this level of granularity. The only viable work around to achieve this ideal behavior today would be using software based switches or NPU type hardware switches. In the ideal sense flows means ACLs in the hardware ASICs which is about 2000 in most merchant chips today.
Most ASICs were designed for traditional networking and they have lots of tables that could be leveraged for SDN purposes. For example the MAC table in most switches can run from 32K to 124K easily. This amount of table entries can create lots of scale. However, the goal of Openflow and SDN is to implement flexible policy across the network fabric. MAC table entries are very limited as they only track the destination MAC, VLAN and output port. Taking that into consideration, we could build a flexible L2 network just using the MAC table where two stations could communicate by installing the respective MAC entries. Now we come to the issue of L3 requirements as well as with the WAN. These ASICs also have L3 and MPLS tables that could be leveraged to perform these functions.
In summary then, we could combine MAC, L3 and other tables to provide basic flexible forwarding within the network fabric with the Openflow controller coordinating table programming. We are still not achieving the ideal goal yet as these tables would not by themselves allow for policies within the network.
Openflow 1.3.1 Promise
While lots of this started out in Openflow 1.1, the concept of pipe lining with the various hardware tables is the real solution to overcome current hardware designs plus lay the foundation for the future.
Lets say the controller would allow all stations to communicate with each other using basic L2 and L3 tables. The next step is now to have some control over whom can speak to whom. With pipe lining you could insert an ACL entry to block traffic between two subnets or in some cases apply QOS parameters to specific L4 flows. All these would work together to maximize resource usage. The tables are processed in sequence as oppose to only one table per packet in Openflow 1.0.
Its very unlikely that you would have to block traffic within a given subnet but definitely you would need to consider differently between subnets. You have about 124K MAC entries and 4K L3 entries in most hardware and smartly using your ACLs and these other tables, you could easily scale out your Data Center network.
The next challenge are for both hardware and controller vendors to implement this standard approach to pipe lining tables and provide the real benefit of an SDN based fabric. While that is happening, we hope that ASIC vendors would deliver more ACL type table entries closer to 100K or more to allow even more scaling in the network.
Openflow as emerged as the pioneering protocol relating to Software Defined Networking and the hopes to transform networking as we know it. One of the biggest complaints with Openflow for real deployment is the lack of scale.
Recently, Broadcom an ASIC manufacturer published a new API scheme that shows the implementation of Multiple table pipe-lining which started in Openflow 1.1 but mostly talked about with 1.3.1. This pipe-lining approach allows switch vendors to exploit the many tables already in the current hardware. This API is significant as its implementation could turn the corner for real Openflow deployments in the year or so.
The other side to the scaling challenge is that Broadcom and other chip vendors are developing ASICs with much larger ACL tables closer to 100K to provide more flexibility in designing Openflow networks.
There are a lot of buzz about software defined networking (SDN), Network Function Virtualization (NFV) and many other related technologies. Now if you are in the business, the bigger issue is whether this can bring real economic benefits to my business?
While there are early adopters who just want to get their hands on the latest technologies out there, it still comes down to real analysis to see how this technology can be helpful. What are some things about SDN that can be beneficial?
1. SDN comes with the paradigm of a centralized control plane. This approach would reduce the need for management multiple network devices in a distributed fashion. This can save significant amount of time in managing the network.
One concern with this approach is the risk of failure points within the centralize model. The good news is that with clustering technology on modern controllers, its failure risk is very low.
2. Flexible - Since the network is no longer tied to specific ports and devices, SDN provides the network administrator many options in terms of properly utilizing existing resources. Another benefit would be cases of unfortunate disasters where you could move your resources to another location with simple configuration steps.
3. New Revenue - While we can focus on how to save money by centralizing the network orchestration piece, it also has the benefit to create more revenue streams especially if you are a cloud or service provider.
There are several more benefits of SDN that can be translated into dollars but stay tuned for more analysis on the economic benefits and strategies of evolving your network.
The fundamental questions are; How will it help your business to manage cost? How will it help to secure the network? SDN is gaining traction and its important to understand the fundamentals.