There have been many different announcements about multilayer wide area network (WAN) virtualization and management demonstrations that control both the IP layer and optical layer of service provider networks through software-defined networking (SDN). As the industry moves beyond demonstrations to deployment and operationalization, it is important to try to understand not only the virtual world, but the physical world of optical networks, especially at Layer 0 (DWDM) and Layer 1 (OTN). These are some of the layers of the network that are often referred to as an “underlay.” For SDN control of the WAN to succeed in real-world scenarios outside a controlled lab or field trials, this underlay transport structure must be designed in a way that allows most if not all of its attributes to be controlled via software.

First, let’s look at DWDM, Layer 0. Many of the demonstrations showcase activating a 100 Gb/s wavelength on demand, selecting its color, configuring its launch power and setting other analog optical parameters. They may also include dynamically operating reconfigurable optical add-drop multiplexors (ROADMs) along the path to switch these new wavelength colors across the transport network.  To better understand how to get from demos to real deployments, we need to question the current technologies and resulting operational motions that are often employed in production today:

• Was the 100-Gb/s line card that hosts the activated wavelength already installed in the chassis and connected to the fiber but inactive? If so, is the cost of the card being carried on the books of the service provider, and are there multiple spare cards per chassis throughout the network waiting and ready for activation?
• Or alternately, was the card pulled from spares inventory or ordered from the vendor’s inventory and then installed? In either of these more typical cases, a manual human process is required, which fundamentally challenges the concept of automating the optical transport layer.
• These demonstrations often use a single wavelength on a fiber, which is not a real-world DWDM deployment scenario. So if there are multiple pre-existing waves on the fiber, does the introduction and powering-up of a new wavelength requiring tuning any of the adjacent wavelength parameters, or does the system automatically tune the other waves if needed to balance spectrum power?
• Is the ROADM infrastructure at intermediate sites completely colorless, directionless and contentionless (CDC), providing the flexibility to route this new wavelength without having to worry about wavelength blocking? If the ROADM is not CDC, then there will very likely be wavelength blocking, requiring human intervention or a planning tool that computes multiple best paths ahead of time, challenging the notion of on-demand activation.

These questions lead to the fact that 10 Gb/s, 40 Gb/s, and 100 Gb/s wavelengths at the transport layer in most cases today are not deployed until they are needed. I’m sure it is clear that it is impossible to software-virtualize the human installation of a muxponder or transponder line card unless you want to factor advanced robotics into the equation. One approach to this problem is to pre-deploy N number of DWDM line cards per site, but this tends to be expensive for the service provider if they have to carry the cards on the books or for margin-challenged vendors if they need to carry the inventory on their books.

A second approach is to leverage photonic integration. Let’s assume a hypothetical scenario where 1 Tb/s of capacity is delivered by a single card with 10 x 100 Gb/s channels versus a traditional approach of 10 separate 100-Gb/s line cards. Because of the cost-effectiveness of a single-card approach, the 1 Tb/s card could be divided into 100-Gb/s channels and licensed, so that only 100 Gb/s is initially “allowed” to transport traffic while the other nine 100 Gb/s channels are already lit, tuned, and locked but waiting to be software-activated to carry additional traffic.  Software activation could happen by applying a license from a pool under the auspices of an SDN controller, if and when additional bandwidth is needed.  The license could be permanently applied, or even further flexibility could be achieved if the license is time-based or movable to other routes. If optical routing or re-routing is needed, a full CDC ROADM implementation can complement the dynamic software control of optical routing without wavelength blocking concerns.

Now one might raise the same cost and inventory issues at the router layer, but unlike most 100 Gb/s transponders and muxponders which only provide a single wavelength per card, routers often offer N x 100 Gb/s (even up to 10 x 100 Gb/s) short-reach optics (gray wavelengths) connections to the transport layer in a single card. Since the provider needs to purchase and install this entire card, a similar licensing mechanism could be implemented under the auspices of an SDN controller. So if more router bandwidth was needed, a license could be applied to the router port to activate it. Similarly, if at that same node bandwidth at the transport layer is required, it could be allocated and activated.

