The obstacles before Microsoft's Open Line System

Last month a network executive from Microsoft used the Optical Society of America's Executive Forum to publicly air a request that sources say he and others at Web 2.0 companies have been making in private. Microsoft wants an optical transport system closely tailored to the company's data center interconnectivity needs. Given the growing interest in the increasingly free-spending Internet companies, it's not surprising that several technology vendors on the OFC 2015 exhibit floor expressed interest in meeting the request. However, that doesn't mean Microsoft and other Web 2.0 companies will get what they want anytime soon.

Jeff Cox, senior director, network architecture, for Microsoft's Azure Global Network Services, used his Executive Forum keynote presentation to describe Microsoft's vision of what he called an Open Line System. The platform, not surprisingly, would not only contain all of the features Microsoft wants, but none of the features it doesn't. Many of the unwanted characteristics are common to current metro and long-haul transport systems.

The "don't want" list underscores the difference between the requirements of a typical carrier service provider and those of data center network operators. In particular, the latter don't have legacy services to support and favor the packet-layer-centric operation to which they're accustomed in data center networks. Therefore, features Cox said he didn't need include:

• Electrical OTU switching (since Microsoft uses the largest channels available between switches)
• Optical protection and restoration (this is done at the packet level)
• Packet aggregation (ditto)
• Optical bandwidth on demand (because they want all of it all the time)
• Demarcation between the packet and optical layers
• Optical transmission other than coherent.
  

So what does that leave? A simplified platform that contains just the functions required to link two data centers together at either metro or long-haul distances: coherent optical transmission, amplification, gain equalization, maybe some ROADM functionality, etc. The platform would have a RestConf/Yang open API for the network elements layer that exposes telemetry and control information. There would be standardized modeling of network elements and transceivers. Oh, and those coherent transceivers would be interoperable, regardless of their suppliers.

The last two years have seen a spate of new systems unveiled for data center interconnect by companies such as BTI Systems, Cyan, and Infinera. Cisco is said to have a new platform for this application near completion, while ADVA Optical Networking has been privately discussing a concept it calls Open Optical Line Systems for terabit-scale network requirements in a multivendor environment.

What stands in the way

Asked at the Executive Forum how closely these offerings met his vision, Cox said he's starting to see some buy-in from the vendor community. But he stopped short of embracing any of the announced offerings.

One hurdle to meeting Microsoft's goal expressed repeatedly among sources tapped on the OFC show floor was the perceived lack of commonality among the requirements sought by Microsoft and its peers. While Microsoft would represent an attractive customer, it might not buy enough equipment on its own to offset the research and engineering costs a systems house might incur to create a custom product. This is particularly true if Microsoft (and other Web 2.0 companies) view these platforms as being as expendable as the servers they turn over every three years. So unless a systems house has something dead-on already in the pipeline, significant risk would have to be embraced.

However, module and subsystems companies that design custom line cards for their systems customers might find such a business case appealing. A source at JDSU, which has had success with its Super Transport Blade line, said the company sees the Open Line System concept as a potential opportunity. Finisar likely would investigate what role it could play as well.

But these companies would face obstacles as well. The line cards would have to be inserted into a box, which would mean either Microsoft would have to find a supplier for that separately, build it itself, or have the subsystem company step up. Any of these options could work, but Microsoft would have to choose one. Also, a JDSU or Finisar likely would first offer a line card populated entirely with its own modules and components. If Microsoft wanted a best-of-breed approach, that would mean more negotiations or working with a systems integrator.

Finally, there's the question of interoperability. The advent of merchant coherent DSPs from companies such as ClariPhy Communications and NEL that support pluggable CFP2 optical transceivers would appear a step in the direction Microsoft wants to go. However, the two companies' DSPs currently don't talk to each other. Acacia Communications has conducted interoperability demonstrations between its DSP and NEL's, but only in the comparatively low-performance ZR mode (see "NTT Electronics, Acacia Communications verify coherent ASIC interoperability"). And it would have to sell its DSP as a standalone product to whomever was building the line cards for this level of interoperability to be an option.

So Microsoft might have to compromise by selecting a single DSP supplier – and then sticking with it through various generations of the Open Line System until interoperability among DSPs arrives. In fact, as things currently stand, it appears Microsoft and its peers will have to make several compromises now or show patience for later in the quest for a fully optimized optical transport platform for data center interconnectivity.

For more information on high-speed transmission systems and suppliers, visit the Lightwave Buyer's Guide.