Sam Fuller, head of digital networking system solutions at Freescale, says: "The key driver behind SDN is the virtualisation of processing and the need to be able to quickly reconfigure network traffic. We are moving from a stage where networks connected computers to each other to where networks connect people to services."
Speaking at Interop Tokyo in the summer, Open Networking Forum executive president Dan Pitt said: "There is clear business value in SDN: either you save money or you make money. Operators save in capital expenditure and operating expenditure. And they enjoy the agility to create new revenue producing services."
Pitt says SDN can help deal with the bandwidth problems now facing operators as broadband users make the most of their bandwidth allocations to download videos and other large chunks of content. "They can provide enhanced quality of experience using SDN by caching information and video as close to the consumer as possible. That in turn enhances their ability to charge for entertainment services."
The reason why SDN will be better at functions such as caching video is down to the separation of responsibilities between basic packet forwarding – which can be handled at high speed, probably by hardware units – and the control elements that decide the destinations based on what those packets contain.
Fuller says: "The forwarding decisions can be really sophisticated. The forwarding may be based on the MAC layer, IP address, virtual LAN tag or a TCP port. Or it could be much deeper in the packet itself. It might look at a word being searched for and route it based on that. All the ways I might handle that packet fall into these fabric of SDN."
In the example of video caching, packet inspection might reveal the user is looking for data sitting in a nearby cache, removing the need to ferry those bytes across the wider internet. Software control at that level could also use that sensitivity to packet contents to trap DDOS attacks soon after they start – and before they get close to their targets.
DDOS protection and caching today are handled by what have become known as 'middleboxes' – specialised hardware units designed to do a job and generally little else.
With an SDN structure, those jobs can be programmed by software on more generic hardware. On top of that, control processing can be distributed to other servers to enable more intelligent forwarding decisions.
The tough part of SDN is achieving the necessary performance in software. "All the devices we sell now have 10Gbit/s interfaces," says Fuller. "It means you have 300 clock cycles to decide what to do with a packet before the next one arrives, based on minimum packet sizes. We got pretty good at that at the MAC and IP level. But when we need to dig deeper into the packet, it becomes much harder to hit the throughput requirements that equipment providers are looking for."
There is a further restriction: a new generation of network equipment suppliers and network operators does not want to deal with the highly specialised multiprocessors that companies such as Cisco have deployed in their high-end products. Fuller says: "We don't see a lot of opportunity for those architectures moving forward because the industry wants to program in standard languages and in a Linux environment."
Bryant claims a system to use cloud computing for applications such as voice over LTE developed by Nokia Networks, is 'all Intel, all Xeon'.
Part of the answer to SDN's need for speed with software processing is to move the operating system out of the way.
Although most SDN systems run Linux, the libraries and APIs developed for the industry perform tricks to allow data to be placed directly into user memory from the line interfaces, avoiding the overhead of OS calls. But that is unlikely to be cost effective on its own, says Fuller. "There are large gains to be had by inserting the proper acceleration. Chips can achieve five to tenfold throughput increase if the software can take advantage of acceleration opportunities."
To allow flexibility with hardware acceleration, the focus is on providing building blocks for functions such as search and encryption and then to orchestrate them through software interfaces. Software in the upper layers can then call those orchestrated functions to allow a reasonable degree of compatibility between different SDN hardware implementations but still get the speedups of hardware acceleration. APIs developed for SDN, such as OpenDataPlane (see fig 1), allow for coprocessors to work alongside the main Linux capable processors. Those coprocessors could either be software programmable multithreaded network processors or hardware engines.
Scott Shenker, chief scientist of the International Computer Science Institute, believes the move to SDN will see a split in network functions in which a comparatively dumb core section will perform very fast switching on backbones. Control over packet flow will take place at the edge of the network so that operators will build intelligent rings around the core, potentially even moving some SDN functions into the line cards in data centre servers themselves.
Russ Garcia, executive vice president of corporate marketing at Microsemi, sees the shift happening. "More is moving to the edge. People aren't spending money on the core switches, much more is happening at the edge of the network."
By turning the network design inside out, with intelligence moving to the edges of their domains, operators adopting SDN reckon they will be best placed to survive the next phase of rampant growth in internet traffic, both good and bad.
The internet's growing pains are getting louder, but software could ease that pain
4 mins read
In mid August, there were internet outages because some routers didn't have enough memory to store the global route tables needed to ensure that packets can find their way from one corner of the web to another. The reason? The continual addition of new hosts and networks tipped the tables over their 512k entry limit.
In September, the discovery of a critical flaw in the 'bash' command interpreter used by practically all versions of Unix led to machines being exploited and turned into weapons for distributed denial of service (DDOS) attacks. And hardware vendors have become increasingly keen to add billions of new IoT devices, which will need more networks and more IP addresses.
The answer to these and other problems seems to lie in a more flexible network infrastructure instead of tying functions, such as IP routing or DDOS blocking, to specific boxes. The idea behind software defined networking (SDN), originally developed by Martin Cassado at Stanford University, is to split the workload between machines in a different way, with software deciding what to do with packets and high speed hardware using those decisions to perform the necessary actions in the network's core.
Diane Bryant, general manager of Intel's data centre group, said at the company's developer forum in September that the idea of SDN has come a long way in a short time.
"The pace of development is staggering. It started in October 2011 in Paris at a carrier community event. [There] British Telecom presented lab results showing virtualisation of network functions was was possible. By the end of this year, there will be the first commercial deployments. This is an amazing transformation of an industry; it is moving so very, very fast."
Sam Fuller, head of digital networking system solutions at Freescale, says: "The key driver behind SDN is the virtualisation of processing and the need to be able to quickly reconfigure network traffic. We are moving from a stage where networks connected computers to each other to where networks connect people to services."
Speaking at Interop Tokyo in the summer, Open Networking Forum executive president Dan Pitt said: "There is clear business value in SDN: either you save money or you make money. Operators save in capital expenditure and operating expenditure. And they enjoy the agility to create new revenue producing services."
Pitt says SDN can help deal with the bandwidth problems now facing operators as broadband users make the most of their bandwidth allocations to download videos and other large chunks of content. "They can provide enhanced quality of experience using SDN by caching information and video as close to the consumer as possible. That in turn enhances their ability to charge for entertainment services."
The reason why SDN will be better at functions such as caching video is down to the separation of responsibilities between basic packet forwarding – which can be handled at high speed, probably by hardware units – and the control elements that decide the destinations based on what those packets contain.
Fuller says: "The forwarding decisions can be really sophisticated. The forwarding may be based on the MAC layer, IP address, virtual LAN tag or a TCP port. Or it could be much deeper in the packet itself. It might look at a word being searched for and route it based on that. All the ways I might handle that packet fall into these fabric of SDN."
In the example of video caching, packet inspection might reveal the user is looking for data sitting in a nearby cache, removing the need to ferry those bytes across the wider internet. Software control at that level could also use that sensitivity to packet contents to trap DDOS attacks soon after they start – and before they get close to their targets.
DDOS protection and caching today are handled by what have become known as 'middleboxes' – specialised hardware units designed to do a job and generally little else.
With an SDN structure, those jobs can be programmed by software on more generic hardware. On top of that, control processing can be distributed to other servers to enable more intelligent forwarding decisions.
The tough part of SDN is achieving the necessary performance in software. "All the devices we sell now have 10Gbit/s interfaces," says Fuller. "It means you have 300 clock cycles to decide what to do with a packet before the next one arrives, based on minimum packet sizes. We got pretty good at that at the MAC and IP level. But when we need to dig deeper into the packet, it becomes much harder to hit the throughput requirements that equipment providers are looking for."
There is a further restriction: a new generation of network equipment suppliers and network operators does not want to deal with the highly specialised multiprocessors that companies such as Cisco have deployed in their high-end products. Fuller says: "We don't see a lot of opportunity for those architectures moving forward because the industry wants to program in standard languages and in a Linux environment."
Bryant claims a system to use cloud computing for applications such as voice over LTE developed by Nokia Networks, is 'all Intel, all Xeon'.
Part of the answer to SDN's need for speed with software processing is to move the operating system out of the way.
Although most SDN systems run Linux, the libraries and APIs developed for the industry perform tricks to allow data to be placed directly into user memory from the line interfaces, avoiding the overhead of OS calls. But that is unlikely to be cost effective on its own, says Fuller. "There are large gains to be had by inserting the proper acceleration. Chips can achieve five to tenfold throughput increase if the software can take advantage of acceleration opportunities."
To allow flexibility with hardware acceleration, the focus is on providing building blocks for functions such as search and encryption and then to orchestrate them through software interfaces. Software in the upper layers can then call those orchestrated functions to allow a reasonable degree of compatibility between different SDN hardware implementations but still get the speedups of hardware acceleration. APIs developed for SDN, such as OpenDataPlane (see fig 1), allow for coprocessors to work alongside the main Linux capable processors. Those coprocessors could either be software programmable multithreaded network processors or hardware engines.
Scott Shenker, chief scientist of the International Computer Science Institute, believes the move to SDN will see a split in network functions in which a comparatively dumb core section will perform very fast switching on backbones. Control over packet flow will take place at the edge of the network so that operators will build intelligent rings around the core, potentially even moving some SDN functions into the line cards in data centre servers themselves.
Russ Garcia, executive vice president of corporate marketing at Microsemi, sees the shift happening. "More is moving to the edge. People aren't spending money on the core switches, much more is happening at the edge of the network."
By turning the network design inside out, with intelligence moving to the edges of their domains, operators adopting SDN reckon they will be best placed to survive the next phase of rampant growth in internet traffic, both good and bad.
Sam Fuller, head of digital networking system solutions at Freescale, says: "The key driver behind SDN is the virtualisation of processing and the need to be able to quickly reconfigure network traffic. We are moving from a stage where networks connected computers to each other to where networks connect people to services."
Speaking at Interop Tokyo in the summer, Open Networking Forum executive president Dan Pitt said: "There is clear business value in SDN: either you save money or you make money. Operators save in capital expenditure and operating expenditure. And they enjoy the agility to create new revenue producing services."
Pitt says SDN can help deal with the bandwidth problems now facing operators as broadband users make the most of their bandwidth allocations to download videos and other large chunks of content. "They can provide enhanced quality of experience using SDN by caching information and video as close to the consumer as possible. That in turn enhances their ability to charge for entertainment services."
The reason why SDN will be better at functions such as caching video is down to the separation of responsibilities between basic packet forwarding – which can be handled at high speed, probably by hardware units – and the control elements that decide the destinations based on what those packets contain.
Fuller says: "The forwarding decisions can be really sophisticated. The forwarding may be based on the MAC layer, IP address, virtual LAN tag or a TCP port. Or it could be much deeper in the packet itself. It might look at a word being searched for and route it based on that. All the ways I might handle that packet fall into these fabric of SDN."
In the example of video caching, packet inspection might reveal the user is looking for data sitting in a nearby cache, removing the need to ferry those bytes across the wider internet. Software control at that level could also use that sensitivity to packet contents to trap DDOS attacks soon after they start – and before they get close to their targets.
DDOS protection and caching today are handled by what have become known as 'middleboxes' – specialised hardware units designed to do a job and generally little else.
With an SDN structure, those jobs can be programmed by software on more generic hardware. On top of that, control processing can be distributed to other servers to enable more intelligent forwarding decisions.
The tough part of SDN is achieving the necessary performance in software. "All the devices we sell now have 10Gbit/s interfaces," says Fuller. "It means you have 300 clock cycles to decide what to do with a packet before the next one arrives, based on minimum packet sizes. We got pretty good at that at the MAC and IP level. But when we need to dig deeper into the packet, it becomes much harder to hit the throughput requirements that equipment providers are looking for."
There is a further restriction: a new generation of network equipment suppliers and network operators does not want to deal with the highly specialised multiprocessors that companies such as Cisco have deployed in their high-end products. Fuller says: "We don't see a lot of opportunity for those architectures moving forward because the industry wants to program in standard languages and in a Linux environment."
Bryant claims a system to use cloud computing for applications such as voice over LTE developed by Nokia Networks, is 'all Intel, all Xeon'.
Part of the answer to SDN's need for speed with software processing is to move the operating system out of the way.
Although most SDN systems run Linux, the libraries and APIs developed for the industry perform tricks to allow data to be placed directly into user memory from the line interfaces, avoiding the overhead of OS calls. But that is unlikely to be cost effective on its own, says Fuller. "There are large gains to be had by inserting the proper acceleration. Chips can achieve five to tenfold throughput increase if the software can take advantage of acceleration opportunities."
To allow flexibility with hardware acceleration, the focus is on providing building blocks for functions such as search and encryption and then to orchestrate them through software interfaces. Software in the upper layers can then call those orchestrated functions to allow a reasonable degree of compatibility between different SDN hardware implementations but still get the speedups of hardware acceleration. APIs developed for SDN, such as OpenDataPlane (see fig 1), allow for coprocessors to work alongside the main Linux capable processors. Those coprocessors could either be software programmable multithreaded network processors or hardware engines.
Scott Shenker, chief scientist of the International Computer Science Institute, believes the move to SDN will see a split in network functions in which a comparatively dumb core section will perform very fast switching on backbones. Control over packet flow will take place at the edge of the network so that operators will build intelligent rings around the core, potentially even moving some SDN functions into the line cards in data centre servers themselves.
Russ Garcia, executive vice president of corporate marketing at Microsemi, sees the shift happening. "More is moving to the edge. People aren't spending money on the core switches, much more is happening at the edge of the network."
By turning the network design inside out, with intelligence moving to the edges of their domains, operators adopting SDN reckon they will be best placed to survive the next phase of rampant growth in internet traffic, both good and bad.
