The journey towards SDN: Six things for the road

Posted on: 6th October 2014

Network virtualisation is here to stay.  Network operators and data centre owners have to address the issue of SDN/NFV.

Understanding the nature of an SDN controller and the differences between products offered by vendors is the best starting point on the SDN journey.  The foundation of any SDN journey though, starts at home – learning and understanding your own network and whether (or how much) it can support SDN.  Network operators are acutely aware that they need to find new ways to manage the assets that make up their network to continue to deliver service against increase demand.

Here are six things to consider both before embarking on the SDN journey, as well as during the design, build and operate phases of the installation.

1) Learn about SDN:  A large number of organisations still do not know what software defined networking is or how it might benefit the business.  SDN can help or hinder your enterprise network.  Read up on the various styles and compositions of SDN – you may even come up with your own definition.

2) Know what you want to do:  SDN was initially developed with the data centre in mind, but now the enterprise WAN is a prime focus for the automation and orchestration benefits of SDN.  Questions you need to ask yourself at this stage include do we want a centralised or distributed control plane?  Some of the more advanced SDN applications have analytics and packet monitoring capability, due to the ability of SDN to quickly direct traffic.  Orchestrating and automating the network through software can save on both capital and operational cost, so determining what the goal or objective is and implementing it accordingly can provide exceptional results.

3) Security:  To make the job of the network operator easier, many organisations centralise control of the SDN, but this also provides a single point of failure or target for a malicious attack.  Considering how a controller would deal with outages and other situations that would require large scale traffic re-routing is a fundamental pre-install step.  If someone gains access to your controller, could that intruder bring your network to its knees?

4) Design – decide the best place to begin:  Although SDN continues to be targeted at networks and data centre, as many of the benefits are obvious, there is a new focus on SDN for WAN.  WANs can also benefit greatly from the automation and simplified management of SDN.  Major IT trends such as SaaS, private cloud and BYOD are stressing the quality of links in an enterprise WAN.  WAN links also now require improved security, lower latency, higher reliability and support for multiple devices in multiple locations.  SDN has the potential to assist enterprise IT in accomplishing this without expensive upgrades.  It is important to be mindful of budget as well as architectural choices when defining the necessary policy rules strategic dimensioning.

5) Start small:  Compartmentalise a small portion of the network to test for SDN compatibility and effectiveness so that if anything goes wrong, the entire network is not affected.  After a test and measurement phase you can gradually extend the SDN pilot scheme.  The functionality roll out should be based on business demands and be planned to satisfy the policies created at the design stage, depending on market forecasts.  In the legacy WAN this could involve CAPEX spend based on budget but in the new world this could ensure the virtual network resources are dimensioned to support the forecasted service mix.

6) Operate – OPEX and monetisation of the virtual network:  When the operate phase is reached, policy is enforced and network performance needs to be monitored.  For example, when a network installs Aria Networks’ iVNT, which models the network topology, existing services and future demand, the routing engine is establishing the optimum routes for traffic, based around the key criteria and policies.  Reconfiguration, repair and re-optimisation are then continual processes to support the real time demands of the service layer.  Some may see capacity management here as an operational requirement and that once a network is software defined and self-monitoring capacity does not need to be managed.  This is wrong – whether automatically or via human intervention, capacity still needs to be managed.  The principles of monitor, analyse and monetise need to be intelligently applied, particularly when you have tight operating budgets and margin controls.