NFV Terminology and Architecture from ETSI

Wendell Odom
By Wendell Odom May 20, 2015 09:05

Well, if you thought SDN introduced a lot of terminology, you’ll love NFV! The good news is that ETSI, which defines NFV, does a great job documenting NFV, with extensive term and acronym lists to support other documents about the details of NFV architecture. Several of the ETSI NFV docs provide some great stepping-stones for understanding the basic concepts and terminology, which is where we’ll go in this post.

This is the last in a related series! The other posts:

A Brief Big Picture of NFV

One of the challenges with this blog is figuring out how much prior knowledge to assume. If you don’t know much at all about NFV, read this section for a quick intro. Otherwise, skip to the next heading.

Briefly…

Think of every networking device used in the IT world. Those include routers, switches, firewalls, intrusion detection systems, load balancers, and so on. Traditionally, those devices have indeed been devices – purpose built hardware, running some OS that performed the networking function.

While you’re thinking of the old way to network, next think of all those diagrams we draw of our networks, showing that the switch connects with a cable to the router, which connects via cable to a firewall, etc. The combination of cabling between particular devices, plus the forwarding logic used by each networking device, defines where messages flow in a network. You can think of these diagrams as a graph, in that the diagram shows where expect messages to flow through one device, then the next, and so on.

Network Functions Virtualization (NFV) virtualizes the networking functions and the associated graph.

First, NFV virtualizes the networking functions from the purpose-built hardware, instead running the equivalent software as virtual machines on a server. So, instead of a bunch of networking hardware, each doing a particular networking function, you have a bunch of x86 servers, running VMs, each doing a particular networking function. To make that happen, the networking vendors supply an OS or app for each networking function, one that can run as a VM rather than on a purpose-built device.

NFV also defines a service graph of the networking functions and their sequence – think of this as the equivalent of a network diagram. Instead of cabling the VMs together, NFV knits the flow of messages from one VM to the next, and the next, and so on.

NFV provides many benefits to service providers and larger enterprises. For example, instead of buying and racking thousands of firewall appliances in anticipation of future customer requests, an SP can install more generic data center x86 server/storage/network capacity. That capacity can be used to run any service, including a lot more firewall instances (or not), depending on what the various customers need. And the deployment of these virtualized network functions can all be done programmatically, improving efficiencies.

 

ETSI Defines NFV. Who is ETSI?

NFV has grown up (standards wise) in ETSI, an SP-focused community. What is ETSI? To paraphrase, ETSI is the standards body recognized by the European Union (EU) to create Telecommunications standards. More specifically, quoting the about ETSI web page:

ETSI, the European Telecommunications Standards Institute, produces globally-applicable standards for Information and Communications Technologies (ICT), including fixed, mobile, radio, converged, broadcast and Internet technologies.

ETSI began their NFV work with volunteers from seven companies that are household names in the EU. Today, the ETSI NFV membership lists sits several hundred long. For perspective, here’s a list of the original seven companies, along with their country of origin; note that all have significant international businesses, and unsurprisingly have a large EU presence.

  • AT&T (USA)
  • BT (Great Britain)
  • Deutsche Telekom (Germany)
  • Orange (France)
  • Telecom Italia (Italy)
  • Telefonica (Spain)
  • Verizon (USA)

 

Four ETSI NFV Documents for Newbie Networkers

ETSI has been working hard at defining NFV since 2012, and they’ve accumulated quite a set of documents to read. I see four that would be of the most use for networkers who are trying to move from just cursory knowledge of NFV to getting into a little more depth. Figure 1 shows the four documents:

Figure 1: Four (of Many) ETSI NFV Docs

Of these, I would suggest starting with these two:

NFV Architectural Overview (NFV 002) This doc, at about 20 pages, gets into the internals of NFV, focusing on the architecture. It’s great for putting big ideas in context, with enough familiar terminology from outside NFV to make the transition a little easier.

