No Comments

The SDN Controller — Under Control or Out of Control?

 By: Mark Leary Posted: Jan. 30, 2013

This post is also available in: Japanese

The SDN Controller -- Under Control or Out of Control?

Spiderman’s uncle was right… “With great power comes great responsibility.”

In software-defined networking, the SDN controller has great power. It has ultimate responsibility for the health and well-being and even actions of the SDN environment. It directs downstream networking devices. It translates and reacts to on-demand requests and changing networking and computing conditions. It tracks and protects networking — and networked — resources. It acts as a singular conduit for programmatic control over the network. It serves as a foundation for an open network environment. The list of vital SDN controller functions is lengthy… and very powerful indeed.

So how does one judge if a particular supplier is stepping up to the great responsibility that comes with developing, deploying, supporting, and advancing their chosen high-powered SDN controller? I offer the following Top Ten list of supplier best practices (in no particular order) that point to future SDN controller success — whether the supplier develops their own SDN controller or leverages SDN controller technology from another source (e.g., public domain, second supplier, etc.):

10.  Device interoperability – Standardized technologies such as OpenFlow form a solid baseline for open networking and multivendor SDN. Offering an SDN controller to customers without offering formal proof of interoperability with, at least, the more popular networking devices is simply unacceptable. Such programs not only expand a supplier’s solution set, they also build experience with real-world SDN challenges.

 9.  Application development – While the SDN controller itself offers its own level of network programmability, the SDN controller will also be directed to program the network in reaction to needs and directives from SDN applications – system and business applications — operating on top of the network. Here, application development kits that include such key resources as open northbound/southbound APIs, application templates, optimization guidelines, and QA tools serve as proof that a controller supplier is very serious in building out its application ecosystem.

 8.  Application certification – The successful SDN controller will attract the better SDN applications. There must be a process in place to certify these applications. Network operators will need to know that not only is the application of value, but that it will also work with their chosen controller. This will also serve in support of multi-vendor solution packages that include controllers plus high-impact applications.

 7.  Legacy integration – While representing a significant step forward in networking, SDN also lends itself well to gradual deployment. Here, proof of SDN functionality working within a traditional operating network offers proof that incremental SDN buildout is not only possible, but a sensible and risk-free approach to SDN adoption.

 6.  Solution ecosystem – In looking at an SDN deployment, the controller is one piece of the puzzle. The supplier willing to assemble a proven complete SDN solution (the whole puzzle) for the operator has the advantage both in the near-term (deployment) and into the future (ongoing operations).

 5.  Capacity planning – The SDN controller is SDN’s central processor. Understanding (for operators) and measuring (for suppliers) the capacity of an SDN controller under different loads (e.g., traffic volume, active rules, directed devices, controlled flows, etc.) will be critical in evaluating SDN solutions – and, subsequently, deploying the right-sized solutions.

4.  Proactive support – While we would all love to see the network evolve into a “Set it and forget it” utility, the reality is that deploying and operating an SDN environment will challenge every operator. SDN-specific support services and systems engineering expertise ensure that the SDN controller and directed larger SDN solution are deployed correctly and, once activated, continue to operate properly as they adapt to new network, device, policy, and application demands.

 3.  Fail-safe systems – While in its most simple form, the SDN controller can be a singular software package operating on a traditional server/appliance hardware platform, its crucial role in the network demands fail-safe operations. Think multiple controllers. Think “hot” service activations and updates. Think pre-activation confirmations and configuration rollbacks. And less we think this is all about software protection, let’s not forget all the fail-safe hardware features – e.g., redundancy, failover, hot swaps, etc.)

 2.  Hardware optimization – While controller-driven hardware optimization efforts run counter to the open systems ideals of the SDN movement, I would say that performance and availability trumps software portability. While I do not advocate bowing to the fastest  “shut tight” system, I do argue that network operators should not settle for the least common denominator when deploying SDN. The SDN controller that strikes the right balance between standardization and optimization wins.

 1.  Usability and manageability – Beauty is in the eyes of the beholder when it comes to network administration. Here, the most standardized and open SDN controller will benefit from management interfaces and tools that can be customized to suit the operator. An open system that is difficult to deploy, operate, maintain, and update will fail to deliver on all the promise of SDN.

 If you’re a network operator, think of the crucial role the SDN controller plays in your network the next time you’re thinking that a simple public domain download or neat server software package will satisfy all your network needs. If you’re an SDN solution supplier, think of the many ways the SDN controller influences the success (or failure) of your own SDN offering – an offering that may or may not include underlying devices or over-arching applications or both. Spiderman’s uncle may not have known a thing about networking, but he certainly offered some great guidance to SDN operators and suppliers.

Guest Blogger Disclaimer:

The views, opinions and positions expressed within these guest posts are those of the author alone and do not represent those of SDNCentral.com and SDNCentral, LLC. The accuracy, completeness and validity of any statements made within this article are not guaranteed. We accept no liability for any errors, omissions or representations. The copyright of this content belongs to the author and any liability with regards to infringement of intellectual property rights remains with them.

Checkout more from our Guest Bloggers:

Like our Content? Join the SDNCentral Mailing List

  • This field is for validation purposes and should be left unchanged.

 

About the Author

.

Mark Leary

In 2012, 30-year IT industry veteran Mark Leary founded The First Tracks as a research, analysis, and… More

Connect with the AuthorWebsite

Login


MODAL