How is the SDN landscape shaping up? (Part-2) – A market perspective

Will SDN and its accompaniments (NFV/NV) bring back the glorious days prior to the telecom bust, and pull the networking industry out of its technological plateau? I presume, most would say that the wave has already started. It is surmised that SDN has brought back venture money to networking after years of drought, years that were mostly sustained by bigwigs of the industry, through spin-ins and strategic investments in startups. SDN has found huge favor with VCs, with startups in this space having raised nearly $500M in 2013. Successful exits in the last couple of years, including Nicira Networks (VMWare), Contrail Systems (Juniper), Vyatta (Brocade), Tail-f (Cisco), Xpliant (Cavium)  and Cyan (IPO), have further spurred VC funding in the SDN market.

I will explore the SDN market landscape in this post, having covered technical aspects in my previous post.

What business potential does SDN hold?

To start off with vendor perspective, there are 2 facets to be understood –

  1. How will SDN impact customer spending in existing market?
  2. What is SDN’s potential for new market creation?

Roughly 30% of the total networking spend from Service Providers, Enterprises and Web Hosting companies is expected to be related to SDN. So, existing market players need to buckle up and be ready with committed SDN roadmaps and solutions, to still be relevant in the SDN driven networking market, as the technology is emerging as a significant influencer in network purchasing decisions. Customers are increasingly seen to evaluate how solutions and equipment procured today will fit into an SDN environment in the future. Market research firms (and VC firm Lightspeed Venture Partners) forecast impact of SDN to exceed $25B per annum, which could potentially be as high as $35B, by 2018. In comparison, the overall networking TAM is estimated to grow from the current value of $75B to $90B by 2018.

Plexxi-SDN-Report-319x301

Figure – SDN existing market impact (Source: Plexxi)

Except for speeds and feeds, networking innovation has been lagging behind compute (servers) and storage, the other two key blocks in any data center infrastructure. The advent of SDN/NFV/NV should help effectively virtualize any IT infrastructure environment by complementing compute and storage solutions, and propel new market creation, at a pace faster than seen with server virtualization in the mid-2000s. According to IDC, the new SDN market TAM will reach a total value of $3.7B by 2016, and touch $8B by 2018.

sdn market 1

Figure – SDN new market potential (Source: IDC, Image Source: IT World)

Moving on to customer perspective, SDN assures businesses outcomes of better revenues (by enabling network monetization through improved service velocity), and lower TCO (through automated control and higher network resource utilization). As with any emerging technology, customers are apprehensive whether SDN can deliver on its promises, and are unsure of its potential to become mainstream. Broad incumbent support for SDN and significant open community efforts are expected to accelerate maturation of SDN technology, and help realize usecases.

While SDN related needs have mostly been latent, Google (a founding member of ONF) developed an in-house solution for its inter-datacenter WAN deployment with centralized traffic engineering, using OpenFlow based SDN, as early as 2012. Other marquee SDN adopters include Amazon, eBay, Rackspace and Baidu.

What are the leading usecases?

Key usecases for SDN include public & private cloud, WAN traffic optimization, dynamic WAN interconnects and re-routes, network virtualization, automated network management, service chaining, network analytics, automated malware quarantine, granular flow based DDoS mitigation et al. [I could plan to cover each of these in detail in some future post.]

The usecases span Data Centers, Enterprise campuses, Cloud Providers, Service Providers and even SMBs, as latter segment could amply gain from SDN’s value proposition of IT infrastructure simplicity.

It wouldn’t thus be an exaggeration to conclude that SDN is going to impact every customer segment and use case of the networking market, and thus no customer or vendor is going to be immune to SDN driven change.

The Ongoing Controller War

SDN has driven the emergence of a new class of products, the SDN controller. With the controller being a strategic control point of any SDN network, vendors are vying for significant mindshare of their respective SDN architecture and controller solution, to eventually translate it into a sizeable market share.

Most dominant vendors in the industry are working on their own controller offerings [Refer next section for list of SDN controllers] to better chart the course of controller evolution and development, turn on potential software differentiation and hardware-assist features, and effectively orchestrate their range of infrastructure equipment offerings.

