Big Switch's controller will interoperate with third-party switches that support the OpenFlow protocol version 1.0. To that end, Big Switch has announced official partnerships with Arista, Brocade, Dell and Extreme, and also claims to have performed interoperability testing on switches from IBM, HP and Juniper.
And what about Cisco Systems? Cisco has announced it will support OpenFlow in two switches, the Catalyst 3570-x and 3560-x, but Big Switch said it had not been able to test interoperability between its controllers and the Cisco switches. Given Cisco's dominance in the switching market, Cisco's absence removes a significant source of potential customers from Big Switch's plate.
As mentioned, Cisco has announced that it will develop its own controller, called the ONE controller, and also stated that a controller function will be included in IOS as part of its OnePK initiative. Cisco promotes a broader vision of SDN than just OpenFlow. Cisco takes the view that OpenFlow is just one small part of the overall requirement for SDN, and that there are dozens of other functions in the network that need configuration and exposure via an API. Cisco has announced that its OnePK platform will provide not only API access to the flow table, but it will also give API access to routing tables, AAA configuration, the physical interface and another 15 or so areas. OpenFlow is just one API of many in OnePK.
Cisco is following its typical approach of embracing a standard and adding proprietary extensions. Consider 802.1d Spanning Tree, which was improved by the proprietary and patented PVST, or TRILL, which was extended by FabricPath.
From a mercenary perspective, Cisco is defending its incumbent position by maximizing the value of its existing software and hardware features, thus defending against being made irrelevant by OpenFlow's simplicity at the device level. It seems that Cisco is making its own future with its OnePK strategy and is choosing not to integrate with wider OpenFlow/SDN community. It's likely that Cisco expects to build its own platform that software partners can use--a platform over which it can exert more control and direction.
Who Rules the Northbound API?
The controller sits between network devices at one end and applications such as firewalls or load-balancing at the other. Thus, the controller requires an API to interface with these applications (in controller parlance, this is the northbound API).
At this point in time, the northbound API between the applications and the controller is not stable or well defined. No single body has defined standards for a northbound API, and it will likely take some time for a consensus to form around the structure and technical features of the API. However, the controller vendor that can gain enough market momentum will have a key role in defining the northbound API.
Big Switch hopes to get an early-to-market advantage on this front. As part of its Big Network Controller launch, it has announced partnerships with Cariden, which has a highly successful network analysis systems for service providers, and with Coraid for ATA-over-Ethernet storage networking. It has also developed a partner ecosystem that includes vendors such as F5 Networks, Citrix Systems, and Palo Alto Networks. Big Switch is also touting its commitment to the open-source community in hopes of building a strong developer ecosystem. By keeping Floodlight as an open-source effort while also tightly linking it to Big Network Controller, developers can build and test with Floodlight and then seamlessly move to production.
However, for third-party vendors, the question of the northbound API is significant; it would take time and money to interface with controller APIs from Cisco, HP, IBM, NEC, Big Switch and whatever other vendor decides to get into the game.
It's possible that software vendors will partner with Big Switch rather than closed products from major vendors. That said, Cisco's gravitational market share is likely to pull in a significant amount of third-party development efforts.
Serious and Significant
Despite the uncertainty that surrounds any start up, the Big Network Controller is a serious and significant technology achievement. It represents a potential watershed for OpenFlow adoption. In conjunction with the Big Virtual Switch, it provides the first software package that configures a multivendor switch network without using MPLS or overlay protocols like VXLAN.
The most important takeaway is that the OpenFlow/SDN movement has a shipping product from a vendor that is strongly positioned to make an impact. The success of Big Switch and its products will test whether the market is ready for OpenFlow-enabled networks.
