There are two standards out there right now that have strong momentum. One being the ETSI NFV standard that has been around for quite a while, and the other being the recently open sourced Enhanced Control, Orchestration, Management and Policy (ECOMP) architecture from AT&T based on the work done as part of Domain 2.0.
ETSI has been the leader in this space, and is the standard that almost everyone is using. It is also a less complicated view of what is required to successfully create and manage an NFV environment. There are gaps in the ETSI standard, but it is still evolving as implementations become reality. ETSI NFV is also the basis of the OPNFV project seeking to define a set of open source tools for use in NFV.
ECOMP is much more detailed, and addresses all of the operational areas required for long term success. However, it has fewer companies using it which could slow its growth and evolution. The breadth of functions covered by ECOMP is much more comprehensive than the ETSI NFV standard, so it is well worth consideration when you are implementing your NFV environment.
We are going to take a look at each, where the gaps are, and compare the standards to each other. This comparison will lead to some insights on how to evolve the ETSI standard to fill some of its gaps.
The ETSI NFV standard is king across the industry at the moment. It is the standard that almost every vendor is developing their solutions to, and it is the standard that almost every company looking to implement NFV in their network is using as a reference on how to do so. The major components of the ETSI NFV standard are illustrated, and explained, below:
Source: http://www.etsi.org/deliver/etsi_gs/nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf
The ETSI NFV model has 4 major areas: NFV Infrastructure (NFVI), Management and Orchestration (MANO), Virtual Network Functions (VNF)…and associated EMSs where appropriate…as well as the OSS integrations to MANO.
The NFVI is where physical and virtual Compute, Storage and Networking resources reside.
The VNF/EMS area is where the virtualized network functions, such as firewall and router capabilities, reside. As VNFs evolve over time to being more “cloud native” in nature the use of an EMS to manage these components will likely go away. However, for now it is common to see the presence of EMS in an implementation. We will discuss more on VNFs and their future evolution in the next entry in this blog series.
The OSS integration area is where the MANO tools interact with existing OSS tools.
The MANO stack, consisting of the NFV Orchestrator (NFVO), VNF Manager (VNFM), and Virtual Infrastructure Manager (VIM), is where the management of the NFVI takes place. It is also where instructions are received from OSS systems on services to provision/modify/remove, as well as being a source of data passed to the OSS tools for fault and performance events related to NFV services.
We will be discussing the details of each of the major areas in future blog posts, with an emphasis on MANO and OSS interactions.
For more detail on the ETSI Standard you can review the ETSI documents found at:
http://www.etsi.org/technologies-clusters/technologies/nfv
Similarly the ECOMP architecture has a few major areas. These are: the Portals for Design and Operational Functions, the Service Design and Creation and Policy Creation components, the Analytic Design component, the Active and Available Inventory (A&AI) component, the Data Collection Analytics and Events (DCAE) component, the Master Service Orchestrator (MSO), and the Controllers for various networks and applications.
Source: http://about.att.com/content/dam/snrdocs/ecomp.pdf
The Portals, naturally, provide a user interface for Design, Policy and Ops activities. Providing the business logic and functionality are underlying components for Service Design, Policy Design and Analytics.
The A&AI component provides a view into provisioned services, as well as available resources. It is model driven and provides the ability to dynamically add and modify services.
The DCAE component provides FCAPS functionality in managing the services and devices involved.
The MSO component provides end to end orchestration of the activities taking place with the framework.
For more detailed information on the ECOMP architecture you can review the AT&T white paper at:
http://about.att.com/content/dam/snrdocs/ecomp.pdf
While the two may look very different in the views above, they are very similar in implementation. The idea in development of ECOMP was to expand on the ideas presented by ETSI, with an increased focus on Controllers and Policy. ECOMP also expands the resource and services inventory capabilities of ETSI NFV, and moves the FCAPS functionality that ETSI assigns to the EMSs to being a core part of the ECOMP components.
The diagram below, from the ECOMP white paper referenced above, shows how they compare in a similar presentation of components.
Source: http://about.att.com/content/dam/snrdocs/ecomp.pdf
The major differences you should notice, as already mentioned, are in the areas of EMSs, which disappear in ECOMP, and the addition of enhanced FCAPS capability within the MANO-like area of ECOMP. Other than those, there are largely the same. As ETSI NFV evolves we may see it look more and more like the AT&T ECOMP architecture.
The future will see these frameworks evolve as more companies implement solutions based on each, and gain the real world lessons that can only be learned through operational experience.
One of the future additions to the ETSI model is likely to be an end-to-end orchestrator, such as is found in some of the open source MANO projects based on the ETSI NFV standard today.
OPNFV will continue to push the boundaries as well as it expands its focus from a VIM/NFVI focus to more of a MANO focus, which has just barely begun at this time.
I expect the view of these frameworks to be very different a year from now when we revisit them. I do not, expect another standard to emerge however. AT&T’s focus on ECOMP should keep it relevant, but ETSI and its NFV standard aren’t going away in this space. For now, using either of these views as the basis of your NFV work would not be a mistake.
Next week we will look at VNFs as they are being implemented now versus how they are evolving, and what that means for the future of NFV…hint: it is good.