My name is Craig Thompson, I run an advanced marketing and technology group inside Finisar and my team is leading a lot of the integration of open switching and networking ecosystem into our existing portfolio, and I'm happy to be here today to talk a little bit of how optics is a key part of this new movement in open networking.

For those of you who don't know much about Finisar, we are the world's largest supplier of Fiber-optic components and subsystems. Our revenue is currently about 1.3 billion in our latest year earnings.

Open Network deployments are responsible for over 20% of our revenue today, and this is a key data point for everybody to remember and understand because of 2 reasons:

• Open Networking deployments are real and happening at scale today
• Optics is one of the first places that any network deployment can begin to disaggregate

Finisar is a worldwide company, and we have R&D throughout the world including here in Berlin, Germany. We have approximately 14,000 employees, most of that is manufacturing. We’re vertically integrated and we own and develop all the technology that is inside our modules, so when you buy a Finisar module, we've been responsible for every aspect of that, from the laser, the photodiode, the IC, the software and the firmware. It all comes from us.

Here are some of the products that we sell, we tend to break our business down into Datacom and Telecom.

Fig. 1 - Datacom Products

For those involved within the Datacenter, most of what we sell is pluggable optical transceivers, which are going to into the vast majority of networks today [Fig. 1].

Fig. 2 - Telecom Products

We’re also still heavily into the telecom segment with products that you see here [Fig. 2]. We have a very broad portfolio, I would say it's the broadest portfolio in the industry, there’s not too much we don't do in this area.

Fig. 3 - Software Stack

Here is a software stack [Fig. 3], we focus on the hardware layer but work very closely with switching silicon vendors, with OEMs, increasingly with switch system providers like Accton/Edgecore and more and more with software, and I'll talk a little bit about why that is.

The history of networking equipment, and even optics, has started and ended with the OEMs. The OEMs not only ensured that all that hardware and software worked well together, they also ensured that the optic worked inside that networking element. For many customers that's good, there are customers in the world that will continue to buy OEM because they need to, they don't have the in-house IT support to benefit from open hardware and open software, but I think everyone in this room is here because they have some curiosity about the benefits of open hardware and software.

Finisar is a pioneer of digital optical monitoring if we were to roll out a new feature inside our optical module for example - monitoring very specific controls in the module, like temperature, receive power, transmitted power, and communicate that through the software stack, we were dependent on the OEM to expose those features.

If we released a new feature, it could be a year or two sometimes even more before that feature would reach the end user. More often than not, there will be no feedback loop, so even if said OEM exposed that feature we’d have no idea whether it was valued or whether it was useful or what things we could improve. That's all being changed now with Open Networking.

The Open Networking stack, just to compare and contrast with the OEM, looks complicated but every day the APIs, productivity, and solutions are all improving, and this is starting to come together very quickly.

To compare and contrast to the OEM side, now that we are selling optics into this Open Network ecosystem, we're able to innovate much faster. We're able to get user feedback much more quickly and we're able to roll out features and test them, and that's the power of this movement and one of the reasons why we're investing heavily in this area.

I'm going to focus mostly on the Open Networking stack and how optics fit into it. I want to talk a little bit about the kinds of attributes that have made optics so successful in integrating into this open networking ecosystem and I’ll walk through these one at a time.

1. Standards
   We've been diligent in establishing standards in the market to allow any hardware to plug into a switch and it will pass data, it may not give you all the fancy features that you may want, it may not do everything that you expect it to do, but it will at least pass data. So standards are critical in developing an open ecosystem for optics.
    
2. Interoperability
   This is a topic that we've been very passionate about and we've been sponsoring through Open Compute.
    
3. Open APIs
   Open APIs with respect to optics.
    
4. Innovation
   I'm going to talk about the pace of innovation, that now that we touch the end-user, and we're able to take feedback from you and improve the product rapidly and get new features out into the market. And then there are other things: quality, reliability, supply, these are really critical, they are very important   if you buy a Finisar Transceiver today I can guarantee that it has the same reliability, the same quality, and the same supply chain as what Cisco and HP buys, the quality is consistent in our products. We are a trusted brand, and there should not be any hesitation to buy a Finisar branded optic and put it into an Open Switch port.

Standards

Standards are complicated and rapidly evolving, and we're a driving force in making sure that we focus on the right things in the industry and establish good baseline standards for the optic to work inside the element. There are a number of bodies that are involved in driving standards, we're a leader in all of them [Fig 4], some of them an industry-wide standard bodies like IEEE and OIF, others are our smaller multi-source agreement bodies that guarantee form factor or optical interface.