Now let’s look at OTN switching layer of the transport network. What we have seen in the market in the last few years is broad adoption of systems that now integrate DWDM and OTN switching into a single system. Infonetics' "OTN, MPLS, and Control Plane Strategies: Global Service Provider Survey 2013" indicated that 96 percent of service providers will deploy OTN switching in the core, and over 90 percent of those desired an integrated OTN switching and DWDM platform by 2016.  By properly integrating the switching function without compromise into a non-blocking, multi-terabit system, it can allow any bandwidth service (from 1 Gb/s service to a 400 Gb/s service) to be cross-connected to/from any tributary port and to/from any DWDM wavelength, providing complete flexibility for service routing and a structure that can be easily controlled through application programming interfaces (APIs).

In contrast, let’s examine for a moment the more typical scenario of a static transponder or muxponder. These are implemented in a single line card with either one 100-Gb/s Ethernet port or 10 x 10-Gb/s Ethernet ports on one side, and a 100 Gb/s wavelength on the other side of the card. These inflexible architectures require extensive offline planning and manual operations because these circuits (services) are rigidly tied to the line cards, which are rigidly tied to specific wavelengths across each route — you can see the challenge that this sort of solution presents in fitting into a software-controllable environment. Turning back to the solution with integrated switching, one can appreciate how the bandwidth services are abstracted from the underlying optical waves by the any-to-any non-blocking switch fabric. This allows for the SDN controller to only see a flexible pool of bandwidth between two nodes that can be sliced up down to 1-Gb/s chunks, as opposed to multiple discrete and complex wavelengths with hard-wired 10-Gb/s and 100-Gb/s circuits.

So now we have a multilayer system that is non-blocking at both the OTN and DWDM switching layers, providing a full set of service creation and routing tools ready to be controlled by software. When combined with an intelligent control plane technology like GMPLS and a set of robust and clean APIs, one can present complete abstraction and software control of all transport attributes to an SDN controller. The controller sees only bandwidth capacity available between sites based on card and license inventory and can easily provision transport services into this pool of capacity to support services either delivered directly from the transport layer or from the router layer. Transport capacity can be deployed in fine-grained chunks down to 1 Gb/s to exactly match what is needed by the service requesting the bandwidth, and that capacity can be switched to any destination using the digital switching fabric or, if carried in a relatively full wavelength via the ROADM, switching functionality.  If more bandwidth is needed at the optical layer, a licensing mechanism can be used to software-activate service-ready bandwidth that has been “pre-lit.”

There are multiple use cases for this automation and virtualization of the transport layer. One is the ability to slice the transport network such that a customer can use a portal to allocate and control bandwidth and services as they see fit, all within a partition as defined by the service provider.  A second is where an SDN controller with global visibility and control of both the transport network and the router network can enable multilayer provisioning, which can provide operational efficiency gains and speed to service by unifying provisioning of a router service and required transport bandwidth through a single user interface.

Based on this same global view, a third use case is focused on multilayer optimization that can increase network efficiency dramatically and lower costs by reducing transit traffic through routers and keeping that traffic at the transport layer, where it has to be carried either way.  A fourth use case is multilayer coordination of protection mechanisms such as leveraging MPLS FRR at the router layer for port failures and fast shared mesh protection at the transport layer for fiber cuts.

So with the proper hardware and software technology, the transport and router layers can be automated to a point where minimal manual intervention is needed. Once we get down to Layer 0, in which photons need to be created efficiently, innovation in the physics domain becomes important.  The key thing to remember is that you can’t automate a process that requires a human, so architecting a Layer 0/Layer 1 system that provides the right level of abstraction and that enables software control of all key attributes balanced with a set of intelligent policy constraints is required.  Once this foundation is in place, a multilayer SDN implementation can be deployed, providing faster service delivery along with significant network capex and opex efficiency gains.

In a follow-on article, we’ll talk about the importance of controlling the underlay in the WAN and why overlay solutions that work reasonably well inside the data center may not measure up when the traffic exits into the WAN, where service providers must meet stringent SLA guarantees for QoS, latency, and uptime.