Sunday, November 30, 2014

Cisco OnePK - Cisco Presents at Networking Field Day 5


What is Cisco onePK?



Using Puppet with Cisco onePK





Cisco ONE Controller History, Future, and Use Cases

Cisco Quad Sup VSS SSO demo



Cisco Catalyst 3850 Converged Access Switch Overview




Cisco Store-in-the-Box Demo with Kishan Ramaswamy



Cisco Identity Connector with OnePK Integration Demo with Natty Iyer


Cisco Private Datacenter Mobility Demo with Mostafa Mansour

Cisco Private Datacenter Mobility in depth with Mostafa Mansour


Cisco Wired and Wireless Demo




Free-Form Discussion on Hybrid Switching, OpenFlow, and SDN with Cisco





Top 10 Strategic Technology Trends for 2014-2015





Mobile and cloud hosting solutions are moving technology in new directions in 2014, as an infographic from ComputerSupport.com points out. Based on a report presented by Gartner at the Gartner Symposium/IT Expo, the infographic reveals ten clear strategic technology trends impacting businesses and consumers in 2014.

Mobile Device Diversity and Management

The rapid adoption of Bring Your Own Device (BYOD) in many workplaces has brought new challenges for security professionals. 2014 is the year professionals will realize the risks related to mobile devices and strengthen policies to address these risks.

Mobile Apps and Applications

Gartner predicts that apps will continue to grow in popularity and applications will start to dwindle as users go increasingly mobile. For developers, the push toward HTML5 and the browser as a delivery mechanism will change the development environment.

The Internet of Everything

For both businesses and consumers, internet connectivity will go beyond devices to include wearable items, household appliances, field equipment, and much more.

Hybrid Cloud and IT as a Service Broker

In its report, Gartner stresses the importance of bringing personal clouds and external private cloud services. Cloud environments should be set up with a hybrid future in mind.

Client/Cloud Architecture

The architecture of client/cloud computing is changing, with the client serving as the application on a PC or mobile device and the cloud requiring scalability. Applications must be able to run on multiple devices.

The Era of Personal Cloud

Thanks to the emerging personal cloud, services will become more important than services. While equipment will still be important, they will merely be a conduit to the apps and data a user needs.

Software Defined Anything

Known as SDx, Software Defined Anything encapsulates the networking, data centers, storage, and storage networks that make up technology today. SDx calls for improved standards for cloud computing and development.

Web-Scale IT

Calling upon the experience of large cloud providers like Amazon and Google, Gartner created a term called “Web-Scale IT.” This term refers to the need for enterprises to examine the IT value chain for improvements in every area across the organization.

Smart Machines

Devices will become more sophisticated through the year 2020 as machines like IBM’s Watson show more human qualities. Gartner predicts this smart machine era will be among the most disruptive in IT history.

3-D Printing

2014 will be the year mainstream 3-D adoption begins to grow, as the number of units shipped this year should grow by 75 percent. Gartner predicts this will be followed by double growth in 2015.


Sunday, November 23, 2014

HOW IS THE SDN LANDSCAPE SHAPING UP? (PART-3) – A SECURITY PERSPECTIVE

Click Here - Part 1
Click Here - Part 2


In a fast-changing technology landscape, security is a moving target as the sophisticated attacker unearths and takes advantage of new weaknesses. Cybercrime has moved beyond mere vandalism and emerged as a professional industry focused on exploit kit innovations and planned attacks, given its lucrativeness and with some countries around the world involved in extensive cyber-espionage. The global hackers’ economy is pegged conservatively at around $450B, while Gartner estimates the worldwide security market for 2014 to be just about $71B.

In the December 2013 breach of retail giant Target, data from as many as 40M credit cards and 70M user accounts were hijacked, while Home Depot data breach between April and September 2014 affected 56M debit and credit cards, data of which is said to have appeared within days on black-market sites. Per Checkpoint security report 2014, 88 percent of analyzed organizations experienced at least one potential data breach event in 2013, up from 54 percent in 2012. Verizon’s data breach investigation report identified nine major patterns that covered over 90% of security incidents in the past decade, with the dominant pattern varying across industry verticals. [Refer bottom-right of the following chart for a listing of these categories.] In the recent years, dangers of targeted attacks and advanced persistent threats (APTs) have garnered much of the attention in the information security world.





