Light Reading Mobile – Telecom News, Analysis, Events, and Research

Heavy Lifting Analyst Notes  

SDN: Start Making Sense

August 13, 2012 | Jim Hodges- Senior Analyst |

Very few – if any – days have gone by over the past few months in which the relative merits of software-defined networking (SDN) have not been publicly debated.

As we note in the latest Heavy Reading report, "SDN & the Future of the Telecom Ecosystem," the debate is likely to increase in the near future given the potential impact for both carriers and vendors.

Conceptually, SDN and the approach of separating the control plane from the data plane present a strong value proposition. And while this approach has long been adopted in other parts of the network (session border controllers and IMS core), it does hold the promise to revolutionize and break new ground on the way data transport networks function.

Here's a quick take on the factors and unanswered questions that ultimately will determine if SDN becomes a truly transformative force in telecom, or if it ends up being something that achieves reasonable facsimile status in that it effected change, but ultimately not within scope of the original vision.

On the transformative potential side, there are these two points:

Point 1: SDN-based initiatives such as OpenFlow are being driven by the carrier in response to real-world requirements. This is an important factor given that it highlights a view that the status quo approach of "pseudo" open tools and software applications is too costly, too inflexible and ultimately no longer sustainable.

Point 2: SDN brings some much-needed simplicity to an overly complex world. Given the impact of moving applications to the cloud and the requirement to introduce policy control for application access and security, networks are going to increase in complexity on many levels, and any approach that has the potential to minimize or reduce that complexity is highly desirable. Support of a distributed control plane model is no longer a viable approach.

On the less-than-meets-the-eye side, we have:

Point 1: It's difficult to implement a concept. Despite all the recent activity in the various industry forums, SDN is still largely in the first phase of industry adoption. As a result, it's really difficult to assess where it will be in even the next few years once the real product development work starts to take place. Further complicating the process is that even though OpenFlow, an SDN protocol implementation, clearly has some early market momentum, other approaches exist and more could emerge. For example, in our report we analyze how the IETF's Path Computation Element (PCE) specification may be a more practical approach to take for carrier SDN optical deployments. The question then becomes whether SDN can achieve meaningful cost savings and programmability openness if a number of protocols/specifications that follow a similar methodology are adopted on a global basis.

Point 2: We still don't know what vendors really think about SDN. This is a difficult question and ultimately depends on vendor competitive standing and market momentum. Therefore, vendors will have to tread very carefully as they define their SDN strategies to protect market share while also appearing as aligned to the spirit of SDN and not simply integrating SDN associated buzzwords like programmability into marketing campaigns. This dilemma is further complicated by uncertainty of how licensing of control plane clients associated with approaches such as OpenFlow will be priced.

A lot remains to be sorted out regarding SDN, including potential for success as a game-changer for telecom networks. Over the next 12 months, a number of critical developments both at a vendor and forum level will provide a much better picture of SDN's ultimate impact on the telecom industry.

— Jim Hodges, Senior Analyst, Heavy Reading


For more information about Heavy Reading's SDN & the Future of the Telecom Ecosystem, please contact:




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Network Computing encourages readers to engage in spirited, healthy debate, including taking us to task. However, Network Computing moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. Network Computing further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 
White Papers SPONSORED CONTENT
Featured