NFV Elements

The New Face(book) of Carrier Class?

As traditional communications service providers (CSPs) seek to gain the promised benefits of Network Functions Virtualization (NFV), it is also prudent to look at potential downsides.

Replacing today's carrier-class network equipment with unproven software running on commercial servers scares the daylights out of some operators. And yet, new cloud/SaaS/OTT providers such as Facebook, Netflix, Google and Amazon provide a variety of cloud-based services that are not built using traditional telco gear and architectures.

I know this isn't going to be popular but we need to consider that Facebook et al. may just be the new faces of carrier class. How do they do it? Is there an opportunity to change how telco services are delivered, and how users consume them?

NFV: Bringing the cloud to the world of telco
CSPs know that the cloud brought tremendous advances in low cost, on-demand compute and storage enabled by rapid development of software hosted on standard servers. The benefits of the cloud model are apparent in terms of direct user services such as Facebook, Netflix and LinkedIn; online markets such as Amazon and Uber; and compute utilities like Amazon AWS and Microsoft Azure.

In its simplest incarnation, NFV is the idea of applying these principles to the world of telecom. Today we use closed network appliances (e.g., router, firewall, VoIP gateway, etc.), as shown in Figure 1.

Figure 1: Service delivery today
Figure 1: Service delivery today

The appliances may differ in appearance, size and cost, but from a network view they implement a needed network function. For example, Figure 1 shows a deployment of customer edge (CE) and provider edge (PE) routers, which differ dramatically from each other in size and complexity. However, they both look like routers at the network topology level.

With NFV, we replace the appliances with software virtual network functions (VNFs) running on servers, as shown in Figure 2. The network view does not change. The routing function is equivalent, regardless of whether it is implemented by appliances or software running on a server.

Figure 2: Service delivery with NFV
Figure 2: Service delivery with NFV

The network view of the service elements did not change, but what about the other aspects, such as resilience and uptime? One of the big concerns of CSPs regarding NFV is the low reliability of servers compared to today's highly resilient network elements. How can CSPs get the benefits of NFV without giving up service availability?

Different implementation, different resiliency
Today, CSPs achieve resilience in service delivery by using a network composed of highly available elements connected by redundant communications links, as shown in Figure 3.

Figure 3: Service resilience today
Figure 3: Service resilience today

At each point in the network there is a highly reliable element, along with a redundant element available to take over in case of a failure:

  • At the customer site there are two small routers that coordinate activity using a protocol such as HSRP.
  • In the metro area there are redundant communication facilities that are diversely routed to provide protection against the typical failures, such as excavations and floods.
  • In the central office (CO) or point of presence (POP) there is a chassis-based router with redundant blades.

Note that the addition of resilient elements does not necessarily change the network view: That's because the redundant elements are held in an inactive state until needed.

Clouds are implemented in data centers that take a radically different approach to resilience. Data centers comprise a set of unreliable elements that are orchestrated into a reliable service. Cloud service providers allocate a percentage of excess compute and storage elements that are used to provide backup when others fail. The orchestration function provides the command and control to detect these failures and to move any affected functions from the failed unit to an available standby unit.

Clearly this approach works. Companies such as our previous examples of Netflix, Google and Amazon are able to provide resilient services. How can we apply this model to NFV? An example is shown in Figure 4.

Figure 4: Service resilience with NFV
Figure 4: Service resilience with NFV

How is resilience implemented in this NFV world?

  • In the metro area there are redundant communication facilities as before. You can't virtualize physical pipes!
  • At the customer site and CO/POP we have a choice. We could use two servers, or use two blades in a blade server. In either case the router VNFs coordinate activity as before, using a protocol such as HSRP.

By moving to a virtualized service, do we automatically gain the cloud benefits of dynamism in terms of scalable and on-demand services? Not necessarily. NFV orchestration is also needed to allocate and control the needed virtual resources. Furthermore, I believe pure-play virtualization is needed to enable the placement of functions where they need to be based on service requirements and available resources. (See The Case For Pure Play Virtualization.)

So, with NFV and orchestration we can implement a reliable service. Aren't we just recreating the wheel?

Wait -- don't answer yet! There's more…
Of course not. With cloud technologies such as NFV, SDN and orchestration, we are not only able to recreate today's services, we are able to make them better.

  • They can be delivered on demand via customer portals, rather than weeks later with truck rolls.
  • They can be scalable to meet time-varying demand.
  • They can have innovative pricing models based on usage, time of day or try before you buy.
  • They can have new resiliency models that take advantage of multiple data centers to provide geographic diversity to protect against regional disasters.