How can SDN improve security?

With the increase in network traffic, virtual machines, cloud computing, and malware threats, IT manpower is a major security bottleneck, as they simply can’t keep up with the increasing demand of sorting through incidents/alerts and fine-tuning security controls based upon latest threats. This situation can be expected to exacerbate as IoT applications gain momentum. The only way to bridge this growing response-capability gap is through intelligent incident detection and automated response.

While automated security is a key driver, the excitement with SDN enabled security is more so around the opportunity for intelligent response on a granular basis – be it on per flow, per application or per user basis – to provide Security-as-a-Service, while eliminating manual configuration errors and keeping down SecOps & NetOps staffing costs. No longer would the default system response to any severe security threat be ‘Fully Block’.

Enterprise SecOps teams are interested in using SDN to enable multiple usecases – to selectively block malicious traffic from endpoints while still allowing normal traffic flows, to centralize security policy and configuration management, and for network security policy auditing and conflict detection/resolution.

With deperimeterization, corporate networks no longer have a single point of entry or exit, resulting in the demand for network telemetry and flow-based security solutions. SDN could be used to act on any anomalies detected on flow capture data, by dynamically establishing rules to divert specific flows to either a centralized or distributed enforcement points. Additionally, SDN could be used for traffic engineering to direct discrete network application flows to specific combination of security services such as FWs, IDS/IPS and WAFs.

SDN’s capability to programmatically and dynamically insert customized security services in the network path, via service chaining of physical and virtual L2-L4 routers/switches/appliances [as illustrated in below figure], could help minimize performance impact of ‘bump in the wire’ security devices, while enhancing security by acting on gleaned threat intelligence.

Figure – SDN enabled network and application security (Source: devcentral.f5.com)

While SDN controller limits its visibility and programmatic focus to underlying physical/virtual network elements and thus directly implements network security, application layer security is provided in this architecture by working in tandem with orchestration components to control other L4-L7 data path elements.

In a nutshell, SDN can help improve security by aligning the right security service with the right flows.

Common Security Usecases of SDN

Having gone over SDN security benefits in the previous section, let’s now deep dive into a couple of well-defined SDN security usecases – DDoS mitigation, Advanced Malware Quarantine and Elephant Flow mitigation.

DDoS Mitigation

Distributed Denial of Service (DDoS) attacks that are typically launched from compromised systems (bots) bombard enterprise applications with fake service requests, with the intent of denying or degrading performance of legitimate service requests. In addition to hogging the application servers, such attacks consume SP network capacity and saturate inline security devices. Addressing DDoS attacks requires detection of fake requests and diverting traffic to a specialized cleaning device to remove fake packets from the traffic stream, and sending back legitimate packets to the enterprise application/service.

While DDoS defense can be implemented through Remotely Triggered Black Hole (RTBH) or Policy based routing (PBR), the former solution implements filters that block all traffic to the target application, thus making it unavailable for legitimate services too. On the other hand, while static PBR based solution provides granular flow control, it requires SPs to add manual filter configuration on their backbone/edge routers and thus prolongs the recovery time from such attacks.

In comparison, BGP FlowSpec which aligns with the SDN paradigm follows a more granular approach and automates distribution of filter lists that can match a particular flow via BGP NLRI to the backbone/edge routers. So, policy updates happen dynamically and only a specific flow traffic (based on L3/L4 information) is stopped instead of dropping all traffic to a server, as illustrated in the below figure. SDN can thus boost security by dynamically reprogramming and restructuring a network that is suffering a distributed denial-of-service attack.


Figure – DDoS Mitigation using BGP FlowSpec (Source: Alcatel-Lucent)

Automated Malware Quarantine (AMQ)

SDN can also offer security capabilities such as automatically quarantining an endpoint or network that has been infected with malware.