In addition, vendors (in collaboration with the Linux Foundation) have created an open-source platform for SDN, the OpenDaylight Project (ODP), to enable SDN adoption by accelerating technology development through ODP’s Open Controller.

A community-driven, common and trusted Open Controller would ensure network component interoperability across vendor offerings, both within and across architectural layers. The goal is also to promote multi-vendor environments, in comparison to today’s networks where each tier is typically populated with single vendor solutions. Network architects have been advocating open source/standard approaches to liberate customers from vendor lock-in challenges. Customers such as cloud and internet service providers, using such open standards based solutions, could still differentiate their end user offerings, by incorporating their secret sauce in the application layer. [Refer ‘SDN architecture’ section in my previous post for various layers].

Arguably, vendors who do not have their own controller but are participating actively in OpenDaylight community efforts seem to be betting the most for ODP controller to take off. Meanwhile, the controller war has heated up with the entry of other open source controllers which have been making news, namely Juniper’s OpenContrail and ON.LAB’s ONOS.

So, let us take a quick look at how these controllers differ.

ODP architecture has a single uber-controller and is primarily datacenter focused today, but could service WAN usecases as well.

ONOS targets SP WAN usecases with an architectural focus on fault-tolerance and state distribution across multiple controllers, to address high availability and bottleneck concerns with a single uber-controller. The challenge here is the need to orchestrate among these multiple controllers.

OpenContrail architecture is built for centralized control but with distributed physical components for fault tolerance. OpenContrail is very routing centric and focused on solving multi-tenant issues for SPs. Experts opine that its scope to extend to other customer segments is limited, given the lack of an abstraction layer to support multiple southbound/northbound interfaces, unlike ODP. [Refer ‘A Deep Dive into OpenDaylight components’ section in my previous post].

With vendors and communities tweaking their architectures and evolving their solutions over time, it is early to predict any potential winners. With SDN deployments being sporadic till date, it will be sometime before contenders evolve their offerings, prove their mettle in actual deployments and emerge successful.

The gamut of SDN offerings (ODP/ONF members only)

Given that there is a whirlwind of SDN activities in every nook and corner of the industry, I’ve opted to limit my evaluation to current members of ODP & ONF. To get a feel of the number of firms out there in the SDN ecosystem, refer list of players.

With SDN taking the world by storm [well, that might have be an exaggeration though – just got carried away for a bit, but here is what I wanted to say], I think it is inevitable for networking vendors to make their existing HW equipment and OS offerings SDN-ready, if they don’t want to be left behind. Also, a new group of players have emerged with niche SDN applications and orchestration platforms (e.g. PLUMGrid with its OpenStack Networking Suite).

While adding SDN capability to (legacy/existing) equipment and appliances would ensure investment protection for customers, SDN and orchestration applications (which are still taking shape and quite customer/segment specific) are key to delivering real customer value through SDN. However, adoption of SDN controllers, the pivotal component in the SDN architecture, is a precursor for customers to tap into potential of SDN applications.

I’ve chosen to focus my analysis in this post, on SDN offerings from (1) those who’ve taken the plunge by putting out (or working on) SDN controllers in the market, and (2) those who have built pure software switches, that can go with generic (x86?) hardware, towards realizing the joint vision of SDN/NFV/NV.

And, here we go with the list of SDN offerings!

(1) SDN Controller Platforms

Just a quick reminder that SDN controllers are only software platforms. And, yes, they do need a host to run on. [Would welcome inputs on hosts you’ve seen being used in SDN deployments.]

I’ve removed the term ‘Controller’ from product names in the below table. Thought it was understood.

logo_abbnDBSM

logo_atto

OBelle

logo_bigswitchBig Tap

logo_brocade_0Brocade Vyatta

logo_cienaAgility Multilayer WAN (MLWC)

logo_ciscoXNC (ODP based), ONE, APIC (Insieme)

logo_citrixNetScaler logo_coriantIntelligent Optical Control (IOC)

logo_cyanBlue Planet

logo_dellActive Fabric

logo_etriETRI

