Chinese Merchant-Silicon Vendor Joins ONF, Enters SDN Picture

Switching-silicon ODM/OEM Centec Networks last week became the latest company to join the Open Networking Foundation (ONF).

According to a press release, Centec is “committed to contributing to SDN development as a merchant silicon vendor and to pioneering in the promotion of SDN adoption in China.” From the ONF’s standpoint, the more merchant silicon on the market for OpenFlow switches, the better.  Expansion in China doubtless is a welcome prospect, too.

Established in 2005, Centec has been financed by China-Singapore Suzhou Industrial Park Venture Capital, Delta Venture Enterprise, Infinity I-China Investments (Israel), and Suzhou Rongda. A little more than a year ago, Centec announced a $10.7-million “C” round of financing, in which Delta Venture Enterprise, Infinity I-China Investments (Israel), and SuZhou Rongda participated.

Acquisition Rumor

Before that round was announced, Centec’s CEO James Sun, formerly of Cisco and of Fore Systems, told Light Reading’s Craig Matsumoto that the company aspired to become an alternative supplier to Broadcom in the Ethernet merchant-silicon market. As a Chinese company, Centec not surprisingly has cultivated relationships with Chinese carriers and network-gear vendors. In his Light Reading article, in fact, Matsumoto cited a rumor that Centec had declined an acquisition offer from HiSilicon Technologies Co. Ltd., the semiconductor subsidiary of Huawei Technologies, China’s largest network-equipment vendor.

Huawei has been working not only to bolster its enterprise-networking presence, but also to figure out how best to utilize SDN and OpenFlow (and OpenStack, too).  Like Centec, Huawei is a member of the ONF, and it also has been active in IETF and IRTF discourse relating to SDN. What’s more, Huawei has been hiring SDN-savvy engineers in China and in the U.S.

As for Centec, the company made its debut on the SDN stage early this year at the Ethernet Technology Summit, where CEO James Sun gave a silicon vendor’s perspective on OpenFlow and spoke about the company’s plans to release a reference design based on Centec’s TransWarp switching silicon and an SDK with support for Open vSwitch 1.2. That reference design subsequently was showcased at the Open Networking Summit in April.

It will be interesting to see how Centec develops, both in competitive relation to Broadcom and within the context of the SDN ecosystem.

Advertisement

Cisco’s SDN Response: Mission Accomplished, but Long Battle Ahead

In concluding my last post, I said I would write a subsequent note on whether Cisco achieved its objectives in its rejoinder to software-defined networking (SDN) at the Cisco Live conference last week in San Diego.

As the largest player in network infrastructure, Cisco’s words carry considerable weight. When Cisco talks, its customers (and the industry ecosystem) listen. As such, we witnessed extensive coverage of the company’s Cisco Open Network Environment (Cisco ONE) proclamations last week.

Really, what Cisco announced with Cisco ONE was relatively modest and wholly unsurprising. What was surprising was the broad spectrum of reactions to what was effectively a positioning statement from the networking market’s leading vendor.

Mission Accomplished . . . For Now

And that positioning statement wasn’t so much about SDN, or about the switch-control protocol OpenFlow, but about something more specific to Cisco, whose installed base of customers, especially in the enterprise, is increasingly curious about SDN. Indeed, Cisco’s response to SDN should be seen, first and foremost, as a response to its customers. One could construe it as a cynical gesture to “freeze the market,” but that would not do full justice to the rationale. Instead, let’s just say that Cisco’s customers wanted to know how their vendor of choice would respond to SDN, and Cisco was more than willing to oblige.

In that regard, it was mission accomplished. Cisco gave its enterprise customers enough reason to put off a serious dalliance with SDN, at least for the foreseeable future (which isn’t that long). But that’s all it did. I didn’t see a vision from Cisco. What I saw was an effective counterpunch — but definitely not a knockout — against a long-term threat to its core market.

Cisco achieved its objective partly by offering its own take on network programmability, replete with a heavy emphasis on APIs and northbound interfaces; but it also did it partly by bashing OpenFlow, the open  protocol that effects physical separation of the network-element control and forwarding planes.

Conflating OpenFlow and SDN

In its criticism of OpenFlow, Cisco sought to conflate the protocol with the larger SDN architecture. As I and many others have noted repeatedly, OpenFlow is not SDN;  the two are not inseparable. It is possible to deliver an SDN architecture without OpenFlow. Even when OpenFlow is included, it’s a small part of the overall picture.  SDN is more than a mechanism by which a physically separate control plane directs packet forwarding on a switch.