In the non-SDN architecture, AMQ is typically deployed as a proprietary standalone solution where each device performs its specified function autonomously, with limited awareness of other devices in the network. This closed approach is suitable only for static traffic flows, and inflexible in data center environments where server workloads are virtualized, traffic flows are highly dynamic and multiple simultaneous flows must be maintained.

In a SDN controller driven network, if detailed forensics by network security devices generate a high enough score to initiate a quarantine directive, the SDN controller translates this into a set of OpenFlow rules that is pushed down to OpenFlow enabled switches to cut off the infected host from the production network and display (via the Web Proxy Notifier in the below figure) a web page with corrective actions to be performed. Once the corrective actions are performed, the rules are changed to allow the end host back into the network. Such automated reconfigurations through SDN reduce the response time to security threats, while allowing user mobility at the network edge. Given that this AMQ implementation does not require any additional software or hardware support beyond OpenFlow enabled devices, this is a vendor agnostic solution and ripe for deployment.


Figure – Advanced Malware Quarantine using SDN (Source: ONF)

Elephant flow detection/mitigation

Short-lived flows referred to as mice tend to be bursty and are often latency sensitive. In contrast, long-lived flows termed as elephants normally perform transfers of large blocks of data and are typically packet latency insensitive. Without intelligent traffic engineering, elephant flows may fill up network pipes causing latency and/or service disruption of mice flows.

SDN applications could help select a marking action and instruct the SDN controller to push the action to OpenFlow routers/switches to assign a selected queue for traffic associated with elephant flows. Other applications include offloading elephant flows from L2/L3 network fabric to the optical circuit switched network i.e. a pure photonic layer 1 network, for better performance and scalability at lower cost. In an enterprise environment, elephant flows observed during network backup of a filesystem could be prevented from taxing the firewall and slowing down its performance without compromising on security, by implementing a firewall service bypass function dynamically via SDN, based on whitelisted flow parameters of “good” permitted elephant flows. The permitted elephant flows are now dynamically re-directed so that they are sent directly in/out of the campus and the firewall is no longer in the forwarding path.

Security-centric SDN offerings

While OpenFlow is a key technology enabler of SDN security usecases as we saw in the previous section, few firms offer enhanced SDN security solutions that go beyond OpenFlow.

Illumio – a promising startup with a veteran executive team from Cisco, McAfee, Nicira, Riverbed and VMware – is based on the idea that each workload must have its own defenses. Illumio’s Adaptive Security Platform (ASP) provides visibility and enforcement services to dynamically keep pace with the motion, change and automation of the underlying IT infrastructure and applications, by attaching fine-grained security at the level of individual workloads while being continuously aware of its context. [Refer below figure to understand workload context.] It allows enterprises to secure applications across private, public or hybrid cloud environments on any physical server or VM. Illumio has 25 customers including Morgan Stanley, Plantronics, Creative Artists Agency, UBS, Yahoo and NTT I3.


Figure – Workload context (Source: Illumio)

Illumio ASP provides two modes of operation: (1) illumination mode which security administrators can use to visualize workloads and traffic flows, perform policy analyses, assess security gaps and potential impacts to application flows, and even discover unused workloads. (2) enforcement mode which lets administrators write security policies using natural language to describe desired communications between workloads. Once the policies are enforced, workloads are locked down to interact only with the specifically allowed paths.

As illustrated in the below figure, Illumio ASP is architected as a distributed and asynchronous system with Virtual Enforcement Nodes (VENs) attached to individual workloads (running on any VM, physical server, or private/public/hybrid cloud) and a centralized policy engine (PCE). The VENs listen continuously for the context of their workload and relay the information to the PCE, which computes enforcement rules by combining the workload’s context with configured security policies. The enforcement policies are then sent to the VEN, which modifies the appropriate iptables or Windows Filtering Platform parameters on the workload.



Figure – Security-centric SDN – Illumio ASP architecture (Source: Illumio)

NetOptics, a provider of application and network visibility and monitoring solutions, offers Security-centric SDN by combining an SDN controller with Network Packet Brokers (NPBs) in an architecture that allows for intelligent orchestration of the customer’s existing security appliances and solutions. NPBs embody dynamic attack monitoring, ability to chain solutions and distribute traffic, while the SDN controller is used to assess the network and adapt the network behavior based on threats detected through security enforcement elements, to either divert suspicious traffic, change security devices’ responses, or block packets altogether, all with minimal-to-no human intervention.

