Cloud infrastructures are nothing new. The likes of Google and Amazon have had virtualized, fully elastic infrastructures that run on commodity servers for more than a decade. Commercial technologies for elasticity have been around since VMware introduced DRS in 2004. Why hasn’t the telecom industry incorporated these technologies to produce cloud-based architectures already?
Telecom is slow to incorporate IT
Come to think of it, this delay is not a new phenomenon. Even though the mother of all telcos – AT&T’s Bell Labs – invented the transistor, the first commercial microprocessor (Motorola’s 68000) was not used in a telecom switch until around 1982 in the 5ESS. Intel introduced the first general purpose microprocessor, the Intel 4004, in 1968; that’s a 14-year lag. This technology adoption delay is true of nearly all major IT technologies – starting from digital computers, networking technologies like IP and the web, right to elastic clouds today.
Why has telecom always been so slow to adopt commercial IT technologies? Are telecom engineers just lazy? Are service providers really luddites compared to their IT peers?
Telecom is harder than IT
Actually, telecom is slow to incorporate commercial IT technologies because those technologies are generally not designed for use in real time communications services. The low-latency, bi-directional, continual and high processing nature of real time communications has always made the usage of commercial IT technologies impractical until they reach a mature state with very high performance.
As an example, let’s return to my original rhetorical question on cloud-based architectures. Let’s look at what the vast majority of today’s commercial virtualization technologies were designed for – the web. Most web servers are made to be stateless by design. Most applications involve sending a lot of data to clients and relatively little back. Content can be queued and cached. The OSI model is well abstracted between layers. Most applications use TCP for its retransmission and reassembly properties.
Voice over IP (VoIP) is much messier. Call state is maintained by both the client and server. All content is bidirectional and synchronous. Everything must be as instantaneous as possible. Retransmission is generally futile. Late packets are as good as dead. Conversations are ephemeral. Content delivery optimization takes on an entirely different meaning when the content that was just created becomes worthless in a fraction of a second. To make matters more difficult, the messy realities of NAT traversal for VoIP traffic have blurred the boundaries of the OSI stack.
Although there are alternative approaches that alleviate some of telecom’s traditional constraints, the reality is that there are more than 6.4 billion telephone subscriptions based on TDM and VoIP technologies. Moving these users to a modern, cloud infrastructure would have a significant impact in revolutionizing service providers.
Telecom cloud infrastructure is on the horizon
A newly formed industry specifications group within the ETSI organization recently took on this charter last October. They call this initiative Network Functions Virtualization (NFV). NFV’s objective is to deploy and deliver software-based functions and services by consolidating disparate equipment types on standard, high-volume commercial-off-the-shelf (COTS) hardware and leveraging standard IT virtualization technologies. NFV’s goals apply to the control and data plane, fixed and mobile networks, the edge, and the core.
The group composed a whitepaper that described their objectives. Some of the benefits they highlighted include:
Reducing equipment related costs – significant operational savings can be achieved by through standardization of installation and maintenance processes.
Increasing the speed of innovation – software can be rapidly prototyped, tested, and adjusted without lengthy equipment procurement cycles. This removes the stranded hardware costs associated with failure, making it significantly more practical to experiment with new features.
Resource sharing across services – underutilized hardware can be used to support oversubscribed services and functions, reducing the amount of hardware needed.
Finely tuned service introduction – service introduction is defined by software, not the physical location of equipment assets, so new services and features can be finely targeted, tuned, and then scaled to a larger audience as needed.
Encourages open ecosystem – software has lower market entry barriers than hardware. This will bring in new competitors from the software domain and academia.
NFV is in its infancy, but there are signs that the larger IT ecosystem is giving more attention to telecom. For example, Intel has started to promote its Data-Plane Development Kit (DPDK) for high-speed packet processing on standard x86 platforms. Hypervisor companies are working with NFV proponents to adapt their products for the unique requirements of real time communications. Infrastructure vendors are redesigning their products to accommodate these technologies.
Many network functions, such as management and support systems, are already virtualized, making them easy to incorporate into NFV. However, other functions, particularly media-based functions will be among the hardest to virtualize due to many of the constraints listed in the previous section. These are not necessarily insurmountable obstacles, but applying technologies like DPDK to all network functions will take time. Making them practical at scale may take a little longer, so we do not expect to see an instantaneous transition to fully virtualized, software-only networks in the near future.
That being said, operators can start to realize the benefits of NFV without needing to virtualize all their functions. Since applying cloud concepts to network functions is a new domain for many personnel, it is important for service providers to start developing this expertise immediately so they can effectively manage this evolution. Amazon did not build its infrastructure overnight, and the same will be true of the service provider cloud.