If you listened to Cisco last week, however, you would have gotten the distinct impression that OpenFlow and SDN are indistinguishable, and that all that’s happening in SDN is a southbound conversation from a server-based software controller and OpenFlow-capable switches. That’s not true, but the Open Networking Foundation (ONF), the custodians of SDN and OpenFlow, has left an opening that Cisco is only too happy to exploit.

The fact is, the cloud service-provider principals steering the ONF see SDN playing a much bigger role than Cisco would have you believe. OpenFlow is a starting point. It is a means to, well, another means — because SDN is an enabler, too. What SDN enables is network virtualization and network programmability, but not how Cisco would like its customers to get there.

Cisco Knows SDN More Than OpenFlow

To illustrate my point, I refer you to the relatively crude ONF SDN architectural stack showcased in a white paper, Software-Defined Networking: The New Norm for Networks. If you consult the diagram in that document, you will see that OpenFlow is the connective tissue between the controller and the switch — what ONF’s Dan Pitt has described as an “open interface to packet forwarding” — but you will also see that there are abstraction layers that reside well above OpenFlow.

If you want an ever more detailed look at a “modern” SDN architecture, you can consult a presentation given by Cisco’s David Meyer earlier this year. That presentation features physical hardware at the base, with SDN components in the middle. These SDN components include the “forwarding interface abstraction” represented by OpenFlow, a network operation system (NOS) running on a controller (server), a “nypervisor” (network hypervisor), and a global management abstraction that interfaces with the control logic of higher-layer application (control) programs.

So, Cisco clearly knows that SDN comprises more than OpenFlow, but, in its statements last week at Cisco Live, the company preferred to use the protocol as a strawman in its arguments for Cisco-centric network programmability. You can’t blame Cisco, though. It has customers to serve — and to keep in the revenue- and profit-generating fold — and an enterprise-networking franchise to protect.

Mind the Gap

But why did the ONF leave this gap for Cisco to fill? It’s partly because the ONF isn’t overly concerned with the enterprise and partly because the ONF sees OpenFlow as an open, essential precondition for the higher, richer layers of the SDN architectural model.

Without the physical separation of the control plane from the forwarding plane, after all, some of the ONF’s service-provider constituency might not have been able to break free of vendor hegemony in their networks. What’s more, they wouldn’t be able to set the stage for low-priced, ODM-manufactured networking hardware built with merchant silicon.

As you can imagine, that is not the sort of change that Cisco can get behind, much less lead. Therefore, Cisco breaks out the brickbats and goes in hot pursuit of OpenFlow, which it then portrays as deficient for the purposes of far-reaching, north-and-south network programmability.

Exiting (Not Exciting) Plumbing

Make no mistake, though. The ONF has a vision, and it extends well beyond OpenFlow. At a conference in Garmisch, Germany, earlier this year, Dan Pitt, the ONF’s executive director, offered a presentation called “A Revolution in Networking and Standards,” and made the following comments:

“I think networking is going to become an integral part of computing in a way that makes it less important, because it’s less of a problem. It’s not the black sheep any longer. And the same tools you use to create an IT computing infrastructure or virtualization, performance, and policy will flow through to the network component of that as well, without special effort.

I think enterprises are going to be exiting technology – or exiting plumbing. They are not going to care about the plumbing, whether it’s their networks or the cloud networks that increasingly meet their needs, and the cloud services. They’re going to say, here’s the function or the feature I want for my business goal, and you make it happen. And somebody worries about the plumbing, but not as many people who worry about plumbing today. And if you’ve got this virtualized view, you don’t have to look at the plumbing. . . .

The operators are gradually becoming software companies and internet companies. They are bulking up on those skills. They want to be able to add those services and features themselves instead of relying on the vendors, and doing it quickly for their customers. It gives opportunities to operators that they didn’t have before of operating more diverse services and experimenting at low cost with new services.”

No Cartwheels

Again, this is not a vision that would have John Chambers doing cartwheels across the expansive Cisco campus.

While the ONF is making plans to address the northbound interfaces that are a major element in Cisco’s network programmability, it hasn’t done so yet. Even when it does, the ONF is unlikely to standardize higher-layer APIs, at least in the near term. Instead, those APIs will be associated with the controllers that get deployed in customer networks. In other words, the ONF will let the market decide.

On that tenet, Cisco can agree with the ONF. It, too, would like the market to decide, especially since its market presence — the investments customers have made in its routers and switches, and in its protocols and management tools — towers imperiously over the meager real estate being claimed in the nascent SDN market.

