No one will be surprised by startups and developments in the field of software-defined networks ( SDN ) - the topic is widely explored by both large global corporations and open source communities.

However, until recently, almost all developments were aimed at managing the infrastructure of data centers, and just a little more than a year ago, few believed that the SDN concept could be applied to transport networks ( transport networks ).

In October 2015, NetCracker’s T-SDN ( transport software-defined networks ) controller was deployed on the network of one of the European operators. The controller has automated a significant part of network operations and, as a result, has allowed the operator to save significant time - hundreds of hours that engineers spent on setting up the network and allocating the service.
')

Network structure

Network elements within the domains included ROADM / WSS cards, which are actually reconfigurable optical I / O multiplexers and allow changing signal paths between network elements. Inter-domain connections rose between client ports, these ports are on cards called transponders (an optical transponder is a device that provides an interface between the terminal access equipment and the WDM line). In our case, we used transponders with ten 10 Gbit / s ( IEEE 802.3ae ) client interfaces and an aggregating ODU4 . ODU is a container with data that provides control of this data all the way through and is part of the OTN technology ( optical transport network ). The test optical network could transmit up to 80 such containers in one physical fiber, the speed of each was equal to 100 Gbit / s.


The controller allowed the network to support the following functions:

• automatic laying of the service in the network at the request of the client;
  
  
• automatic switching to the protective route in case of failure of the device port, or recalculating the path if the device does not support the protective routes;
  
  
• monitoring errors and notifications.

T-sdn

Let us try to understand in more detail what the architects and ideological inspirers put into the concept of T-SDN .

The main idea of T-SDN , as well as in SDN for data centers, is the separation of the data plane ( data plane ) and the control plane ( control plane ), which is realized through the creation of a single control controller that interacts with network devices of a certain domain of the transport network . Above the controller is the application layer ( SDN application layer ), communicating with the controller on a specific interface. Due to the fact that the controller knows everything about the structure of its domain, there are additional opportunities to improve network performance. For some of them, solutions already exist in various protocols, but T-SDN can significantly improve existing approaches.

So what does T-SDN offer?

• Simplification of operations with the transport network.
  
  It is assumed that it will be as easy to request a service from a provider, as it is to place an order in an online store. Once an order is made, the controller automatically reconfigures all devices and allocates the necessary resources. Thus, the client will receive the necessary service in minutes.
  
  
• Optimum bandwidth utilization.
  
  Optimizing the use of bandwidth (or, as they say, optimal channel utilization) is not a new task. However, a full-fledged solution for the dynamic distribution of client channels in the transport network still does not exist, and it is assumed that in the future the transport controller will take over the solution of this problem.
  
  As an example, consider the following case. Client traffic passes between optical devices A and B in two ways. The blue dotted line is the optical fiber, the black lines are the client channel. The graphs show which part of the channel is occupied and which is free - red and green, respectively.
  
  
  Now imagine that you need to place a new client channel - larger in capacity, occupying 50% of the connection bandwidth. To do this, for example, you can spend one of the channels going up the bottom path, and thus release 50% of the connection.
  
  
  This operation must be carried out in such a way that the existing client does not notice that his traffic now follows a different path - even a short-term denial of service or a deterioration in the quality of services ( QoS ) is unacceptable. Such a redistribution of channels is possible, but at the moment it is performed by engineers in manual mode, takes a lot of time and is subject to errors. The controller can potentially automate this process. It should be noted that the use of bandwidth is 100% impossible in reality, the figures are given only to illustrate the problem. In fact, the recycling rate is usually around 80-90%.
  
  
• Bandwidth on demand — an automatic increase in the capacity of a client service, in case the traffic volume exceeds the capacity of the channel purchased by it. This behavior will allow data to be transferred at a faster rate for a short period of time, and will also prevent packet drops in case of peak loads. On-demand capacity will not require a large financial investment from the client - you only need to pay for the amount of time during which the capacity has been increased.
  
  
• The construction of optimal routes in the transport networks.
  
  Centralized network management makes it possible to optimally select a route for laying a service, taking into account various metrics and requirements.
  
  
• High level of reliability and availability of the service ( high availability ).
  
  Automatic control allows you to quickly respond to network failures. The controller supports any methods of protection route reservation for quick service recovery in case of failures.
  
  
• Secure network configuration through high-level applications.
  
  If the device is changed by the network administrator, errors may occur that could lead to serious consequences, including long-term denial of service. There are many cases of significant failures in the global network due to errors of engineers - which only costs route leak (June 12, 2015), affecting a significant part of the Internet. Using high-level visual applications can greatly reduce the likelihood of incorrect configuration - most of the scrupulous work is done automatically.
  
  
• The ability to easily scale the system ( scalability ).
  
  Increasing the number of devices and control applications is performed without additional controller settings.
  
  These and other stated T-SDN capabilities now cause the most diverse reactions, including harsh criticism and mistrust, but only full-fledged research, prototyping and pilot launches of software-configured transport networks can give a real understanding of the situation.
  
  Employees of NetCracker in Moscow, St. Petersburg and Nizhny Novgorod, with the support of engineers from the company NEC , are currently actively working on T-SDN research and developing T-SDN controller functionality.
  

NetCracker T-SDN Controller

In developing the controller, we focus on supporting the following requirements:

