SDxCentral
Join Log In
SD-WAN 4 5G 17 Edge 7 IoT 14 SDN 9 NFV 10 Containers 2 Cloud 15 Security 5 AI 8 Data Center Storage 1 APM/NPM 1 Open Source

Log In to SDxCentral

Log in with your email? Forgot your password?
  • Newsletters
  • eBriefs
  • Podcasts
  • Webinars
  • Videos
  • Directory
  • White Papers
  • Resources
  • Use Cases
  • Support

Join SDxCentral and get information tailored to your particular interests everyday.

Join
Sponsored:
Dell EMC 8 Citrix Riverbed

Topology Options for NFV

NFV Topologies
Prayson Pate May 14, 2015
7:00 am MT

There is some debate about the best way to implement network functions virtualization (NFV) and where to host the constituent virtualized network functions (VNFs). The options are described in the original ETSI NFV white paper:

NFV aims to transform the way that network operators architect networks by evolving standard IT virtualization technology to consolidate many network equipment types onto industry-standard high-volume servers, switches and storage, which could be located in data centers, network nodes, and in the end–user premises.

The question is whether to centralize hosting, or to distribute the hosting out to a central office or even the edge of the network. My view is that all these options are valid.

Centralized NFV Topology – Lowest Cost

In this topology model, all of the VNFs are hosted at a centralized location in a metro area. Here’s an example of how that might look:

Centralized NFV Topology – Lowest Cost

In this discussion, the centralized model could be implemented in either a large data center or in a smaller central office, with the only difference being scale. In either case, the centralized model provides a shared pool of large servers, enabling the maximum statistical multiplexing of compute loads for multiple consumers. This configuration is ideal for deploying services to small and medium-sized businesses. It also enables the creation of service overlays using existing Carrier Ethernet connections to the service edge.

Here are some key considerations of the centralized topology:

  • First Cost: The one drawback to this approach is that it requires a substantial initial investment to build out the infrastructure in the areas where services are needed.
  • Per-Unit Cost: Having a large pool of inexpensive, general-purpose, shared servers means that the cost for each virtual service is low, and re-use of resources is maximized. This is a huge advantage.
  • In-service scalability: Another advantage of this approach is that compute and storage resources can easily be added to the centralized location, and then be made available for any services that need them.
  • Overlay services with no upfit of edge: The centralized virtualization can be used to create services that overlay existing Carrier Ethernet 2.0 (CE 2.0) facilities. The operator can create CE 2.0 connections from the service edge to a VNF hosted in a centralized location, maximizing the use of the existing edge network. The one caveat is that some services may require functionality beyond that of CE 2.0.  Examples include prioritization at layer 3 and security functions.
  • Edge services, e.g. routing and security: Another disadvantage to centralized virtualization is that it cannot support services where particular functionality is needed at the service edge. For example, a security-critical service cannot be delivered unless security functions can be placed at the service edge. Another example is latency-sensitive applications, which can best be met with collocated network functions. The one caveat is that some services may require functionality beyond that of CE 2.0.  Examples include prioritization at layer 3 and security functions.
  • External service chaining needed: With a centralized approach there is no need for service chains to extend beyond the serving data center, which simplifies orchestration.
  • Disruption to PMO: Perhaps the biggest drawback of centralization is that it requires a major change to the present mode of operation (PMO). In short, it requires a fundamental change to how services are constructed.

Service Edge NFV Topology – Scalable and Service Rich

In this topology model, the virtualization resources and hosting of VNFs are pushed to the service edge, as shown in the following figure.

ervice Edge NFV Topology – Scalable and Service Rich

