• TechnologyInnovator
• NextInnovator
• EnterpriseInnovator
• SecurityInnovator
• DefenseInnovator
• WirelessInnovator 
• HPinnovator
• EnergyInnovator
• TransportationInnovator
• SMBinnovator (beta)

• NextInnovator(at)Live.com

• Newsroom Home
• Newsroom Archives
• Fast Facts
• Financial  Information
• Global  Citizenship
• HP Labs
• Company History
• HP in the News   
• Videos
• B-roll
• Blogs
• RSS Feeds 

• Connect
• Connect - Deutschland
• 3000 Newswire Blogs

• Ghost City
• Frontline Sentinel
• Innovation Insights
• WebInno
• Over the River
• Enderle Group
• Security Insights Blog 
• McAfee Audio Parasitics
• Rethinking Security
• Ovum
• iSuppli
• Canalys
• eMarketer 
• CRM Help Desk SW 
• Rethink Research
• The Gadgeteer
• Master the Moment

The concept that the network can become a complete software-defined network (SDN) has been about for many years, and in fact, Juniper Networks spoke about it in 2009 when it announced the “new network”. The benefits of an SDN are expressed as reduced operating expenditure through increased use of automation, and a subsequent improvement in the speed to deploy. However, the challenges of using an SDN are not fully understood, and these will only become clearer as organizations begin to understand more about how an SDN will operate. The truth is that SDN or programmable networks are still some way from becoming a reality. However, Juniper with its Juniper Networks QFabric System has developed its original concept of separating data and control paths to produce an approach that represents a step in the right direction toward SDN.

Centralize what you can, distribute what you must

Juniper pioneered the separation of the data path from the control path in its networking products 16 years ago, which although not entirely analogous to how an SDN is defined today, did at least represent new thinking about network solutions. To fully understand the current applicability of SDN, the network must be categorized into sub-elements or domains. There is no standard definition of these roles, but those used by Juniper represent a valid way to segment the network. The seven domains used by Juniper are: Access & Aggregation, Edge, Core, Data Center (DC), Campus & Branch, WAN, and Consumer & Business devices. Ovum advocates that the technology is currently only relevant for the DC and Campus & Branch domains in terms of supporting SDN concepts. While many would argue that edge devices are the biggest areas that need to be addressed and are more relevant to the concepts of programmable networks, they are also the domains where technology is less stable, hence its applicability to adopt new concepts that are more likely to generate problems.

The concept of an SDN recognizes that not every problem can be solved by the distribution of systems. In addition, the controller currently provides more than one specific role or purpose, for example, storage, compute, and network controller capabilities, and to further complicate matters these operate both upward-stream and downward-stream in terms of communication channels. The first question to ask therefore is what functionality should be in the network and what should be in the controller. For example, provisioning in a distributed way does not have all the information in one place so would make sub-optimal decisions, and likewise, monitoring and identifying the average utilization of a network would be very difficult to perform as a distributed function only. But with the advent of packet switching, a lot of functionality was put in network nodes, such as topology or forwarding, and the centralized functions were management.

The SDN purist view is to go back to the old telephone world where control was centralized. Ovum believes this view is flawed precisely because of the issues raised above: topology discovery and the ability to forward packets needs to be done in the nodes. It is therefore likely that the future is an even split of what is centralized and distributed, but this will be dependent on domain.

OpenFlow is a game-changer

One of the core principles of SDN is to use automation as much as possible and also to use an open standard to communicate between the controller and the network. Currently OpenFlow is an emerging open-source answer to the communication challenge, but it is still focused on developing the standard and as such is considered at best a version 1.0 release, with many commentators believing it needs to mature to a version 2.5 level before it will begin to have any influence on the SDN movement. Ovum believes that to fully enable an open standard, more work is needed on defining which functionality is the role of the controller, and which is embedded in the network, but we do believe that OpenFlow represents a potential game-changer in the wider adoption of SDNs.