SDN - A Promising Approach for Next Generation Networks

Recently, Software Defined Networking (SDN) has become a very popular term in the area of communication networks. The key idea of SDN is to introduce a separation of the control plane and the data plane of a communication network. The control plane is removed from the normal network elements into typically centralized control components. The normal elements can be replaced by simpler and therefore cheaper off-the-shelf devices that are only taking care of the data plane, i.e. forwarding traffic according to rules introduced by the control unit.

SDN is expected to bring several benefits, such as reduced investment costs due to cheaper network elements, and a better programmability due to a centralized control unit and standardized vendor-independent interfaces. In particular, SDN is also one of the key enablers to realize network virtualization approaches which enable companies to provide application aware networks and simplify cloud network setups.

There are various SDN use cases and application areas that mostly tend to benefit from the increased flexibility and dynamicity offered by SDN. The application areas reach from resource management in the access area with different access technologies, over datacenters where flexible and dynamic cloud and network orchestration are more and more integrated, to the business area where distributed services can be realized more flexibly over dedicated lines realized by SDN. Each SDN use case is, however, as individual as the particular company. A unified OSS solution supporting SDN, as offered with Infosim® StableNet®, should therefore be an integral part of any setup.

SDN Challenges – 6 things to think about before you go SDN

The benefits of SDN seem evident. It is a very promising approach to increase flexibility and reduce cost. The idea of a common standard further seems to ease the configuration and handling of an SDN network. However, our experience shows that with the decision to “go SDN” a lot of new challenges arise. Six major ones of these challenges – by far no complete list – are addressed in the following.

Bootstrapping, Configuration and Change Management

SDN aims at a centralization of the network control plane. Given that an SDN network is readily setup, a central controller can adequately manage the different devices and the traffic on the data plane. That is, however, exactly one of the challenges to solve. How to get the SDN network to be setup before any SDN protocols can actually be used? How to assign the different SDN devices to their controllers? How to configure backup controllers in case of outages, etc.? The common SDN protocols are not adequate for these tasks but focus on the traffic control of a ready setup network. Thus, to be ready to “go SDN” additional solutions are required.

Smooth migration from legacy to SDN

The previously mentioned phenomenon of a need for configuration and change management is furthermore exacerbated by the coexistence of SDN and non-SDN devices. From our experience in the Telco industry, it is not possible to start from scratch and move your network to an SDN solution. The challenge is rather to smoothly migrate an existing environment while continuously assuring the management of the entire system consisting of SDN and non-SDN elements. Thus, legacy support is an integral part of SDN support.

Configuration transparency and visualization

By separating control plane and data plane, SDN splits the configuration into two different levels. When sending commands to the SDN network, normally you never address any device directly but this “south bound” communication is totally taken care of by the controllers. All control steps are conducted using the “north bound” API(s). This approach on the one side simplifies the configuration process, on the other side leads to a loss of transparency. SDN itself does not offer any neutral/ objective view on the network if the configuration sent via the north bound API actually was sent to the south bound API in the proper and desired way. However, such a visualization, e.g., as overlay networks or on a per flow base, is an important requirement to assure the correctness and transparency of any setup.

SLA monitoring and compliance

The requirements to SDN mentioned earlier even go one step further. Assuring the correctness and transparency of the setup as mentioned before only guarantees that path layouts, flow rules, etc. are setup in a way as desired during the configuration process. To assure the effectivity of resource management and traffic engineering actions and thus the satisfaction of the customers using the infrastructure, however, more than just the correctness of the setup is needed. SLAs have to be met to assure that the users really get what they expect and what they pay for. The term SDN often goes along with the notion of application-aware networks. However, SDN itself cannot provide any guarantee that this application-awareness really brings the expected benefits. Thus, a possibility for an objective monitoring of the network, its flows, services and their corresponding KPIs is necessary.

Handling of competing standards and proprietary solutions

One main expectation to SDN is that a common standard will remove the necessity to control any proprietary devices. However, recent developments show that first, the different standardization efforts cannot really agree on a single controller and thus a single north bound API. Furthermore, many popular hardware vendors even offer their proprietary flavor of SDN. To cope with these different solutions, an adequate mediation layer is needed.

Localization of failures without any “distributed intelligence”

In a traditional network with decentralized control plane, the localization of failed components can be done as a part of the normal distributed protocols. Since devices are in continuous contact anyway, failure information is spread in the network and the actual location of an outage can thus be identified. In an SDN environment, what has been a matter of course suddenly cannot be relied on anymore. By design, devices normally only talk to the controller and only send requests if new instructions are needed. Devices never talk to any other devices and might not even have such capabilities. Therefore, on the one hand a device will in general not recognize if any adjacent link is down, and on the other hand in particular, will not spread such information in the network. Therefore, new possibilities have to be found to recognize and locate failures.

To learn more, download the white paper