Why Telecos Care About SDN and NFV, and Some Issue
Post# of 17650
Posted On: 05/08/2015 9:13:39 AM
Why Telecos Care About SDN and NFV, and Some Issues
Service providers have been driving the transition of telecom networks to cloud technology in the form of network functions virtualization (NFV) and software-defined networking (SDN). Why do they want to do this, and what are the issues?
The simple answer to “why” is the astounding growth in cost-effective computing in the cloud, due to the equally astounding advances in silicon. Moore’s Law states that the density of transistors will double every 12-18 months. This astounding statement is called a law, but it is actually a prediction made by Gordon Moore in 1965. It has become somewhat of a self-fulfilling prophecy that has proven true over the last 50 years. The innovation described by Moore’s Law is at the heart of the cloud-computing revolution, because the growth in density has led to a tremendous increase in compute power and a similar decrease in cost. The availability of low-cost compute platforms (servers) with high bandwidth connections has made computing available as a utility and has driven the web-enabled revolution. Companies such as Google, Amazon, Netflix and Apple have ridden this wave to commercial success.
In contrast, the telecom world is still operating on the old model of slow and steady growth based on using old-fashioned and expensive appliances such as routers and firewalls. Telco service providers saw the innovation being driven by the cloud and wanted to find a way to leverage that technology and its benefits. The result is NFV and SDN. NFV is based on replacing the current generation of dedicated appliances with software functions running on commercial off-the-shelf (COTS) servers, and SDN provides a means to use low-cost compute to centralize the control of networks. The goal of service providers is to use NFV and SDN to apply the power of the cloud to the stagnant telecom network.
The world of cloud technology has made tremendous strides in terms of creating an environment where users can harness the power of low-cost computing. With the advent of virtual machines (VMs), cloud providers such as Amazon, Google and Azure give each user access to what was effectively his/her own standalone compute environment. In truth, each user is sharing a server with other users, and can run an application that was independent from the underlying server. The result is what we now call “the cloud.”
Sounds great, right? Can this technology be applied to telecom networks? The answer is “yes, but…”
While the performance of OVS is adequate for the typical compute-intensive application such as web commerce or databases, it is completely inadequate for the bandwidth-intensive applications that are needed for service providers to replace appliances. A router, firewall or voice application has bandwidth requirements that are 2 or 3 orders of magnitude larger than that required by the typical compute application hosted in a cloud.
Another problem with OVS is its simplistic network interfaces. Today’s clouds are built within datacenters composed of adjacent servers. The networking model in datacenters is very simple, and it assumes direct connectivity. In contrast, service provider networks are a complex mix of layer 2 and layer 3 technologies. Carrier Ethernet 2.0 is the default means of building layer 2 networks for service providers, and it provides for a rich set of features. Key features of CE 2.0 provide for prioritization of traffic such as voice and video, service turnup and assurance, and access across to third-party networks using network-to-network interfaces (NNIs). Unfortunately, OVS has no support for CE 2.0 functionality.
Fortunately, many of us in the telecom industry have been working to solve these problems of performance and network interfaces. Today, a group of us announced an NFV service chain with Gigabit performance running on low-cost COTS servers.
Here’s the full test report: http://www.overturenetworks.com/nfv-performance
Service providers have been driving the transition of telecom networks to cloud technology in the form of network functions virtualization (NFV) and software-defined networking (SDN). Why do they want to do this, and what are the issues?
The simple answer to “why” is the astounding growth in cost-effective computing in the cloud, due to the equally astounding advances in silicon. Moore’s Law states that the density of transistors will double every 12-18 months. This astounding statement is called a law, but it is actually a prediction made by Gordon Moore in 1965. It has become somewhat of a self-fulfilling prophecy that has proven true over the last 50 years. The innovation described by Moore’s Law is at the heart of the cloud-computing revolution, because the growth in density has led to a tremendous increase in compute power and a similar decrease in cost. The availability of low-cost compute platforms (servers) with high bandwidth connections has made computing available as a utility and has driven the web-enabled revolution. Companies such as Google, Amazon, Netflix and Apple have ridden this wave to commercial success.
In contrast, the telecom world is still operating on the old model of slow and steady growth based on using old-fashioned and expensive appliances such as routers and firewalls. Telco service providers saw the innovation being driven by the cloud and wanted to find a way to leverage that technology and its benefits. The result is NFV and SDN. NFV is based on replacing the current generation of dedicated appliances with software functions running on commercial off-the-shelf (COTS) servers, and SDN provides a means to use low-cost compute to centralize the control of networks. The goal of service providers is to use NFV and SDN to apply the power of the cloud to the stagnant telecom network.
The world of cloud technology has made tremendous strides in terms of creating an environment where users can harness the power of low-cost computing. With the advent of virtual machines (VMs), cloud providers such as Amazon, Google and Azure give each user access to what was effectively his/her own standalone compute environment. In truth, each user is sharing a server with other users, and can run an application that was independent from the underlying server. The result is what we now call “the cloud.”
Sounds great, right? Can this technology be applied to telecom networks? The answer is “yes, but…”
While the performance of OVS is adequate for the typical compute-intensive application such as web commerce or databases, it is completely inadequate for the bandwidth-intensive applications that are needed for service providers to replace appliances. A router, firewall or voice application has bandwidth requirements that are 2 or 3 orders of magnitude larger than that required by the typical compute application hosted in a cloud.
Another problem with OVS is its simplistic network interfaces. Today’s clouds are built within datacenters composed of adjacent servers. The networking model in datacenters is very simple, and it assumes direct connectivity. In contrast, service provider networks are a complex mix of layer 2 and layer 3 technologies. Carrier Ethernet 2.0 is the default means of building layer 2 networks for service providers, and it provides for a rich set of features. Key features of CE 2.0 provide for prioritization of traffic such as voice and video, service turnup and assurance, and access across to third-party networks using network-to-network interfaces (NNIs). Unfortunately, OVS has no support for CE 2.0 functionality.
Fortunately, many of us in the telecom industry have been working to solve these problems of performance and network interfaces. Today, a group of us announced an NFV service chain with Gigabit performance running on low-cost COTS servers.
Here’s the full test report: http://www.overturenetworks.com/nfv-performance
(0)
(0)Digital Uts Ventures (DUTV) Stock Research Links
"The only way of discovering the limits of the possible is to venture a little way past them into the impossible."
Scroll down for more posts ▼