Revolutions have to unite before they can disrupt. A bunch of isolated dissidents can’t really hope to do much except create a higher local noise level, but a united crowd can move a society—or in our case, an industry. Telecom is undergoing a revolution right now, created by the irresistible force of falling operator profit per bit meeting the immovable object of vendor desire to preserve the status quo. The “streets” the operators are taking their movement to are the industry forums and open-source projects.
AT&T says that it’s going to deploy about 60 thousand white-box switches based on its dNOS open-source operating system, as part of its 5G deployment. Operator board members have redirected the work of the ONF to accommodate operators’ need for radical changes in how networks are built, changes that would impact legacy vendors. Operator interest in open-source network projects has exploded, and they now seem to be driving these initiatives rather than sitting around passively waiting for vendors to introduce the Next Big (proprietary, expensive) Thing.
This is hardly a new problem, a new kind of creative tension. Vendors have for decades resisted changes that put their own business models at risk, and it’s unrealistic to assume they’d do otherwise. However, there’s a time when, as water is washing around your waist, you have to figure that the finger-in-the-dike approach is running out of gas. Operators provided vendors with specific warnings of their profit-per-bit problem starting in 2012, and they provided an estimate of when they needed to have a solution. This year is the end of that estimate period.
The right approach for vendors would have been to address operations efficiency immediately, through aggressive support of full-scope service lifecycle automation (now popularly called “zero-touch automation”). Vendors didn’t do that, and in fact still haven’t put their heart into the efforts, largely because they saw a broad strategy for ZTA reducing their own competitive differentiation. So operators picked up that ball, in the form of the ONAP/ECOMP initiative now gaining traction at a rather incredible pace. Emboldened, operators are leveraging what they’ve learned, and vendors continue to hunker down and protect a diminishing patch of influence.
The trend toward an operator-driven universal service lifecycle automation approach is incredibly risky for vendors, not so much because of that loss of possible operations differentiation that vendors feared, but because of the experience operators are gaining in cooperating and controlling open-source projects. Open-source has always been the big risk for vendors, a way for operators to create commodity technology. Would AT&T, whose ECOMP launched the current ONAP stuff, have started its open-source work by defining a switch OS, having no real experience in open-source? I don’t think so; they needed to start work doing something that they understood better, which was operations automation.
Open-source initiatives are big news for operators trying to control their own cost destiny. They translate directly to product, unlike standards groups that take forever to get somewhere, which then may turn out to be the wrong place. The open-source groups, like the Linux Foundation, have seen the light and are taking steps to be operator-friendly. The Linux Foundation’s Linux Networking Fund (LNF) is a sandbox for operator-centric network platform elements, including ONAP, and it’s increasingly taking a role of selecting stuff that’s important to operators and framing it in a broad ecosystemic context.
What’s also happening is that operators are expanding their focus from operations to devices. White-box OSs like dNOS offer operators not only an opportunity to adopt SDN, but also the opportunity to adopt an open form of traditional switching and routing. Best of all, the operators can unite this with ONAP/ECOMP to operationalize the new environment efficiently. That gives operators both capex reduction and opex improvement.
Another interesting initiative is the one involving ONF and ONAP to integrate optical management and agile optical technology into the overall service management automation/orchestration processes. This suggests that AT&T, a driver in the initiative, intends to integrate optical management into zero-touch lifecycle automation. That, of course, also means that open optical gear is likely to come along later, though margins on optical-layer technology are lower and so that layer of the network isn’t a primary target for aggressive cost-cutting.
It’s fair to ask what all of this could mean for the “establishment” technologies in transformation, like SDN and NFV. On the surface, SDN could be advanced by white-box, but if dNOS follows the path that the ONF established, it could just as easily be used to host legacy switch and router software, and perhaps is more likely to do that because the cost improvement for operators would be realized faster. On the surface, NFV might also advance because linking NFV better to ONAP could resolve the benefit shortage that’s hampering NFV adoption. Dig deeper, and it also threatens NFV’s existence.
Let’s start with SDN. Operators have often argued that we don’t need a new forwarding paradigm or to substitute central explicit routing for adaptive routing. They’ve voted that point with their wallets, continuing to deploy classic routers and switches. I think that agile devices, because they can easily transform from legacy adaptive behavior to centrally controlled behavior, offer an easier transformation path, but that doesn’t mean anyone will take it. Look for some improvement in SDN adoption rates, but not a revolution.
The NFV picture seems more complicated, because it’s hard to say what is really driving NFV at this point. Fortunately, the possible drivers seem to be converging on the same outcome. If you track current adoption, then the NFV driver is virtual CPE. Clearly a dNOS-type solution and a white box could do the same, with no need for unproven approaches. If you believe that 5G will drive NFV, then AT&T seems to be announcing they’ll depend on dNOS and white boxes instead. That these would be cell-site routers means that the majority of the gear associated with 5G might be dNOS-based, not NFV-hosted.
The end-game for operators is simple; drive cost out of networking even if it means destabilizing current equipment vendors. After all, they reason, current vendors have stuck it to us for decades. It might well be too late for vendors to respond to this in any constructive way, even assuming they were willing to bite the bullet they’ve refused to chew on so far—reduce their profits by supporting open technology.
Some of the changes I’ve noted here have other implications. One good example is the whole issue of “operator leadership”. The ONF has changed its web site, with the opening line being “The ONF is an Operator Led Consortium” whose goal is “Transforming Networks into Agile Platforms for Service Delivery”. I remember that a decade ago, the IPsphere Forum was absorbed by the TMF because many of the EU operators had been told by their legal departments that the operator-control aspect of the organizations created a risk of a collusion charge by regulators. Apparently that risk has passed, and if that’s true then the current operator steps are only the beginning.
This isn’t the only legal/regulatory issue that the current trend is exposing. Huawei is a major figure in many of the open and open-source ventures just announced, and ZTE is also involved in some. In the US, both companies are under pressure because of their Chinese origins. The FCC doesn’t want to allow any broadband subsidies to be spent on products from China, Best Buy is dropping Huawei products, and the Administration is looking at ways to stop Chinese investment in strategic tech companies. Might this taint open-source participation by Chinese companies, or sponsorship of open federations by those same companies? Remember that US operators are already effectively barred from deploying Chinese network technology.
Perhaps the most fundamental question to be addressed in achieving this happy, open, future is the usual “who pays?” question. Vendors have long been the drivers behind all technology initiatives, including open-source. What will happen if vendors lose so much margin they can’t justify spending on personnel to do what’s essentially community development? We already see some vendors ceding their stuff to open-source. Suppose everyone does, then nobody commits bodies to sustaining it?
We’re at the start of something big, but we’ve been here before with other initiatives. I’d like to believe that open-source was going to burst onto the scene and change the market, but we still have issues that could derail things, including the three I just mentioned. There’s still time for vendors and operators alike to tune and refine their processes and avoid anything that could slow things down. Can buyers and sellers cooperate, though? That would be a real revolution.