Fig. 4 - Standards; within/between/long spans between the Data Center Rack

If you look at some of the recent trends in the Data Center [Fig. 4], we've been shipping 10G SFP+ for quite a few years now, we're just starting to ship in volume 25GbE and in multiples of 25GbE, and 50GbE and 100GbE to the server is being standardized today, so the pace in which this is being rolled out now is staggering.

We've been shipping 40GE for a long time now, this is now in high-volume, we've also been shipping 100GE for some time now into the Telco network, but we're just on the verge of rolling out 100GE at scale into the Data Center. The mega operators are well on their way rolling out 100GE at scale and to continue the story, 200GE and 400GE is being standardized today and we expect to see the first deployment of these interfaces over the next 2 years.

For the longest spans between Data Centers and into the WAN, we've been shipping 100GE for some time, and here is where you start to get into the longer reaches you move away from SR and LR into ER, 40km, and even beyond with coherent technology. We're working on 400GE and even going beyond that for inter-Data Center links.

So this is a lot of work but this is key for making sure that you guys have the confidence that optics will work inside of an open switch port.

 Interoperability

The Open Compute Project (OCP) has been playing a key role in ensuring interoperability within open networking hardware and we've been a key participant in that.

The OCP has been working with the University of New Hampshire at the InterOperability Lab (IOL) for some time and they've run through 3 or 4 Plugfests that involve combinations of switch hardware, NOS, and cable module combinations to ensure that they work consistently and as predicted. Once these combinations are tested, they get added to an integrators list [Image on Left], you can see Edgecore hardware there, you can see Finisar modules, and you can see that we have operating systems that fully been tested and are compliant. This testing is now occurring weekly, there are major Plugfests multiple times a year, but ongoing testing on a weekly basis.

Open APIs

One of the big issues that has come up in this movement towards open software is the ability to control and monitor the optical physical layer. Going back to the OEMs, they would take care of that in their own time. They would pick and choose what the end user could see and what they could control, that's all been thrown out wide open now, but there has been an issue that came up within the last year or two about how to do a consistent decode of all the information on these optical modules, things like receive power, transmitted power, voltage rails, or even basic information like the serial number of that transceiver, where it was manufactured. There wasn't a consistent way to decode this information in an open hardware infrastructure.

We kicked off a project which we call Open Optical Monitoring (OOM), which was launched within the Open Compute networking group back in October 2015 to address this problem of consistent, reliable, decode of information from the optical transceiver, the optical physical layer. We worked together with Accton/Edgecore, Broadcom, Cumulus and Big Switch to come up with an architecture and a solution to do a consistent decode of all this information from the transceiver and transport that in an open extensible API for applications to be able to use in some way, shape, or form.

So, what is Open Optical Monitoring? For you software folks, it's a Python package, it's a library that sits in user space in a Linux stack. It provides a standard API northbound to access the data that’s encoded on the transceiver in memory and it decodes that the data by key value pairs that have been defined and provides a Python interface that you can script and do interesting things with.

It works on any Linux based NOS, on any switch, it works with any optical module, not just Finisar, if the optical module is MSA-compliant it will decode the information consistently from that module. All that it requires to make this work is a very simple shim layer that's specific to the Linux OS that you're using. We’ve developed half a dozen different shims, 99% of the Linux operating systems out there today now work with this.

It's open source, it's easy to maintain, you can download it off GitHub today, and you can improve the code, post the back, do all sorts of interesting things. With just a few lines of code, a few lines of Python script, you can extract information from the optical module, the optical physical layer and communicate that to a monitoring application or Diagnostics tool or a database.

Fig. 5 – Open Optical Monitoring (OOM) Applications

What can you do with this sort of information? [Fig. 5] A lot of people do very basic things in fact, simply inventory in the ports in the network and the modules that are in those switches, a very simple but powerful tool that hasn't been available up until recently.

• Health Monitoring
• Diagnostics
• Built-in self-test
• Connectivity Diagnostics

Health monitoring

You can monitor the health of the physical layer in the in the network so that could simply be “Are all my transceivers working within the normal operating range?” or “If one goes into an alarm state what's causing that alarm?”. We monitor things like transmit received power, laser bias, and temperature, in order to provide that extra layer of monitoring and control in a very largescale network and use the as starting point to incorporate that into their network management systems.

Fig. 6 – Open Optical Monitoring Demonstration at Datacenter Transformation 2016