logo_extremenetODP-based with extensions
logo_hpVirtual Application Networks logo_huaweiCarrier-class SDN (SNC) logo_ibmProgrammable Network (PNC)
logo_inocybeSustainable SDN (ODP-based) logo_juniperOpenContrail, NorthStar Network (NNC) logo_nclVirtual Network (VNC2.0)
logo_necProgrammable Flow PF6800 logo_nttRyu OpenFlow (used by Pica8 too) logo_nuageVirtualized Services (VSC)
logo_oracleOracle logo_plexxiPlexxi Control logo_vmwareNSX (Nicira)

logo_opendaylightOpenDaylight (ODP)

(2) SDN Packet Processing Platforms

Here is the list of software-based SDN packet processing platforms, built to run on generic hardware. These would technically fall under the gamut of SDN-ready NFV products, though they align with SDN vision.

logo_6wind6WindGate logo_aricent

Fast Path Accelerator

logo_bigswitch
Switch Light
logo_brocade_0Vyatta 5400/5600 vRouter logo_microsoftCisco vPE-F logo_microsoftHyper-V vSwitch
logo_midokura
MidoNet
logo_nec

ProgrammableFlow vSwitch

logo_pica8

Integrated Open vSwitch

Interestingly, the ecosystem has also seen the entry of Intel into Ethernet switch market, with FM5000/FM6000 series of SDN-enabled ASICs.

Commercial SDN deployments

Now, let me run SDN through the market adoption test!

As we saw, there is no dearth of SDN offerings in the market. But, but, has SDN really taken off? I chose to evaluate this based on public customer references. I thought I’d be amply surprised if any vendor deployed SDN commercially and didn’t get their marketing folks to put together public customer references, or if carriers/web hosting companies didn’t want to make a splash of having adopted SDN. And well, I was surprised. Anyways, more on this later.

Going based on public references, here are the commercial SDN deployments of vendors. I’ve kept out in-house SDN solutions developed/deployed by customers such as Google, NTT, AT&T, Amazon, Microsoft, Facebook, given the number of makeshift offerings masquerading themselves as SDN solutions, and the many paths to realizing SDN benefits of programmability and improved service velocity.

SDN Vendors Customers Deployment Usecases
logo_contextreme logo_verizon SP Carrier Network
logo_bigswitch logo_csmresearch Private Cloud
logo_huawei logo_chinatel Data Centers
logo_huawei logo_21vianet Cloud Data Centers
logo_nec logo_ntt Cloud Data Centers
logo_nicira logo_ebay Data Centers (Prior to VMWare acquisition)
logo_nicira logo_rackspace Data Centers (Prior to VMWare acquisition)

Additionally, Cyan reports on its website that Blue Planet SDN platform has been implemented in 120 production networks, but I didn’t come across any other public material.

Seems too short a list right? Either these are the only commercial deployments or public references aren’t the way to go. Didn’t think that SDN customers (and not just startups like Versa Networks, GuardiCore) would be in stealth mode. If you know of any more SDN deployments, please point me to public references online.

If you could spare time for a deep-dive, do take a look at the links I’ve embedded (at the start of this section) on in-house SDN solutions being worked on by SDN “customers”. Interesting to see how boundaries are continuing to blur across vendors and customers!

May the best win (or atleast each find their niche) and the ecosystem prosper!

That was quite a long post! I really hope to limit the post length in future.

Meanwhile, if you have any feedback on this one, please post a comment or drop an email. I’m certain there’d be alternate views, especially given the murky state of the SDN market.

How is the SDN landscape shaping up? (Part-1)

“May you live in interesting times!” goes a Chinese curse! And interesting times, while challenging and marked with uncertainty, have immense potential waiting to be realized. The SDN canvas, dotted with hopeful startups, open source communities and networking behemoths edging their way in (seemingly a little too early, without giving startups a chance to have had a good run in the new market), is brimming with opportunities and promises to accelerate service velocity through automation and orchestration, while being cost-effective.

The famed SDN definition

