The Evolution of Smart OTN

Release Date:2013-07-17 By Hong Yu

 

Technological Evolution

Smart optical transport networks have evolved because of new optical networking applications and demands. Compared with a traditional transport network, a smart OTN has an independent control plane for dynamic connections that involve routing, signal processing, auto discovery, connection control, and protective restoration. The control plane also supports a variety of new services, and bandwidth is allocated in real time according to actual needs. This makes traffic engineering easier in optical channels and also makes it easier to quickly introduce value-added services.

 

OTN control plane

An OTN control plane is developed on the basis of an automatically switched optical network. A traditional wavelength-switched optical network schedules only single wavelengths whereas an optoelectronic hybrid OTN schedules both the optical and electronic layers in a unified way. As OTN evolves, the control plane needs to schedule large-granularity services that have the capacity for widespread interconnection. The OTN control plane also needs to dynamically adjust the bandwidth in order to manage and control switching devices at multiple layers. Increasingly, the role of the control plane in the OTN is becoming important.

 

Unified control plane

Convergence is an inevitable trend in bearer networks. The control plane, therefore, is developing towards multilayer and multidomain resource control. Vertically, the control plane supports IP/MPLS, SDH/PTN, and WDM/OTN switching technologies and VC, STM, and ODUk switching granularities. Horizontally, the control plane allows interoperability between different operators and manufacturers. The control range has been extended from SDH to WDM/OTN and PTN/CE. This means that the control planes of different switching technologies are interoperable or form a unified plane to control different switching technologies. This requirement has become the focus of attention of standards organizations and operators. Leading telecom vendors have put forward their own solutions and demonstration systems. Generalized multiprotocol label switching (GMPLS) allows control of PSC, L2SC, TDM, LSC, and FSC switching and all types of devices in a bearer network. GMPLS allows the control plane to be easily extended so that it can control networks and devices with different switching technologies and granularities.

The control plane does not yet support all PSC, L2SC, TDM, LSC, and FSC switching granularities. However, the topology for dual-layer device scheduling (i.e. ROADM + OTN and PTN + OTN) has been widely accepted in the industry and will evolve to support multilayer device scheduling.

A unified control plane can control switching devices or networking at multiple layers, but it has issues in terms of protocol extension and standardization. GMPLS is currently the only protocol suite that can control devices at all PSC, L2SC, TDM, and LSC layers. GMPLS has therefore become the preferred protocol suite for a unified control plane.

In an environment with multiple operators and vendors, issues with interoperability often hinder network development. Each operator requires services to be quickly assigned, connection paths to be optimized, and privacy to be protected. To implement large-scale networking, overlay, peer, and border peer networking models can be used. UNI, E-NNI, and I-NNI interfaces can also be used.  

 

Development of Programmable OTN

Unlike traditional optical networks, future software-defined networks (SDNs) will be highly programmable. In an SDN, resources and operations at the transport layer can be opened to APPs and can be controlled at the network control layer in a centralized and personalized way.  

Programmability implies the capacity to alter a command as needed. The programmability of the transport layer is based on the programmability of its components so that node devices are more programmable and capability resources and information can be abstracted in the controller. In this way, the SDN transport layer is highly programmable and capable of optimizing resource scheduling. A controller provides unified traffic flow control for optical, electrical, and packet-switching devices of different granularities. This helps converge the network and unify resource scheduling. 

A software-defined network can

●    satisfy user demand for network programming. This improves user experience; provides flexibility in device usage, operation and sales; shortens the service-development period; cuts hardware costs; and helps operators reduce opex and create new profit models. 

●    virtualize network resources. This makes all OTN products manageable.

●    leverage centralized computing. This helps operators uniformly optimize and schedule resources and obtain information about resources in a timely manner. 

●    provide openness and flexibility. This helps operators build an efficient, flexible, open OTN in the cloud era. 

 

Component programmability

With a software-defined optical module (Fig. 1), spectrum efficiency and compensation algorithms can be selected according to link state. Such algorithms are programmable: Impairment compensation algorithms and forward error correction, types and formats can be changed.


With tunable mux, demux, and WSS, grid width and filter shapes can be selected according to the signal spectrum width and number of cascades. Grid width and spectral shapes are programmable.

 

Node programmability

FLEX OTN allows rate adaptation and multiplexing, and the size of a flexible ODUC/OTUC container is programmable (Fig. 2). In a TDM/packet hybrid scheduling scenario, the electrical switching granularity is programmable. 


FLEX ROADM allows optical switching based on spectrum resources. In the grid, the optical switching granularity is programmable, and in the transport channel, spectrum combination/separation is also programmable.

Nodes can be virtualized and combined, and the scale of nodes is programmable. A single physical node may be virtualized into multiple logical nodes, or multiple physical nodes may be virtualized into one logical node.

 

Network programmability

Network programmability allows resources in the network to be abstracted and changed as required during service scheduling. Network programmability involves bandwidth on demand and technology as a service. With bandwidth on demand, a connection can be selected according to actual needs. Bandwidth type (TDM/packet), size, latency, and QoS can be changed. With technology as a service, different logical subnets are virtualized for different users so that different bearing requirements are met. Network type (packet, subwavelength or wavelength switching) is changeable, and the number of ports, nodes, fibers, and connections are also changeable.

 

Conclusion

In the evolution of smart OTN, the transport plane and control technologies have developed. The transport plane includes open interfaces and decoupled software/hardware functionality and is evolving towards programmability. Control technologies are evolving from distributed, single-domain network control to centralized, multilayer, multidomain network collaboration.