Trends for network control and management

Even though Software Defined Networking (SDN) has been around for a decade at least, it has gained significant momentum the last few years. See for instance [1] for comprehensive summary of the technology. The momentum stems very much from success stories told by large global players like Google, Facebook and Amazon about implementations of SDN infrastructure in and between their data centres. Recently ,some large network operator have also join in “selling” SDN to the rest of the crowd, e.g. AT&T has announced their grand project [2] adding SDN infrastructure to most of their network (and even to some extent replace the current one).

So, does this mean SDN is the path to go for most ISP, e.g. an operator like UNINETT?

This post summarizes some potential gains and also some concerns with respect to introducing SDN in a IP backbone like UNINETT.

  • Reduced equipment cost: One major argument for moving towards an SDN based infrastructure is the potential savings with respect to equipment costs. Core to  SDN is open standardized interfaces between forwarding hardware, control systems and orchestrating management systems. In principle (an in line with an old vision within the network management domain) an operator should be able to pick SDN equipment, controller software and management software from different vendors and connect everything together in harmony. We are not just there yet.  A bottom up approach is  commencing it seems. The Open Flow protocol [3] for interfacing “dumb” switching/forwarding equipment is now well supported. Dominating vendors like Cisco, Juniper and HP have added support in their products, but the  smaller innovative vendors are more interesting with respect to equipment cost. It seems the new openness between forwarding plans and control plane may give operators more freedom when shopping for hardware upgrades. They  may go for a new vendor without having to replace/re-educate their control and management systems/engineers.
  • Shared and “free” open source control systems:  Low cost “dumb” switches require a controller infrastructure to do anything at all. As a result of the openness and standardization of the control protocols, communities have formed to join forces in developing controller software as open source projects, e.g. like the Open Daylight project [4] . Such software is traditionally bundled with the switching hw and hence available only at rather high cost. Open source SDN controllers are maturing, and are already reported applied in production setting. But as for all open source software, even though the code is free, there is a cost in tailoring the software, ensuring availability and debugging when those bugs surface.  An ISP like UNINETT could probably manage the cost and effort of handling one such controller, or a pair to ensure availability. But the number of controllers required may turn out to be more than just a few since…
  • … you need orchestration: The large players report how they need to compose clusters of controllers to handle the load of control traffic between the controllers and the switching hardware. Redundancy is required to ensure availability. But what coordinates all these controllers? Google admits a lot of effort is spent on developing the required super-controller (called “Andromeda” [5]) which over-sees and orchestrates the team of controllers which again connect to the switching hardware. Smaller ISPs like UNINETT will not likely have the resources required to develop and/or tailor an orchestrating super-controller with sufficient quality today. There are some recent open source initiatives founded in research projects aiming to develop such super-controllers. Hence small ISPs may soon get a framework for free, however tailoring will be crucial as the super-controller will have the power to reconfigure and/or bring down the whole ISP infrastructure.
  • Change of management “culture”: SDN enables logically centralized control of the network which again opens for more optimized overall routing and traffic engineering. As much of  Internet’s success stems from its distributed nature, it will take many good arguments to convince senior network engineers that a path towards centralized control (even though only logically) is one to follow.  Cultures change slowly, likely also network management cultures.
  • New network aware application: With respect to what an average customer will gain from an SDN enable network infrastructure, there is at least one area which is interesting, network aware applications. An SDN controller infrastructure may provide a “slice” of the network to an application, and  hence enable it to manage a set of network resources as best suited for the application, including routing and shaping the traffic. More “aggressive” applications with respect to network usage may emerge since the friendly behaviour (e.g. TCP friendliness, thin flow protection) required when transport resources are shared in a best effort manner will no longer be significant.

To summaries, an average commercial national ISP will likely still wait for a while before replacing traditional routing equipment with SDN based systems. An ISP like UNINETT however, being a research network operator, should probably continue building up a parallel experimental backbone infrastructure based on SDN, and at some point run performance tests on live traffic. SDN can be key to keep costs down, but also open up opportunities for innovative ICT systems designs. Giving those PhD and Msc students their own slice of the network to play around may fuel development of new and surprising systems and applications.

References

  1. Kreutz, D.; Ramos, F.M.V.; Esteves Verissimo, P.; Esteve Rothenberg, C.; Azodolmolky, S.; Uhlig, S., “Software-Defined Networking: A Comprehensive Survey,” Proceedings of the IEEE , vol.103, no.1, pp.14,76, Jan. 2015
  2. ONS2014 Keynote: John Donovan, Senior EVP, AT&T Technology & Network Operations
  3. Open Networking Foundation: Open Flow
  4. OpenDaylight, A Linux Foundation Collaborative Project
  5. Andromeda, Google’s orchestrator service

Leave a Reply

Your email address will not be published. Required fields are marked *