With all that Cisco network infrastructure deployed in customer networks, Cisco believes it’s in a commanding position to set the terms for how the network will deliver software intelligence to programmers of applications and management systems. Theoretically, that’s true, but the challenge for Cisco will be in successfully engaging a programming constituency that isn’t its core audience. Can Cisco do it? It will be a stretch.

Do They Get It?

All the while, the ONF and its service-provider backers will be advancing and promoting the SDN model and the network virtualization and programmability that accompany it. The question for the ONF is not whether its movers and shakers understand programmers — it’s pretty clear that Google, Facebook, Microsoft, and Yahoo are familiar with programmers — but whether the ONF understands and cares enough about the enterprise to make that market a priority in its technology roadmap.

If the ONF leaves the enterprise to the dictates of the Internet Engineering Task Force (IETF) and Institute of Electrical and Electronics Engineers (IEEE), Cisco is likely to maintain its enterprise dominance with an approach that provides some benefits of network programmability without the need for server-based controllers.

Meanwhile, as Tom Nolle, president of CIMI Corporation has pointed out, Cisco ONE also serves as a challenge to Cisco’s conventional networking competitors, which are devising their own answers to SDN.

But that is a different thread, and this one is too long already.

Direct from ODMs: The Hardware Complement to SDN

Subsequent to my return from Network Field Day 3, I read an interesting article published by Wired that dealt with the Internet giants’ shift toward buying networking gear from original design manufacturers (ODMs) rather than from brand-name OEMs such as Cisco, HP Networking, Juniper, and Dell’s Force10 Networks.

The development isn’t new — Andrew Schmitt, now an analyst at Infonetics, wrote about Google designing its own 10-GbE switches a few years ago — but the story confirmed that the trend is gaining momentum and drawing a crowd, which includes brokers and custom suppliers as well as increasing numbers of buyers.

In the Wired article, Google, Microsoft, Amazon, and Facebook were explicitly cited as web giants buying their switches directly from ODMs based in Taiwan and China. These same buyers previously procured their servers directly from ODMs, circumventing brand-name server vendors such as HP and Dell.  What they’re now doing with networking hardware, then, is a variation on an established theme.

The ONF Connection

Just as with servers, the web titans have their reasons for going directly to ODMs for their networking hardware. Sometimes they want a simpler switch than the brand-name networking vendors offer, and sometimes they want certain functionality that networking vendors do not provide in their commercial products. Most often, though, they’re looking for cheap commodity switches based on merchant silicon, which has become more than capable of handling the requirements the big service providers have in mind.

Software is part of the picture, too, but the Wired story didn’t touch on it. Look at the names of the Internet companies that have gone shopping for ODM switches: Google, Microsoft, Facebook, and Amazon.

What do those companies have in common besides their status as Internet giants and their purchases of copious amounts of networking gear? Yes, it’s true that they’re also cloud service providers. But there’s something else, too.

With the exception of Amazon, the other three are board members in good standing of the Open Networking Foundation (ONF). What’s more,  even though Amazon is not an ONF board member (or even a member), it shares the ONF’s philosophical outlook in relation to making networking infrastructure more flexible and responsive, less complex and costly, and generally getting it out of the way of critical data-center processes.

Pica8 and Cumulus

So, yes, software-defined networking (SDN) is the software complement to cloud-service providers’ direct procurement of networking hardware from ODMs.  In the ONF’s conception of SDN, the server-based controller maps application-driven traffic flows to switches running OpenFlow or some other mechanism that provides interaction between the controller and the switch. Therefore, switches for SDN environments don’t need to be as smart as conventional “vertically integrated” switches that combine packet forwarding and the control plane in the same box.

This isn’t just guesswork on my part. Two companies are cited in the Wired article as “brokers” and “arms dealers” between switch buyers and ODM suppliers. Pica8 is one, and Cumulus Networks is the other.

If you visit the Pica8 website,  you’ll see that the company’s goal is “to commoditize the network industry and to make the network platforms easy to program, robust to operate, and low-cost to procure.” The company says it is “committed to providing high-quality open software with commoditized switches to break the current performance/price barrier of the network industry.” The company’s latest switch, the Pronto 3920, uses Broadcom’s Trident+ chipset, which Pica8 says can be found in other ToR switches, including the Cisco Nexus 3064, Force10 S4810, IBM G8264, Arista 7050S, and Juniper QFC-3500.

That “high-quality open software” to which Pica8 refers? It features XORP open-source routing code, support for Open vSwitch and OpenFlow, and Linux. Pica8 also is a relatively longstanding member of ONF.

