Archive

Posts Tagged ‘“SDN”’

OpenFlow for SDN – still relevant in 2014?

January 10, 2014 2 comments

Metaphor for OpenFlow

Metaphor for OpenFlow

When I read the prediction “OpenFlow is dead by 2014” it got me thinking…  What is it about OpenFlow that inflated expectations and drove things to a fever pitch only to end up in a “trough of disappointment” (to borrow overused analyst terminology) in 2014?  If Software Defined Networking (SDN) is a way to program network operations to serve a business need and involves separating the data plane in the hardware switches from a centralized control plane residing outside the switch, then OpenFlow is a forwarding protocol for SDN.  Once the control plane decides how to forward packets, OpenFlow enables the programing of switches to actually make this happen.  Use-cases for OpenFlow are compelling:

  • Google talked about how they improved WAN utilization from 30-40% which was the norm across the industry to a staggering ~100% using OpenFlow and home-grown switches.  These switches were build by Google using merchant silicon and open source routing stacks for BGP and IS-IS
  •  IPv6 address tracking could be handled by an OpenFlow v1.2 controller and OpenFlow 1.2 enabled switches
  • Data centers can reduce CAPEX by not buying hardware based network taps and instead using OpenFlow to program the functional equivalent of a network tap on a OpenFlow enabled layer 2 switch
  • OpenFlow controllers and OpenFlow enabled switches can help data-centers migrate from old firewalls to new ones in a seamless manner.

So what changed to bring on the naysayers?  All of the above still holds true.  While HP, Dell, Brocade, Arista Networks, Fujitsu, NEC, Big Switch Networks and others embraced OpenFlow, holdouts like Cisco & Juniper supported it grudgingly if at all.   Seeing switch upstart Arista Networks eroding Cisco revenue from Top of Rack (ToR)  switches, Cisco released the Nexus 3100 as one of its few switches to support OpenFlow 1.0 and even VMware NSX.  Juniper de-emphasized work on the OpenDayLight project and OpenFlow and decided to reinvent SDN by acquiring Contrail leading to disastrous results.  Despite all this, those who believe in OpenFlow and are against vendor lock-in march on:  OpenFlow is being evaluated by CenturyLink (3rd largest telecom provider in the USA) and by Verizon, deployed by providers like Sakura Internet, Rackspace, NTT Communications. SDN start-up Pica8 is promoting OpenFlow and switch programmability by offering white box switches, an open-source routing stack, the Ryu OpenFlow controller and an Open vSwitch (OVS) implementation.  Pica8 has won prominent customers like NTT and Baidu with this approach.  Storage start-up Coho Data offers a storage solution that converges networking and storage using OpenFlow & SDN.  If OpenFlow were a sentient being and could speak it would paraphrase Mark Twain and proclaim: “The reports of my death have been greatly exaggerated!”

Categories: NFV, SDN Tags: , ,

Software Defined Networking – Promise versus Reality

November 9, 2013 1 comment

Computer technicianThe promise of Software Defined Networking (SDN) was to abstract the human network manager from vendor specific networking equipment.  SDN promised network managers at cloud providers and webscale hosting companies a utopian world where they could define network capacity, membership, usage policies and have that magically pushed down to underlying routers/switches regardless of which vendor made the router/switch.  It offered service providers a way to get new functionality, reconfigure and update existing routers/switches using software rather than having to allocate shrinking CAPEX budgets for newer router/switch hardware.   How it proposed to achieve all this was by separating the control plane from the network data plane.   The SDN controller was to have a big view of the needs of the applications and translate that need into appropriate network bandwidth.