That's good, and it gets better. With programmability in the network and sophisticated control systems (orchestration and SDN), it is now possible to rapidly develop and deploy new services that will drive new revenue and new profitability.

— Prayson Pate, CTO, Overture Networks Inc.

danielcawrey 6/25/2015 | 2:55:58 PM
On Demand I really like this idea of on-demand portals. Customers want services when they want them (predictably) and therefore it's key that service providers offer speed to service these days. I think we are seeing with the likes of Facebook that people have an expectation, and carriers need to get on board with providing ASAP. 
mhhf1ve 6/25/2015 | 6:16:02 PM
Re: On Demand I totally agree with you, danielcawrey. ISPs have been offering some "on demand" services to businesses for temporary speedier connectivity -- and I think some households would want that too. When people invite over everyone in the family for Thanksgiving... it'd be nice to not have the WiFi network slow to a crawl..?
VictorRBlake 6/25/2015 | 7:02:09 PM
What does facebook have to do with the CE I fail to see what Facebook has to do with CE. For one, they do not provide access services, so I don't see what access has to do with Facebook. For a second, even if they did, it would be unlikely that they are delivery MEF service and thus using a CE. it would be more likely that any service they integrated with would use IP based (CPE). CE is usally a reference to the term CE in MEF. If it was intended to be a reference to any CPE (as in CPE == CE) I still don't follow because you don't need a PE at the edge for IP broadband. The purpose of the PE is for MPLS signaling as the PE is the point at which interfaces are attached to LSPs. This is by no means necessary and is not typically used for IP/Internet (aka broadband) services. Instead, the complexities of MPLS are more typically reserved for the transport of other (non-internet transit) services over a single converged IP network. Exemplary transport services would be things like Ethernet (as in Carrier Ethernet described by MEF), VPNs (L2 or L3), or some other private or virtual private service.

All that said, the point about separating out service integration from forwarding is reasonable, but I again don't see what Facebook has to do with VMs. They were around before Facebook and are used by carriers and other operators without respect to Facebook.
VictorRBlake 6/25/2015 | 7:23:42 PM
Re: What does facebook have to do with the CE I should say, as for Amazon, I agree that they are now a carrier. Although I wouldn't see the CE connection, when they provide VPN services from one private cloud to another, that is directly competitive with other VPN (L2 or L3) or dedicated L2 or shared L3 services.
prayson.pate 6/26/2015 | 2:57:42 PM
Re: On Demand
Rate It

danielcawrey and mhhf1ve - Your points about on-demand services are very good.  Masergy just made an announcement about how they are using NFV to enable dynamic services for their customers. Here is the LR coverage: http://www.lightreading.com/nfv/nfv-strategies/masergy-to-launch-global-enterprise-nfv-service/d/d-id/716553

Also, here is an excerpt from our press release regarding the support for dynamic services:

"Our primary focus is on service agility and our pure-play NFV deployment sets the stage for immediate response to customer requests," said Tim Naramore, Masergy's chief technology officer. "Masergy has long been an innovator, providing our customers with solutions that give them real-time control and the ability to get the services they need, when they want them. With this launch, we're adding incredibly agile and flexible solutions to our Managed Network f(n)™ family of distributed, fully managed network functions."

The PR is here: http://www.overturenetworks.com/press_release/overture-announces-first-commercial-pure-play-nfv-deployment-with-coalition-of-global-technology-leaders/

prayson.pate 6/26/2015 | 3:16:17 PM
Re: What does facebook have to do with the CE VictorRBlake - My thinking is not that Facebook et al are carriers per se, and not that they are providing Carrier Ethernet services or infrastructure.

Instead, I am pointing out that these new cloud-based companies deliver services with high availability (as do telcos), and they do it using unreliable equipment (unlike telcos).  They do so using cloud technologies: VMs running on a pool of unreliable servers, with resiliency coming from the system using orchestration and control. 

As telcos move from traditional hardware elements in the network to virtualized solutions using NFV, they need to look at changing how they build systems and deliver reliable services.

The examples that I showed were intended to provide some concrete details on what this transition might mean for typical services delivered today.

Does that answer your questions?
prayson.pate 9/19/2015 | 8:21:32 AM
More on resilience of NFV/SDN systems ACG Research posted this blog on the matter of resilience: "Regardless of Technology, SPs' Requirement Fundamentals Don't Change"

Link: http://acgcc.com/regardless-of-technology-sps-requirement-fundamentals-dont-change/

Sign In