HP Announces Their SDN Controller

HP Announces Their SDN Controller

openflow-lab

HP Announces Their SDN Controller

Hp announces their SDN controller at Interop: HP is not new to the OpenFlow conversation. HP was one of the first, if not the first networking companies to make their OpenFlow enabled switch firmware agent GA (generally available) in 16 products in 2011 and now up to 24 products in 2012. HP has also long supported the GENI project which is an NSF project to leverage prototyped networks fir research. Likely the most recognized project that from GENI was Flowvisor, which is the concept of slicing and arbitrating networks to create virtualization. Yes, MPLS/BGP/VPNs do that also, but the difference is an exposed northbound API that allows for self provisioning.

sdn-agility-hp

Figure 1.  Hitting all the high points. Open, Abstract, Standards, Automation, Agility, Dynamic, Orchestration, check. Throw in a “Paradigm” or two and its bingo.

There was criticism of where HP was going with their strategy which I tended to agree with. Delivering commodity switches but not delivering anything in the form of controller or application was missing the economic promise and void in the market. There is a great deal more margin in software than there is merchant silicon. HP and SDN have the recipes to bring good products to market.

HP-SDN-Layers

Figure 2. HP SDN Layers.

“We(HP) are introducing the industry’s first complete and open-standards-based software-defined network technologies across all three critical SDN layers—infrastructure, control and application layers with a “single control plane” that enables enterprises and cloud providers to simplify and maximize agility across data center, campus and branch networks.”

FloodLight OpenFlow Controller Base

What I have heard is the HP solution is built on top of FloodLight the SDN OpenFlow controller. FloodLight was developed and open sourced by BigSwitch one of the two original SDN venture cap startups in SDN. I am under NDA with HP and most other network vendors but have not talked to anyone at HP about SDN since this summer and then it was hardware focused. Sounds like FloodLight is quickly becoming the de facto base for OpenFlow controllers. While I prefer Python, I am really happy to see an cross platform and modular framework becoming a base for products. I heard a while back IBM was leveraging either FloodLight or BigSwitch in their SDN product. Presumably that could be the Layer3 component to the IBM DOVE networking strategy. OpenFlow, MPLS some brand new label+meta data, is irrelevant. The promise is decoupling the OS and building proper abstraction layers. Pick something and lets go.

RESTful API

The RESTful API calls of the FloodLight and HP’s controllers are encouraging. Brad and Ivan have been writing about what if any uniformness comes from the industry with northbound facing programatic interfaces. We are quickly falling in trace behind OpenStack. It is appropriate since we are easily 5-10 years behind in the x86 market.

  • Example of RESTful API calls are at the bottom of this to get an idea of what they look like in a networking context.
  • Example of attaching an HP switch to a FloodLight OpenFlow controller.

Another interesting aspect to the HP announcement is bringing a few applications along with it. Jim Duffy had a good preview of what HP will be bringing with their SDN strategy in 2013. Security is one of the targeted applications with the product. Exposing forwarding tables allows for flow instantiation natively using layers 2-4. This opens up the ability to leverage switches for much more than mac address forwarding, flooding and storing. Edgy security classification may actually have a prayer to be realistic and not a total kludge like it is with today’s 802.1x solutions. It’s not a knock on the developers, their hands are tied with a completely inflexible platform to develop on top of.

HP-SDN-Cloud

Figure 3. Clearly looking to integrate hybrid cloud options into their OpenStack public cloud.

HP has a large investment in their public cloud offering. You can bet there will be hooks to facilitate elastic cloud computing.

HP-SDN-Ecosystem

Figure 4. I would be remiss if I didn’t write about all things magical here and not say the “E” word. Ecosystem, there I feel better, thanks.

There has been plenty of networking and virtualization vendors going after the Data Center but hardly any articulating a strategy for the Enterprise Campus or the Service Provider space. There will hopefully be a day that we see solutions a bit more tailored to the problems needing to be solved that is something better than a particular combination of protocols. When we run out of scale or have new needs the answer is always another protocol.

Not Just the Data Center

HP appears to be having two product offerings. One will be for the data center and the other will be for the enterprise campus. HP was vital in creating the competition and reducing margins in the edge switch market over the past couple of years. HP was indirectly responsible for entire product lines from incumbents, such as the Cisco Catalyst 2960 that was introduced as a low cost access closet switch and provided lifetime software upgrades for free after losing a few big deals to HP. HP has a deep background in software and obviously they see the opportunity to capitalize on that base. The stakes are even higher now for companies to commit or be left behind.

Good to be Ahead of the Curve

This is another brick in the path to networking horizontalization from a huge company with a deep bench. The road will be littered with the indecisive, risk adverse and arrogant. I expected Dell and HP to take a wait and see approach, I was wrong on the HP front. I still think Dell will buy BigSwitch, but I also thought they were going to buy Brocade but the bought Force10, oops. Good to see folks thinking about SDN solutions other than the Data Center since apparently the world is not made up of HyperScale cloud and content providers, shocking!

 

About the Author

Brent SalisburyI have over 20 years of experience wearing various hats from, network engineer, architect, ops and software engineer. More at Brent's LinkedInView all posts by Brent Salisbury →

  1. Michael P.Michael P.10-06-2012


    I mentioned this on Twitter but pretty sure that the IBM controller is based upon or is a straight OEM of the NEC controller which in turn is based on Trema (http://trema.github.com/trema/). You will notice the IBM and NEC specs are almost identical. IBM at http://www-03.ibm.com/systems/networking/software/pnc/specs.html vs. NEC at http://www.necam.com/docs/?id=67c33426-0a2b-4b87-9a7a-d3cecc14d26a (PDF)

    • Brent SalisburyBrent Salisbury10-06-2012


      Hi Michael, Sorry I missed your tweet, crazy week, guess they all are anymore. Makes sense with the history of IBM and NEC and the IBM TOR being rebranded NEC gear. I havent ever tinkered with Trema. I am leaning toward interpreted languages for early controllers for maximum exposure to code and avoiding library issues.
      Do you blog anywhere? Very insightful.
      Have a good weekend.
      -Brent