Just as combustion engine based auto-makers panicked at the dawn of electric cars, proprietary router/switch vendors saw their ~60% gross margins at risk from SDN and hurriedly came up with their own interpretations of SDN.  Cisco’s approach based on technology from the “spin in” of Insieme Networks is that if you as a customer want the benefits of SDN, Cisco will sell you a new application-aware switch (NX 9000) which will run an optimized new OS (available in 2014) on which you can use merchant silicon (Broadcom Trident II silicon) and you’ll have OpenFlow, OpenDaylight controllers, a control plane that is de-coupled from the data plane.  It assumes that customers would live with the lack of backward compatibility with older Cisco hardware like the Nexus 7000.  There was a silver lining to this argument: Should you choose to forgo the siren song of open hardware & merchant silicon and return to the Cisco fold, you will be rewarded with an APIC policy controller (in 2014) which will manage compute, network, storage, applications & security as a single entity.  APIC will give you visibility into application interaction and service level metrics.  Cisco also claims that using its Application Centric Infrastructure (ACI) switching configuration will lower TCO by eliminating the per-VM tax imposed by competitor VMware’s network virtualization platform NSX and reduce dependence on the VMware hypervisor.  VMware with Nicira under its belt, will of course disagree and have its own counter spin.

Juniper’s approach was to acquire Contrail and offer Contrail (commercial version) and OpenContrail (open source version) instead of OpenDaylight.  This is a Linux based network overlay software designed to run on commodity x86 servers and aiming to bridge physical networks and virtual computing environments.  Contrail can use OpenStack and CloudStack as the orchestration protocol but won’t support OpenFlow.

Startup Big Switch Networks (the anti-overlay-software startup) has continued to use OpenFlow to program switches -supposedly 1000 switches per controller. Once considered the potential control plane partner of the major router/switch vendors they have been relegated to a secondary role quite possibly since Cisco and Juniper have no intentions of giving up their cozy gross margins to an upstart.  Another startup Plexxi (the anti-access-switch startup) relies on its own SDN controller and switches connected together by wave division multiplexing (WDM).  Its approach is the opposite of that taken by overlay software like Contrail since its talking about assigning a physical fiber to a flow.

Where do SSDs play in all this?

Startup SolidFire makes iSCSI block storage in the form of 1U arrays crammed with SSDs and interconnected by 10GbE.  Service providers seem to like the SolidFire approach as it offers them a way to set resource allocation per user (read IOPS per storage volume) for the shared storage.  Plexxi is an SDN startup with its own line of switches communicating via Wave Division Multiplexing and its own SDN controller with software connectors.  Plexxi and SolidFire have jointly released an interesting solution involving a cluster of all flash storage arrays from SolidFire and a Plexxi SDN controller managing Plexxi switches.

It appears that the Plexxi connector queries the SolidFire Element OS (cluster manager) learns about the cluster, converts this learned information into relationships (“affinity” in Plexxi-speak) and hands it down to a Plexxi SDN controller.  The controller in turn manages Plexxi switches sitting atop server racks.  What all this buys a service provider is a way to migrate array level quality-of-service (QoS) from SolidFire to network level QoS across the Plexxi switches.

While the big switch vendors are duking it out with technology from Insiemi versus Contrail relying on expensive spin-ins versus acquisitions, their service provider customers like Colt, ViaWest (customer of Cisco UCS servers), Databarracks and others who use SolidFire arrays are looking with interest at solutions like the Plexii-SolidFire solution mentioned above which promises tangible RoI from deploying SDN.  Vendors selling high margin switches would do well to notice that the barbarians are at the gates and the citizenry of service providers is quietly preparing to embrace them.

Categories: SDN Tags: , , , ,

OpenFlow, SDN and Big data

November 23, 2012 3 comments

OpenFlow promised a way out of the tyranny in a world dominated by proprietary networking vendors like Cisco, Juniper, Alcatel and others.  It offered the promise of traffic engineering using low-cost hardware and a way to design your network in a deterministic fashion rather than have to over-provision everything for the worst case scenario.  In jargon-speak OpenFlow  allows “separation of the control plane from the data plane.”

What this means to you and me is that we can now take functions like access control lists (ACL) that were handled by the routers/switches and move that intelligence into Java software running in a virtual machine.  To do all these wonderful things all you need is:

  • OpenFlow controller
  • OpenFlow enabled switch