To fast-forward through Software Defined Network (SDN) evolution to this date, SDN started off with a compelling vision to centralize network control plane in a network controller, and strip off intelligence from the distributed data plane, to provide administrators an environment that is generic, open, extendable and centrally manageable. With few takers to rebuild control plane solutions from scratch, the vision has evolved to accelerate deployment of end user applications in a secure and scalable manner.

Control Plane Approaches

OpenFlow’s imperative and OpFlex’s declarative model are the two main control plane approaches in the SDN market.

In the imperative model as in OpenFlow, the controller fully instructs routers and switches on how to move packets based on application requests, with no control intelligence embedded in the distributed data path network elements. The imperative model suffers from the drawbacks of centralized controller becoming a bottleneck and single point of failure in the network.

In contrast, the declarative model implemented in OpFlex, allows for more distributed intelligence. The controller sets a central policy based on the application needs but gives power for network nodes to determine how best to execute the said policies and meet the application needs. In this approach, the network can sustain itself even if the controller fails, allowing for better availability and resiliency. The network can also scale better as the controller is no longer the sole brain of the network. Cisco’s Application Centric Infrastructure (ACI) framework is based on the declarative model.

Open Standards and Development Communities

Open communities such as Open Networking Foundation (ONF), OpenStack and OpenDaylight have played a pivotal role in bringing together IT, cloud and telecom service providers, compute, storage and network equipment vendors & silicon providers, technologists, developers and researchers, to streamline efforts in formulating open standards and following through with open source development, promotion and adoption of SDN.

Open Networking Foundation (ONF) is accredited with introducing OpenFlow, the first SDN standard and vital element of the open SDN architecture.

OpenStack – Unlike ONF which is limited to networking and is a standards community, OpenStack encompasses compute, storage and networking (refer figure below), and is a developer community focused on cloud environment solutions. OpenStack software is an open-source cloud operating system that helps control large pools of compute, storage and networking resources throughout a datacenter, allows administrators to manage resources through the OpenStack dashboard, and empowers application users to provision resources, through a web interface, transparently orchestrating across compute, storage and networking blocks.

OpenStack is architected to provide flexibility as businesses design their public/private clouds, with no proprietary hardware or software requirements and the ability to integrate with legacy systems and third-party technologies.

OpenStack has multiple official programs targeted for specific architectural blocks such as Nova (Compute), Swift (Storage), Quantum replacing earlier termed Neutron (Networking), Heat (Orchestration) etc. to provide plugins to deliver each of these blocks as a service, for e.g. Network as a Service in the cloud environment, and thus the value proposition of programmability in the SDN/SDCC paradigm, though in a cloud environment.

openstack-software-diagram

Figure – OpenStack Architecture – Sourced from openstack.org

OpenDaylight is an open platform that any enterprise or provider can use today, to enable SDN and NFV through programmability of networks of any scale. The software is combination of components and includes a fully pluggable controller, interfaces, protocol plug-ins and applications.

SDN Architecture

Towards realizing the SDN vision, Open communities and foundations comprised of business users, vendors, technologists and researchers, have arrived at a basic SDN architecture [captured in below figure], which consists of 3 main layers – Application, SDN controller and Network Infrastructure.

The SDN controller which houses the intelligent control plane, interfaces between user services & applications and the network on which they run (latter denoting the distributed packet-forwarding data plane in an SDN environment), with the goal of abstracting the network, so that application developers can tune the network to meet application needs, without having to understand the inner workings of the network.

SDN-Archit-fig1

Figure – Basic SDN architecture – Sourced from Datacenterjournal.com

Northbound APIs are used for communication between the controller and application layer, to enable efficient orchestration and automation of the network to align with needs of different applications, while Southbound APIs are used between the controller and infrastructure layer.

To demystify the term ‘orchestration’, as in a musical orchestra, this function in the SDN architecture ensures that various resources (for e.g. compute, storage and network blocks in a data center) are controlled by a common entity to align with or complement each other and work synergistically to meet the business application needs.

Let us now see how OpenStack, OpenFlow and OpenDaylight fit into the SDN architecture.

OpenStack allows for orchestration in a cloud environment to deliver networking-as-a-service, through OpenStack Quantum APIs that I discussed earlier in this article.