The pros and cons of this topology include:

  • First Cost: A huge advantage of putting the virtualization resources at the service edge is that the first cost is minimized. There is no need to build out centralized infrastructure before deploying virtualized services; the resources are deployed when each customer is added.
  • Per-Unit Cost: The other side of this equation is that there is very little opportunity to achieve lower costs through scale. Because the virtualization resources are located remotely, the cost is constant.
  • In-service scalability: Another drawback to this approach is that the ability to add additional services or scale is limited by the installed resources. This limitation can be overcome using the chained approach described in the next section.
  • Overlay services with no upfit of edge: This consideration is not applicable because the service edge model assumes an upfit deployment at the service edge.
  • Edge services, e.g. routing and security: The ability to deploy functions at the service edge enables a class of advanced services that are not possible in a centralized model. Some examples include dual homed routing, WAN optimization and security functions.
  • External service chaining needed: As with the centralized approach, placing resources in one location means that no advanced service chaining is needed.
  • Disruption to PMO: The service edge model replaces a stack of appliances with a server running VNFs. However, the deployment location is not changed, and no changes are needed back in the network. As such, this approach requires only an incremental change to the PMO.

Chained NFV Topology – The Best of Both Worlds

With chained NFV, services are composed using resources that are distributed throughout the network and then chained together, as shown here:

Chained NFV Topology

Here’s how the chained topology model measures up:

  • First Cost: As with the centralized model, the chained model requires an initial investment to start deploying services.
  • Per-Unit Cost: The chained model utilizes shared resources for low per-unit cost. It will be somewhat higher than a purely centralized approach due to the location of resources at the service edge.
  • In-service scalability: One advantage of the chained model over the service edge model is the ability to add virtualization resources without having to upgrade the service edge.
  • Overlay services with no upfit of edge: Not applicable.
  • Edge services, e.g. routing and security: The chained model can support all of the advanced applications that are available with the service edge model.
  • External service chaining needed: The biggest complexity of the chained model is that it requires advanced orchestration to combine physical and virtual resources across multiple physical locations.
  • Disruption to PMO: This is the most powerful virtualization model and, as a result, is the most complex.

The Power of NFV – Put the Functions Where Needed

I have described some of the tradeoffs and synergies between the various topology models. These characteristics are summarized in the following table:

Characteristic Centralized Edge Chained
First Cost High Low High
Per-Unit Cost Low High Medium
In-service scalability Unlimited Low Medium
Overlay services with no upfit of edge Yes N/A N/A
Edge services e.g. routing and security No Yes Yes
External service chaining needed No No Yes
Disruption to PMO High Low High

By using the appropriate NFV topology for a given service, operators can match the requirements of the customers to constraints such as bandwidth and latency, as well as available resources. Doing so ensures that the power of virtualization is optimally applied to unleash new services.

Related Articles

Ericsson, VMware Cozy Up With Telcos on NFV
Ericsson, VMware Cozy Up With Telcos on NFV
ZTE-Rises-Above-Political-Woes-With-Core-5G-Network-Claim
ZTE Rises Above Political Woes With Core 5G Network Claim
2019 Resolutions for Healthier NFV
2019 Resolutions for a Healthier NFV and SD-WAN Ecosystem
Ericsson Turnaround Could Limit Growth Potential Says TBR
Ericsson Turnaround Could Limit Growth Potential, Says TBR
InterDigital Solves Mobile 5G Problems Far in Advance of Standards
InterDigital Solves Mobile 5G Problems Far in Advance of Standards
IBM, Nvidia Team Up on Converged Storage for AI Workloads
IBM, Nvidia Team Up on Converged Storage for AI Workloads
SDxCentral Daily News

Join your Peers! Subscribe to SDxCentral's Newsletter

Article Tags:

Contributed Articles NFV

Subscribe to Get the Daily News!

About SDxCentral

  • Newsletters
  • About Us
  • Contact Us
  • Work With Us
  • Editorial Team
  • Careers
  • Legal
  • Support

Engage With us

This material may not be copied, reproduced, or modified in whole or in part for any purpose except with express written permission from an authorized representative of SDxCentral, LLC. In addition to such written permission to copy, reproduce, or modify this document in whole or part, an acknowledgement of the authors of the document and all applicable portions of the copyright notice must be clearly referenced. All Rights Reserved.

© 2012-2019 SDxCentral, LLC, All Rights Reserved. SDNCentral™, the SDNCentral logo, SDxCentral™, SDxCentral logo, SDxNews™, SDxTech™, SDx™, the SDx logo, and DemoFriday™ are trademarks of SDxCentral, LLC in the U.S. and other countries.

  • Terms of Service
  • Privacy