NFV; Terminology for Main Concepts in NFV (NFV 003) This doc can be a huge help for those learning SDN and NFV. It’s simple, short, and sweet, and has two clear features with no clutter:

  • A dictionary of main terms
  • A list of abbreviations and acronyms (spelled out)

I would suggest a brief read through this document before starting any of the others (but move on from terms that don’t make sense – just browse it.) At 13 pages total, it won’t take long. Then keep this doc handy while you read any of the others.

The other two documents in Figure 1 should probably be saved from your next steps of getting into depth. In particular, the infrastructure overview (NFV-INF-001) document is useful, but at 59 pages, it gets into enough depth to slow down your reading. (I prefer the -002 doc as a starting point.) But the -001 doc does have it’s own built-in dictionary and acronym list (many of these ETSI NFV doc do include such lists), so it’s worth stopping to review that list to help get your terminology legs under you.

Finally, the NFVI Network Domain (NFV-INF-005) document gets into lots more details about how to implement Virtualized Network Functions (VNFs).

 

(Yet Another) Architecture, This one for NFV

This short series discussed a couple of architecture documents for SDN. So while we’re here, let me give you a few words about the NFV architecture as outlined in NFV-INF-002 from ETSI. You can pick these same ideas out from reading their document, but I’ll try and emphasize a few points.

First off, NFV focuses on providing networking functions, but some of the mechanisms are tried and true data center virtualization tools and features. So, one block of NFV architecture, called NFV Infrastructure, holds all the traditional DC virtualization features. That is, you need server hardware (compute, storage, and networking), a hypervisor on each server, management/orchestration software to manage the collection of servers, all so you can easily create/start/stop/delete Virtual Machines (VMs).

Figure 2 shows the NFV Architecture from NFV-INF-002, which the NFV Infrastructure piece at the bottom left.

Figure 2: ETSI NFV Architecture

 

The term Virtualized Network Function (VNF) refers to any networking function that now runs as a VM in an NFV design. For instance, if you now run a router as a VM instead of using a hardware router, that router VM would be a VNF. Those sit at the top of the architecture of Figure 2.

Finally, MANO refers to the management and orchestration functions of NFV. (The MANO term doesn’t really translate easily as an acronym, best I can tell.) To appreciate the pieces, take this more detailed version of the architecture (adapted from Figure 4 in the NFV-INF-002 doc), which shows three parts MANO:

 

Figure 3: ETSI NFV Architecture – Focus on MANO

This new figure adds the typical SP management systems (Operational Support Systems and Business Support Systems) at the top. MANO includes all management and control. However, the specific tools vary quite a bit, so it’s not necessarily some monolithic management structure. For example, if implementing the NFV Infrastructure with VMWare products, you would probably be using VMWare products to manage that same environment. If you implement one vendor’s firewall and another vendor’s IDS, then you may have different management software. All the management feature sit over in the MANO part of the architecture.

 

Opinions and Closing

I started this series commenting about the fact that the SDN world already has a variety of competing terms, with no one definitive reference. NFV, on the other hand, has a stronger terminology basis, given both its history and given the standards work done by ETSI. (That’s just my opinion.)

Let’s wrap this series then with a quick visit to the survey that I threw out in the first post. One terminology issue with SDN is to decide what term to use for a device that forwards messages in a network. What do you call a thing in SDN, or in NFV, that forwards messages? Do we get use the generic NFV term VNF? Or something more specific, like those in the survey? Weigh in with your opinion! And thanks for reading.

Some Impressions from Open Networking Summit 2015
SDN Terminology from Layered Models
Wendell Odom
By Wendell Odom May 20, 2015 09:05
Write a comment

No Comments

No Comments Yet!

Let me tell You a sad story ! There are no comments yet, but You can be first one to comment this article.

Write a comment
View comments

Write a comment

Your e-mail address will not be published.
Required fields are marked*

Subscribe

Subscribe to our mailing list and get interesting stuff and updates to your email inbox.

Search

Categories