OpenFlow is a open-standard Southbound communication protocol that enables OpenFlow SDN controller  to add and delete flow tables entries in OpenFlow switches and routers, and thus control flows for optimal performance and eventually make the network more responsive to real-time traffic demands. More to this, when I explore OpenDaylight in the next section.

OpenDaylight is a complete implementation of SDN and I think the below framework summarizes it best. Let me also repeat how I introduced OpenDaylight earlier in this article. OpenDaylight is an open source software platform that implements a pluggable controller, northbound programmatic & southbound implementation interfaces, protocol plug-ins and applications, that anyone can use today (that’s right, today!) to evaluate, commercialize, and deploy SDN (and NFV – the topic I’ve saved for a future blog post). The controller is contained within its own Java Virtual Machine, and can be deployed on platform that runs Java.

odp_ds_ltr_diagram

OpenDaylight Framework – Sourced from OpenDaylight.org

A Deep Dive into OpenDaylight components

In this section, I’ll go over various protocols and stacks that you would hear of in the SDN context and see how they fit into the SDN architecture, based on the OpenDaylight framework [refer figure above].

Northbound Interfaces

Northbound APIs are the most critical in the SDN environment, as the value of SDN is closely tied to the innovative applications it can potentially support and enable. Given that they must support a wide variety of applications, a variety of possible interfaces currently exist to control different types of applications via an SDN controller. Consolidation of these interfaces is yet to happen, given that SDN usecases are still evolving.

OpenDaylight supports OSGi framework and bidirectional REST for northbound APIs. The OSGi framework is used for applications that will run in the same address space as the controller. In comparison, REST (HTTP based) APIs are used for applications that do not run in the same address space or even necessarily on the same machine, as the controller.

Northbound APIs are also used to integrate the SDN controller with automation stacks such as Puppet, Chef, Salt, Ansible and CFEngine. As we saw earlier, they also help interface with orchestration platforms such as OpenStack.

SDN Applications that can be optimized via Northbound interfaces include load balancers, firewalls and other software-defined security (SDSec) services.

Southbound Interfaces

The southbound interface is capable of supporting multiple protocols for (1) managing physical and virtual network elements, (2) operating on the control plane to allow for controller driven programmability, or communicating network state/events and (3) configuring data forwarding plane on distributed physical and virtual network elements. Networking equipment vendors implement one or more protocols in the above categories, to add SDN capability to their legacy equipment, thus ensuring investment protection for their existing installed base, during the move to SDN.

NETCONF, OF-CONFIG using YANG data models, SNMP and XMPP operate in the management plane and allow for network device configuration and monitoring.

I2RS, PCEP, BGP-FlowSpec and BGP-LS are protocols that operate on the control plane and either update routing tables in a programmatic way, allow for creation of MPLS-TE tunnels from a central controller and communication of computed LSP paths to network nodes, automate distribution of traffic filter lists for DDoS mitigation or help export link/topology/tunnel states through BGP to the controller.

OpenFlow (v1.0, v1.3), LISP and OVSDB are protocols that allow the controller to configure flows tables and influence the forwarding behavior of physical and virtual devices.

[I could explore these protocols in-depth in another blog post, to limit the length of this one.]

SDN Controller

As discussed earlier, the controller is the key arbitrator between network applications and network infrastructure, and forms the crux of the SDN network. To be able to effectively centralize the intelligent control plane, the controller typically implements base network functions to provide host/node service, flow service, topology service, path service to setup and manage a path based on specified constraints, multi-tenant network virtualization, network statistics, security, centralized monitoring etc. In addition, it provides a collection of pluggable modules in the Service Abstraction Layer to support a variety of southbound interfaces.

[I’ll delve more into the SDN controller war among commercial and open source variants, in my subsequent post. I plan to post “part-2” of this topic soon, which will cover SDN market potential, overview of vendor architectures/solutions, SDN ecosystem of controllers, SDN-ready routers/switches and trending vendor solutions.]

To be continued..

Look forward to hearing your thoughts in the comments section. Would be glad to address any questions as well.