Hardware and Software Pedigrees

Cumulus Networks is the other switch arms dealer mentioned in the Wired article. There hasn’t been much public disclosure about Cumulus, and there isn’t much to see on the company’s website. From background information on the professional pasts of the company’s six principals, though, a picture emerges of a company that would be capable of putting together bespoke switch offerings, sourced directly from ODMs, much like those Pica8 delivers.

The co-founders of Cumulus are J.R. Rivers, quoted extensively in the Wired article, and Nolan Leake. A perusal of their LinkedIn profiles reveals that both describe Cumulus as “satisfying the networking needs of large Internet service clusters with high-performance, cost-effective networking equipment.”

Both men also worked at Cisco spin-in venture Nuova Systems, where Rivers served as vice president of systems architecture and Leake served in the “Office of the CTO.” Rivers has a hardware heritage, whereas Leake has a software background, beginning his career building a Java IDE and working at senior positions at VMware and 3Leaf Networks before joining Nuova.

Some of you might recall that 3Leaf’s assets were nearly acquired by Huawei, before the Chinese networking company withdrew its offer after meeting with strenuous objections from the Committee on Foreign Investment in the United States (CFIUS). It was just the latest setback for Huawei in its recurring and unsuccessful attempts to acquire American assets. 3Com, anyone?

For the record, Leake’s LinkedIn profile shows that his work at 3Leaf entailed leading “the development of a distributed virtual machine monitor that leveraged a ccNUMA ASIC to run multiple large (many-core) single system image OSes on a Infiniband-connected cluster of commodity x86 nodes.”

For Companies Not Named Google

Also at Cumulus is Shrijeet Mukherjee, who serves as the startup company’s vice president of software engineering. He was at Nuova, too, and worked at Cisco right up until early this year. At Cisco, Mukherjee focused on” virtualization-acceleration technologies, low-latency Ethernet solutions, Fibre Channel over Ethernet (FCoE), virtual switching, and data center networking technologies.” He boasts of having led the team that delivered the Cisco Virtualized Interface Card (vNIC) for the UCS server platform.

Another Nuova alumnus at Cumulus is Scott Feldman, who was employed at Cisco until May of last year. Among other projects, he served in a leading role on development of “Linux/ESX drivers for Cisco’s UCS vNIC.” (Do all these former Nuova guys at Cumulus realize that Cisco reportedly is offering big-bucks inducements to those who join its latest spin-in venture, Insieme?)

Before moving to Nuova and then to Cisco, J.R. Rivers was involved with Google’s in-house switch design. In the Wired article, Rivers explains the rationale behind Google’s switch design and the company’s evolving relationship with ODMs. Google originally bought switches designed by the ODMs, but now it designs its own switches and has the ODMs manufacture them to the specifications, similar to how Apple designs its iPads and iPhones, then  contracts with Foxconn for assembly.

Rivers notes, not without reason, that Google is an unusual company. It can easily design its own switches, but other service providers possess neither the engineering expertise nor the desire to pursue that option. Nonetheless, they still might want the cost savings that accrue from buying bare-bones switches directly from an ODM. This is the market Cumulus wishes to serve.

Enterprise/Cloud-Service Provider Split

Quoting Rivers from the Wired story:

“We’ve been working for the last year on opening up a supply chain for traditional ODMs who want to sell the hardware on the open market for whoever wants to buy. For the buyers, there can be some very meaningful cost savings. Companies like Cisco and Force10 are just buying from these same ODMs and marking things up. Now, you can go directly to the people who manufacture it.”

It has appeal, but only for large service providers, and perhaps also for very large companies that run prodigious server farms, such as some financial-services concerns. There’s no imminent danger of irrelevance for Cisco, Juniper, HP, or Dell, who still have the vast enterprise market and even many service providers to serve.

But this is a trend worth watching, illustrating the growing chasm between the DIY hardware and software mentality of the biggest cloud shops and the more conventional approach to networking taken by enterprises.

Fear Compels HP and Dell to Stick with PCs

For better or worse, Hewlett-Packard remains committed to the personal-computer business, neither selling off nor spinning off that unit in accordance with the wishes of its former CEO. At the same, Dell is claiming that it is “not really a PC company,” even though it will continue to sell an abundance of PCs.

Why are these two vendors staying the course in a low-margin business? The popular theory is that participation in the PC business affords supply-chain benefits such as lower costs for components that can be leveraged across servers. There might be some truth to that, but not as much as you might think.