Radware’s Defense4All, the first open SDN security application to be integrated into OpenDaylight, offers carriers and cloud providers DoS and DDoS detection and mitigation as a native network service. The application uses the programmability of SDN to collect statistics, analyze information and control the infrastructure layer to proactively defend against network flood attacks. This allows operators to provide DoS/DDoS protection service per virtual network segment or per customer.

In today’s dynamic cloud data centers, assets and their network configurations are subject to change yet compliance lacks automation and continues to rely on manual processes. Catbird, the leader in security policy automation and enforcement for private clouds and virtual infrastructure, offers CatBird vSecurity to bring automation and agility of the cloud to security automation and enforcement of compliance standards such as PCI, HIPAA and FISMA. By integrating with Cisco ACI, Catbird provides IT teams a highly standardized, automated approach to provisioning security as part of the network policy, through the asset lifecycle from asset inception to teardown.

Most vendors including Juniper (Altor Networks acquisition rebranded as Firefly Perimeter) and Cisco offer SDN controllers that seamlessly integrate with virtual and physical routers/switches/security devices to enable dynamic provisioning and service chaining of security services. Among the vendors that have already announced OpenDaylight Helium-based products is Brocade. Helium release has multiple security capabilities including Secure Network Bootstrapping Infrastructure (SNBI) and AAA. Alongside, we have OpenFlowSec, a community focused on developing OF security applications, kernel extensions and application frameworks, to assist OpenFlow practitioners in enhancing security capabilities of OpenFlow.

Is SDN secure enough, to offer security?

We’ve seen that good potential exists to enhance security through SDN, and there are ongoing industry efforts to help realize it. But, is SDN inherently secure enough, to augment network and application security? Or is SDN security an oxymoron as skeptics put it? Let me explore this aspect to try and calm down the naysayers to SDN from a security perspective, before I wind up this post.

Here are the top security concerns of the SDN architecture –


  1. Single point of failure, given the central function of the SDN controller
  2. Wide span of impact, when the network is opened up to applications
  3. Need for secure communication between controller and end nodes/applications, to stem MITM attacks


Single Point of Failure

Because the control plane and thereby the SDN controller play such a central function in the SDN architecture, security strategies must focus on protecting the control plane to thwart any targeted attacks on the controller – be they to saturate the control plane or attempts to leverage policy configuration errors for infiltration and lateral movement – as access to the controller could potentially give complete control of the network to an attacker.

It is vital to secure the SDN controller by carefully designing access control policies, manage authorization, track and audit usage of the controller. Also, where it resides on the network is a big security concern. This concern of having a king that needs to be protected are being addressed in variants of the SDN architecture through High Availability in the controller, SSL communication between controller and network elements, extension to the OpenFlow data plane called connection migration, which dramatically reduces the amount of data-to-control-plane interactions that arise during such attacks, SIEM to log everything that comes out of the system, analytics to correlate logs from SIEM and alert the manager of any changes.

Wide span of impact

In contrast to pre-SDN one-by-one configuration process, where an error might only affect one part of the network, SDN now makes it easy to have one policy applied uniformly and in an automated way. However, opening up the network to its own applications require their own security policy framework, governance and management to be put in place.

Business applications are vulnerable to potential threats because of the powerful SDN programming model. Multiple SDN network services may interfere with one another, compromising the forwarding behavior of the network and such conflicts must be avoided. Security policies may be compromised at the controller, at one or more network devices, and/or at other places. As a result, security policies must be validated, along with the network configuration and behavior and performance.

While the upside is that SDN will demand clear policies, companies will need to spend time thinking about and designing those policies. These can be expected to be reside as pre-provisioned security policy logic in a policy management system.

Communication between controller and end nodes/applications

