Is there a Role for GMPLS in Transport SDN?

By Chris Liou

Vice President, Network Strategy

After having an opportunity to present at TIP’13 last week on some of the collaboration done jointly with ESnet and Brookhaven National Labs in the emerging area of Transport SDN, it occurred to me that many have an instinctive negative reaction to the mention of GMPLS  and SDN in the same sentence.  After all, SDN, as currently defined, includes the fundamental principle of separating control plane from forwarding plane, and enabling external applications to directly program flows on packet forwarding hardware systems. SDN’s key premise is to migrate away from a model where the distributed control plane logic is tightly coupled with the vendor’s hardware platform, and instead, create an alternative model where the networking intelligence is logically centralized, and the actual control over the flow of packets is shifted to the SDN control layer.

This model is a paradigm shift for the packet world, as packet-based systems (switches, routers) are inherently connectionless systems, switching or forwarding packets on to their “next hop” and letting the next system make its own decision on what to do next with the incoming packets. The industry around these products evolved from a time way before cloud computing, where it was necessary to develop distributed routing protocols in order to make these connectionless systems viable and deployable.  Packets had to know what output port to head to in order to get closer towards its destination. Without the development of distributed control plane protocols to automate the propagation of this information, one might speculate that connectionless networking probably wouldn’t have flourished. With the emergence of SDN, however, the paths of packet flows can be externally and centrally computed and then programmed into packet forwarding systems through standard protocols like OpenFlow, giving network providers explicit control over how flows, which in today’s networks are taking on more circuit-like qualities, get routed through networks.

In the transport realm, however, centralized control, connection-oriented networking and circuit-like constructs are the norm. Transport SDN, which extends SDN’s openness and programmability concepts to the transport domain, has the inherent advantage of leveraging existing logically centralized paradigms for directly programming connections, as is often done via NMS/OSS systems, where network topology information resides. Some current next-generation transport solutions have enhanced this model with complementary distributed control plane technologies like GMPLS.

As an example, Infinera’s GMPLS technology is used by network providers worldwide for reliably discovering the network topology and reporting topological changes back to the centralized NMS/OSS, ensuring database consistency between the network and the NMS/OSS.  GMPLS is also leveraged as a means to reliably establish connections in real-time via robust signaling protocols, based on routing “instructions” provided by the centralized NMS/OSS, initiated either by point-and-click operations or software applications.  While the protocols utilized today within the management plane aren’t OpenFlow, the general paradigm of centralized control over connection-oriented systems is already broadly deployed today, making it easier to marry with SDN.

While the conventional transport networking paradigm is inherently more compatible with SDN concepts, many large networks today are deployed with GMPLS capabilities. The development of Transport SDN solutions will need to consider migration strategies as well as the best location for specific networking functions such as network discovery, path computation, and service protection & restoration.  Solutions need to be flexibly defined to accommodate providers who do not want every networking function logically centralized and who instead desire to extract the benefits of SDN without a wholesale network upgrade or loss of the GMPLS capabilities to which they have grown accustomed.

Specifically, GMPLS is a transport networking toolset employed worldwide to perform one or more of the following:

1. Automatically discover the network topology and provide timely updates as it changes
2. Compute and provision circuits based on provided routing constraints, triggered through one of several methods including via local command-line, external network management system, or through some management protocol
3. Provision and establish a circuit based on some externally computed path, using a robust signaling protocol
4. Dynamically restore a circuit on an available path through the network that is either pre-computed or dynamically computed

With GMPLS being an optional capability available in advanced transport systems, often peacefully coexisting side-by-side with explicitly configured cross-connects, it is no wonder its capabilities are broadly valued by service providers if only for the basic function of reliably and accurately reporting topology.

Will operators with large GMPLS deployments likely move wholesale to a “100% pure SDN” approach, devoid of any GMPLS technology?  Probably not. There are some transport networking functions that make sense to be centralized, but others which make more sense to keep distributed or localized to the transport system.  I submit a pragmatic hybrid approach to centralization/decentralization is what Transport SDN should consider, rather than necessarily subjecting its definition to the same technological principles applicable to packet switched networks.

Another important question to ask is what abstraction models should Transport SDN support for the applications layer. This will be the topic of a future blog.

Legal Disclaimer