At the outset, let’s be clear about something: Neither HP nor Dell manufactures its own PCs. Manufacture of personal computers has been outsourced to electronics manufacturing services (EMS) companies and original design manufacturers (ODMs).

Growing Role of the ODM

The latter do a lot more than assemble and manufacture PCs. They also provide outsourced R&D and design for OEM PC vendors.  As such, perhaps the greatest amount of added value that a Dell or an HP brings to its PCs is represented by the name on the bezel (the brand) and the sales channels and customer-support services (which also can be outsourced) they provide.

Major PC vendors many years ago decided to transfer manufacturing to third-party companies in Taiwan and China. Subsequently, they also increasingly chose to outsource product design. As a result, ODMs design and manufacture PCs. Typically ODMs will propose various designs to the PC vendors and will then build the models the vendors select. The PC vendor’s role in the design process often comes down to choosing the models they want, sometimes with vendor-specified tweaks for customization and market differentiation.

In short, PC vendors such as HP and Dell don’t really make PCs at all. They rebrand them and sell them, but their involvement in the actual creation of the computers has diminished markedly.

Apple Bucks the Trend 

At this point, you might be asking: What about Apple? Simply put, unlike its PC brethren, Apple always has insisted on controlling and owning a greater proportion of the value-added ingredients of its products.

Unlike Dell and HP, for example, Apple has its own operating system for its computers, tablets, and smartphones. Also unlike Dell and HP, Apple did not assign hardware design to ODMs. In seeking costs savings from outsourced design and manufacture, HP and Dell sacrificed control over and ownership of their portable and desktop PCs. Apple wagered that it could deliver a premium, higher-cost product with a unique look and feel. It won the bet.

A Spurious Claim?

Getting back to HP, does it actually derive economies of scale for its server business from the purchase of PC components in the supply chain? It’s possible, but it seems unlikely. The ODMs with which HP contracts for design and manufacture of its PCs would get a much better deal on component costs than would HP, and it’s now standard practice for those ODMs to buy common components that can be used in the manufacture and assembly of products for all their brand-name OEM customers. It’s not clear to me what proportion of components in HP’s PCs are supplied and integrated by the ODMs, but I suspect the percentage is substantial.

On the whole, then, HP and Dell might be advancing a spurious argument about remaining in the PC business because it confers savings on the purchase of components that can used in servers.

Diagnosing the Addiction

If so, then, why would HP and Dell remain in the PC game? Well, the answer is right there on the balance sheets of both companies. Despite attempts at diversification, and despite initiatives to transform into the next IBM, each company still has a revenue reliance on — perhaps even an addiction to — PCs.

According to calculations by Sterne Agee analyst Shaw Wu, about 70 to 75 percent of Dell revenue is connected to the sale of PCs. (Dell derived about 43 percent of its revenue directly from PCs in its most recent quarter.) In relative terms, HP’s revenue reliance on PCs is not as great — about 30% of direct revenue — but, when one considers the relationship between PCs and related related peripherals, including printers, the company’s PC exposure is considerable.

If either company were to exit the PC business, shareholders would react adversely. The departure from the PC business would leave a gaping revenue hole that would not be easy to fill. Yes, relative margins and profitability should improve, but at the cost of much lower channel and revenue profiles. Then there is the question of whether a serious strategic realignment would actually be successful. There’s risk in letting go of a bird in hand for one that’s not sure to be caught in the bush.

ODMs Squeeze Servers, Too

Let’s put aside, at least for this post, the question of whether it’s good strategy for Dell and HP to place so much emphasis on their server businesses. We know that the server business faces high-end disruption from ODMs, which increasingly offer hardware directly to large customers such as cloud service providers, oil-and-gas firms,  and major government agencies. The OEM (or vanity) server vendors still have the vast majority of their enterprise customers as buyers, but it’s fair to wonder about the long-term viability of that market, too.

As ODMs take on more of the R&D and design associated with server-hardware production, they must question just how much value the vanity OEM vendors are bringing to customers. I think the customers and vendors themselves are asking the same questions, because we’re now seeing a concerted effort in the server space by vendors such as Dell and HP to differentiate “above the board” with software and system innovations.

Fear Petrifies

Can HP really become a dominant purveyor of software and services to enterprises and cloud service providers? Can Dell be successful as a major player in the data center? Both companies would like to think that they can achieve those objectives, but it remains to be seen whether they have the courage of their convictions. Would they bet the business on such strategic shifts?

Aye, there’s the rub. Each is holding onto a commoditized, low-margin PC business not because they like being there, but because they’re afraid of being somewhere else.