Get started Bring yourself up to speed with our introductory content.

How the open transport switch will make operator SDN a reality

SDN holds plenty of promise in operator networks, but it'll take open transport switches to translate protocols like OpenFlow to the underlying network.

Editor's Note: In the first part of this series on SDN for optical transport networks, we discussed the challenges of applying centralized control and programmability to operator networks. In part two, we examine how open transport switches (OTS) can solve the problem by communicating between SDN controllers and components in optical transport networks.

Software-defined networking has the potential to radically change optical transport networks. Engineers will eventually be able to apply centralized control and programmability in order to optimize network resources and automate service provisioning. But before that can happen, technology providers must develop a way for centralized SDN controllers to speak to the optical network -- that's where the open transport switch comes in.

Most SDN technology has been developed for Ethernet networks. Generally the control plane and the data plane are disaggregated from the physical network and centralized into a software controller that manages flows all over the network. But optical transport networks often vary in architecture and protocol, making it a big challenge to decouple the control and data planes and apply one kind of controller over the network.

To tackle this challenge, a number of vendors are currently developing open transport switches (OTSes) that act as the intermediary between an SDN controller and an optical transport switch. An OTS communicates with the controller using the OpenFlow protocol and with the switch using the command syntax specific to that switch.

In a network consisting of a number of transport switches, the OTS assigned to each switch communicates the capabilities of that switch to the SDN controller. By gathering information from each switch including the number of links, link bandwidth, QoS characteristics and connectivity, the controller can create an overall view of the network. This network view enables the controller to respond to application requests for connections with specific bandwidth and QoS requirements while freeing the controller from dealing with the details of configuring and monitoring a variety of switch types from multiple vendors.

Internal modules on OTSes communicate hardware capabilities to the SDN controller, report state changes such as link failure or recovery, monitor performance, and configure hardware resources in response to controller commands. Due to differences in command syntax, each type of transport switch requires a specific OTS, but much code is common. Only the modules that interface directly to the hardware differ across OTS implementations.

How SDN controllers communicate through open transport switches

Open transport switches support two operation modes: explicit and implicit. In explicit mode, the SDN controller is aware of every transport switch in the network. Every switch must have an associated OTS implementation. To configure a connection, the controller must communicate with every OTS and switch along the path.

Implicit mode takes advantage of the existing routing and signaling control plane protocols within a transport domain. The SDN controller is aware only of the switches at the edges of the domain. Each edge switch must have an associated OTS, but switches purely internal within the network do not.

The controller creates a connection across the domain by communicating with the OTSes at each edge. The OTSes then use the existing control plane protocol, such as GMPLS, to connect to the switch at the other edge of the domain. The controller creates connections across multiple domains by configuring the links between the edge switches of each domain.

Use of implicit mode creates a migration path for network service providers. Open transport switches must be provided only for edge switches. Over time, a service provider could move to add more OTSes and switch to explicit mode, or continue using implicit mode. A hybrid environment, with implicit mode used in some parts of the network and explicit mode in other parts, is a third possibility.

A service provider can also partition a transport switch, implementing two or more OTSes, each managing a subset of the links. Each switch partition could be assigned to a specific customer in a multi-tenant environment.

Developers found that they needed to extend the OpenFlow protocol. Currently, OpenFlow deals only with packets. To support the transport network, it was necessary to add commands to deal with circuit switching, such as time-slots and cross-connects. Discussions are under way in the Open Networking Foundation on these and other extensions to OpenFlow.

Ciena spins up SDN test bed across U.S. and Canada

Ciena is working with research networks Internet 2, the Canadian CANARIE research network and the Starlight International exchange point to develop an SDN test bed that tests SDN in a realistic multilayer environment. The test bed was constructed with Ciena Ethernet and optical transport switches, all managed by an SDN controller.

The test bed currently connects Ciena facilities in Maryland and Canada with a connection to the Starlight exchange point in Chicago. It is expected to grow internationally with connections to other national research networks. In addition to current participants, network and service providers are expected to take advantage of the test bed to evaluate SDN for their own applications.

Cyan and Ericsson demo open transport switch solutions

Cyan, together with members of its Blue Orbit Ecosystem, demonstrated SDN optical network technology at Interop Tokyo last July. The Cyan Blue Planet SDN solution consists of Cyan's packet-optical transport platforms, along with components from other Blue Orbit Ecosystem partners, including Accedian Networks, Arista Networks, Canonical and Overture Networks. Cyan's solution also used RYU, an open source SDN controller software initially developed by NTT Laboratories. The solution demonstrated applications running in an OpenStack software environment, requesting services across the multi-vendor Ethernet and optical network.

Ericsson demonstrated its Service Provider SDN solution in February, 2013 at the Mobile World Congress in Barcelona. The demo showed SDN control of the data center and WAN, in addition to network and cloud management that integrated legacy and programmable interfaces.

Google puts SDN to use

Google's G-Scale network links data centers in Europe, North America and Asia. Commercial SDN-enabled equipment was not available when the project began early in 2010, so Google designed and built its own switches.

Staged deployment and testing took place through 2011, and the new network was fully deployed in 2012. Google found that use of SDN has increased network utilization to nearly 100%. The network has been stable, and QoS goals have been met.

The move to SDN in the optical transport layer is clearly under way. Service providers understand the benefits, but deployment will take time. Revenue depends on reliable network operation, so products will be tested carefully. Operational support systems and business support systems software will need to be modified, but after these steps are taken, the transition to SDN control of optical transport networks will certainly take place.

About the author:
David B. Jacobs of The Jacobs Group has more than 20 years of networking industry experience. He has managed leading-edge software development projects and consulted to Fortune 500 companies, as well as software startups.

Next Steps

SDN in optical networks means control and scalability

How SDN could bring automated provisioning to optical networks

The rise of multi-layer SDN

This was last published in March 2014

Dig Deeper on Software-defined networking

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.