Vendors who make OpenFlow compliant switches include Brocade, HP, Juniper, Dell, Extreme Networks, Arista and IBM.  Carriers who deploy OpenFlow in their networks today include Verizon.

Software Defined Networking (SDN) is the latest buzzword which sends shivers down the spines of the big router/switch vendors who made billions of dollars selling proprietary firmware based routers and switches.  The stifling world they thrust upon us of access routers, aggregation routers, layer 3 routers and WAN routers, millions of lines of code for each router, roadmaps that stretch into the next 10 years –  may all become a thing of the past thanks to the unrelenting march of technologies like SDN.

How do you visualize SDN?  Think of this new architecture as being modular and neatly layered like an IKEA shelf, with the data-plane layer at the bottom, control plane above it and the application plane on top:

  • The data-plane layer switches can be of two types: OpenFlow Hypervisor switches and OpenFlow physical switches.
  • The control plane could feature commercially available controllers like Big Switch “Big network controller”.
  • The application plane is where you would have SDN applications, cloud orchestration and other business applications.

Players in the emerging SDN space include vendors like Nicira and Big Switch Networks.

  • Nicira who made available via open source their vSwitch Open vSwitch
  • Big Switch Networks who made available via open source their OpenFlow controller “Floodlight” under the Apache 2 license.
  • Midokura who virtualize the network stack of OpenFlow with their MidoNet

So what did the legacy networking and virtualization vendors do?  As the adage goes – If you can’t build it in-house then at least acquire it so you regain some nominal measure of control.   This scenario was acted out recently when:

  • VMware acquired Nicira for $1.2B
  • Brocade acquired Vyatta for an undisclosed amount
  • Cisco acquired Cloupia for $125M and Meraki for $1.2B

That’s enough about the vendors in the space.   If I am a user how do I benefit from SDN?

Benefits of SDN to enterprise customers:

  • The ability to squeeze more VMs into you existing rack servers results in driving down your power and cooling costs.  This  in turn mean more CapEx savings and OpEX savings (due to fewer trouble tickets) especially in an enterprise cloud environment.

Fidelity and Goldman Sachs are rumored to be customers of Big Switch Networks.

Benefits of SDN to cloud service providers:

  • A way to virtualize your network
    • If you are benefiting from virtualizing servers using VMware or Citrix technology why stop there?  Why not go down a level and virtualize the underlying network of proprietary switches and routers and treat them like an un-differentiated pool of resources?
    • A programmatic way to control your infrastructure:
      • If you are a telecom service provider you now have a way to move away from the proprietary architectures of Cisco, Juniper, Alcatel which requires a vendor’s programmer to program your routers.  You can now have your own telecom engineers do the programming blissfully oblivious to the make/model of the underlying router.
      • Better orchestration of cloud services.
        • Rapid provisioning including scale-up and scale-down.

In the service provider market these can quickly become key business differentiators.  Cloud providers like Amazon, Google, Facebook, MSN, Yahoo, Rackspace take advantage of the benefits of SDN today.  Traditional services providers like NTT are also adopters of SDN.

If you are still with me you might wonder: I get all this OpenFlow, SDN business but what pray tell does all this have to do with Hadoop and big data?  For starters, Infoblox has proven that Hadoop performance can be accelerated using OpenFlow enabled Ethernet switches instead of using pricier InfiniBand or other interconnects.    As Stuart Bailey, CTO of Infoblox says “Imagine a single programmer routinely having 10,000 cores and their associated networks to write Big Data applications!  SDN enables new industrial applications like Big Data analysis in the same way the PC brought spreadsheets and word processors into the enterprise.”

If you wish to explore this area further look into papers like these from IBM on how you can program your network at run-time for big data applications.  To learn more about SDN itself look into papers like this one from Dell.  If you happen to be an HP shop you’ll want to catch up on HP’s solutions for SDN.  So you see in the end big data has tangible benefits from this move towards SDN regardless of who makes your underlying network hardware.