• full management of a highly distributed transport network of a major provider;
  
  
• laying a route throughout the provider’s network;
  
  
• route optimization taking into account requirements and various metrics;
  
  
• support for multi-vendor network (network built on devices from different manufacturers);
  
  
• bandwidth on demand;
  
  
• high level of reliability and availability of service;
  
  
• the ability to easily scale the system;
  
  
• optimal bandwidth utilization.

The company NetCracker is developing a controller that could single-handedly control the network provider of any level. The performance requirements for managing such a network are very high, so the controller has a hierarchical structure consisting of two types of controllers — the T-SDN domain controller (lower level controller) and the T-SDN controller itself (upper level controller). The domain controller manages only a part of the network, that is, a certain domain, and assumes the functions of managing the transport network devices directly. The top-level controller controls not the network devices, but the domain controllers, thus abstracting from communication with the network infrastructure, which improves the system performance. Network management tasks are decomposed and delegated to lower level controllers. The top-level controller accepts data on the operation of the domain, processes it and takes further action.

The diagram below shows the networks managed by the T-SDN domain controller (single domain control) and the top-level T-SDN controller (all domain control).


Simply put, a top-level controller “sees” a whole group of devices as one device. This concept, on the one hand, allows to avoid significant overheads and improve performance, on the other hand, it makes it possible to view the entire network, along with cross-domain connections that cannot be controlled at the domain level, since they are not in view of the domain controller T-SDN . This approach allows you to run customer service throughout the network: from the point of entry into the provider's network, to the point of exit from it, and, as a result, to effectively manage the disposal, optimization of the route, reliability and availability of the service.

NetCracker T-SDN Controller Architecture

NetCracker has developed a T-SDN controller architecture with NEC . The architecture is a hierarchical structure. At the lower level, there is a network infrastructure, the devices of which, according to some API, communicate with the domain, including proprietary SDN controllers. Next comes the level of domain controllers, which, in turn, is connected to a single top-level T-SDN controller. At the top level are applications that provide monitoring and configuration functions.


The controller architecture developed by NetCracker fits entirely into the SDN controller reference architecture proposed by the Open Networking Foundation in 2014 ( ONF Architecture ). This confirms the full compliance of our T-SDN controller with global standards. The viability of such an architecture has already been repeatedly tested in the network laboratory of NetCracker on the equipment of various manufacturers.

The controller has the following main modules:

Route routing includes routing operations at the logical level, and also interacts directly with the Mediator, from which it receives the processed information from connected domain controllers;

path computation is responsible for determining the route on a network graph, taking into account various criteria;

management utilization ( utilization management ) is responsible for optimizing the use of bandwidth;

service topology ( service topology ) stores the current and planned services and their parameters;

mediator ( mediation ) is responsible for working with the underlying devices API and provides support for a fairly rich set of network management protocols, such as RESTCONF , NETCONF , SNMP , SSH , OpenFlow and also HTTP / HTTPS ;

controller management conforms to the ISO standard FCAPS model and includes configuration, fault and controller performance management.

Path calculation module

One of the most interesting and complex controller modules is the path calculation module ( PCE ), the module responsible for calculating a specific path for the service requested by the client. The implementation of such a module is not an easy task from the point of view of a mathematical algorithm. Connoisseurs of routing protocols based on the OSPF and IS-IS link or 802.11s HWMP channel level routing protocol may say that the problem has been solved for a long time, implemented and tested by time - it’s enough to use standard approaches to find the path on the graph, for example, Dijkstra’s algorithm and its modifications. However, the specifics imposed by the equipment of various vendors, as well as the requirements presented by the system, make the task of finding a way fundamentally new, requiring detailed analysis and unbanal approaches.

Basic requirements for PCE :

1. finding the path subject to its existence;
   
   
2. flexible metrics support;
   
   
3. consideration of sites that are desirable or undesirable;
   
   
4. accounting of obligatory visiting sites;
   
   
5. accounting of prohibited sites;
   
   
6. independence from the manufacturer of the equipment.

Particularly difficult are paragraphs 4 and 6.

Finding the best path on a graph with mandatory visits to specified vertices is an NP- complete task, but calculating the paths separately for each domain optimizes time costs well. To solve the problem, a heuristic algorithm is used in combination with the Dijkstra pathfinding algorithm.

Independence from the manufacturer requires that the correct path be found regardless of the implementation of the internal structure of the device of a particular manufacturer and what restrictions this structure imposes. To solve this problem, a full-featured path finding algorithm is being developed on a multilevel graph, including the physical, physical-logical and abstract levels.

Further development

The successful launch of the pilot version allows T-SDN controller developers to contribute to the development of Open Source projects, such as ONOS and ODENOS , to participate in the standardization of SDN technology in the Open Networking Foundation and in other organizations.

The development of the project is carried out in close cooperation with the company NEC - a manufacturer of modern network equipment. Thus, the controller's functionality is tested in the NetCracker network laboratory on the latest NEC devices, and the development departments of NetCracker and NEC have the opportunity to work closely together and directly discuss technical issues. This interaction allows you to better understand the capabilities of vendors and work more effectively with network devices.

The functional needs of large providers are constantly growing - companies interested in the T-SDN controller are tirelessly supplying NetCracker developers with new, more complex and interesting tasks. Absolutely all components will receive (and are already receiving) significant development - from low-level Mediator network interfaces to visualizing and control applications. The NetCracker T-SDN controller team, which has many years of experience working with leading providers in the context of OSS and BSS solutions, confidently marked the beginning of the development of this challenging but extremely interesting field.