We have a demonstration next door [Fig. 6] about this OOM functionality and you’re welcome to come by have a look. A lot of this is enabled by what we call digital optical monitoring which was really a technology that we pioneered and released into the industry.

Diagnoistics

You can also take that information and do more intelligent analytics to isolate connectivity issues. For example, if you're getting intermittent errors on a on a particular link, you can very quickly isolate whether that's being caused by anything in the physical layer or not and that's again a very powerful tool. If you do decide or determine that it is being affected by the optical physical layer, then you can, through the software or through physical mechanisms, isolate and highlight that particular link and the optical modules that are involved in that error.

I think the power of this open API software is that extensive and we haven't even started to scratch the surface of what we can do with this sort of information and what new features that might rollout in the future. The optical monitoring decode library and the API allows for custom commands and extensibility, new features, and we've started to roll out some of these. We define what that command is, what that key value pair is and then we release it to user customers.

Built-in self-test

Another example is built-in self-test. We can generate a pattern inside the optical module transmitted over the link and then detect errors in the module separate from the host in real-time and that could allow for basic commissioning, so for example you've installed a thousand optical modules in a cluster and you want to run a full diagnostic before you place that cluster into the production network, you can quickly establish whether there is any issues with the physical connectivity. That's a very powerful tool.

Connectivity Diagnostics

We've also developed a technology called connectivity diagnostics, which includes out-of-band communication and physical indicators like an LED on the module [Image on Left], so that if one module goes into an alarm or warning state, he can notify its partner and notify the network operator which module is its partner link and then the network administrator then could turn on the LED. When they come around to replacing that network element or that optical module, it's very clear to the technician on the data center floor which ends of that link are being affected. It’s a very powerful tool.

We showed a lot of this at the OCP Summit in San Jose earlier this year, this was a rack that we put together [Fig. 9] to show the interoperability testing and then within this rack we were showing data that was being gathered in real time from the optical modules [Fig. 10] in the demonstration, so this was data being accessed by over an optical monitoring and being graph just with open-source graphing software.

Fig 9. Rack used in interoperability testing demo

Fig 10. Data collected in real-time from the optical modules during demo

We've started showing people graphical user interfaces with ideas of what you can do with this sort of information. Open Optical Monitoring is now an OCP accepted project, it's part of the networking group, and you can download it and start to use it and improve it, and we'd love to hear from you guys on how we can use and improve it. It's actually being used in the Plugfests, the interoperability testing, so the University of New Hampshire are using it to do a standard decode of all the EEPROM contents, from modules across the industry.

As I mentioned, multiple shims are available for just about every combination of hardware and software we can think of, over 200 Keys have been decoded for QSFP+, QSFP28, SFP+ and we're adding more every week. There's new form factors coming, there’s new functionality, we just keep adding to the library keys, and that's the power of the open networking software stack.

Fig. 11 Connectivity Diagnostics

Connectivity diagnostics [Fig. 11] combines out-of-band signalling between two transceivers at either end of the link, with pull tab LEDs. These LEDs can be triggered physically by pushing or pulling the tab or they could be triggered by software, either automatically by tying it to alarms and warnings, or from human intervention, so a network administrator can light these up as needed.

It's all Out-of-Band, it doesn't affect the high-speed data, it's currently shipping in our active optical cables, but we're going to roll this technology out across our entire product line.

Shortwave WDM

Finisar announced in the last year or so a new technology we called shortwave WDM or SWDM [Fig. 12], and if you're familiar with the physical layer, 10G was a single lane of 10G, 40G took that single lane of 10G and multiplied it by 4, and so, in a typical multimode implementation of 40G you had 4 fibers, each transmitting 10G.

Fig. 12. Shortwave WDM

It was very clear to us as we started to talk to Data Center operators and end users that they were running into a fiber resource problem, they were on 10G, they wanted to go to 40G or even to 100G but didn't have the fiber infrastructure to easily upgrade. And so that fast feedback loop led us to develop SWDM which allows for those four lines of 10G to be optically multiplexed or combined into a single fire and so that has led many of our end user customers now to consider much more cost-effective and rapid upgrades to 40G and 100G.

This is another example of the power of that fast feedback loop in Open Networking. And that technology doesn't have to be proprietary, you don't have to be locked in, like I mentioned earlier standards play an important part in this and so we go to great lengths to make sure that technology is accessible and we founded the SWDM Alliance to promote this sort of technology.

So in summary, optics in open switching is pervasive today. It is the starting point for any network disaggregation that you should consider, it's an obvious thing to do.

There are a number of things that you should care about in selecting a vendor for open optics and you should talk to us about how we can help.