To thwart any security barriers to SDN adoption, OpenDaylight community launched a project to analyze current security capabilities of its SDN implementation, and provide recommendations for security enhancements. Below is a quick snapshot of the transport layer security of existing northbound (NB) and southbound (SB) plugins. For example, OpenFlow specifies the use of TLS or UDP/DTLS, which support authentication using certificates and encryption to secure the connection.


Figure – Transport Layer Security capabilities of SB & NB protocols (Source: ODL)

OpenDaylight recommendations for SDN controller security that are implemented in Helium and future releases include:


  • AAA service for applications/users/devices
  • Framework to securely and automatically discover, connect and configure the devices
  • Secure mechanism to cluster the controller for scalability and availability
  • Robust incident response support for controller/devices/user. E.g. A southbound syslog plugin to incorporate capture logs from devices in incident analysis
  • Secure communication channel to connect to plugins, common trusted crypto key storage for all plugins, pluggable or built-in Certificate Authority


How is the scale tilted?

Securing networks is becoming more challenging to businesses, especially with BYOD and increased cloud adoption, if not yet due to other mass phenomena such as Internet-of-Everything. Organizations can certainly protect themselves better through automated and dynamic security solutions made possible through SDN, as it provides a centralized intelligence and control model that is well suited to provide much-needed flexibility to network security deployments.

With SDN, we can add agility to network intrusion responses and go beyond the network to protect what is actually of interest, namely applications. Focus on network security was more an interim arrangement as there existed a network visibility deficit at the higher layers. However, by focusing on the network all these years, we lost the most important context awareness which will help deduce if the application or user is doing what is allowed to be done. Security-centric SDN allows an organization to deploy a quick, decisive and deep enterprise-wide response to threat on all fronts. An integrated solution comprising both network and application-layer elements will ultimately provide the comprehensive ‘top-to-bottom of the stack’ security desperately needed to defend against attackers in the dynamic threat landscape.

The key to realizing self-defending networks, however, is “lower false positives” combined with “actionable-threat-intelligence”, given the lack of human element to weed out false alarms or manually correlate event logs to decide on the course of action, in the SDN driven security architecture.  The ecosystem of network security vendors, threat intelligence providers, and security professionals should strive for highly accurate intelligence so that automated security remediation decisions are made with a high-degree of confidence. Also, SDN technologies will need to continually evolve to enhance their inherent security capabilities to avoid being a dampener to adoption.

Adoption of SDN will force NetOps and SecOps to work together more closely, even if they aren’t merged into a single organization as few propose or atleast foresee to happen. This could be a bigger change than the driving technology per se, and one that could meet with opposition, given the organizational dynamics involved. Let’s wait and watch how these play out and if enterprises are able to tap into security-centric SDN benefits.

Meanwhile, how do you think the balance is tilted? Will security drive or hinder SDN adoption? Also, a clarion call to security professionals out there to critique my post. Look forward to learning from your feedback too, while I try to get a better handle on security.

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.

What business potential does SDN hold?

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


  • How will SDN impact customer spending in existing market?
  • 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.


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.



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. 

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. 

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. 

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. 

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_citrixNetScalerlogo_coriantIntelligent Optical Control (IOC)
logo_cyanBlue Planet
logo_dellActive Fabric
logo_etriETRI
logo_extremenetODP-based with extensions
logo_hpVirtual Application Networkslogo_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 PF6800logo_nttRyu OpenFlow (used by Pica8 too)logo_nuageVirtualized Services (VSC)
logo_oracleOraclelogo_plexxiPlexxi Controllogo_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_6wind6WindGatelogo_aricent
Fast Path Accelerator
logo_bigswitch
Switch Light
logo_brocade_0Vyatta 5400/5600 vRouterlogo_microsoftCisco vPE-Flogo_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 VendorsCustomersDeployment Usecases
logo_contextremelogo_verizonSP Carrier Network
logo_bigswitchlogo_csmresearchPrivate Cloud
logo_huaweilogo_chinatelData Centers
logo_huaweilogo_21vianetCloud Data Centers
logo_neclogo_nttCloud Data Centers
logo_niciralogo_ebayData Centers (Prior to VMWare acquisition)
logo_niciralogo_rackspaceData 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!