Verizon’s SDN/NFV Architecture in Depth

I noted in my introductory blog in AT&T’s and Verizon’s SDN/NFV approach that Verizon has taken a totally different tack with its architecture.  Where AT&T is building open-source glue to bind its vendor-controlling D2 architecture, Verizon is defining an open architectural framework for vendor integration.  Standards from the ONF, TMF, and NFV ISGs fit deep in the AT&T ECOMP model, but the Verizon model is built around them.  That’s a critical difference to keep in mind as you read this.

Just as there’s a critical difference between the Verizon and AT&T models, there’s a critical commonality.  Both operators are saying that the current standards work isn’t going far enough fast enough.  In particular, both admit to the fact that the scope of the current work is too focused, so assuring broad-based benefits is nearly impossible.  So, in either architecture, standards are somehow supplemented to create something with enough functional breadth to be truly useful.

One obvious extension in the Verizon model is its functional heart, which is End-to-End (E2E) Orchestration.  Verizon builds E2E around the NFV Orchestration (usually called “MANO”) element, and from E2E it extends control downward in two forks—the SDN and NFV forks.  Network connectivity of all types is managed along the SDN path, with real devices (Physical Network Functions or PNFs in the Verizon diagram) and SDN-OpenFlow elements both under a set of SDN controllers.  On the NFV side, the structure is fairly standard, except for the critical point of SDN/NFV separation that we’ll get to.  There are also two “flanks”, one for FCAPS NMS and the other for OSS/BSS.

The way that SDN is handled is the most different thing about the Verizon approach.  Rather than proposing to have a single “Network-as-a-Service” model that then decomposes into vendor- or technology- or geographic-specific domains, Verizon has created three firm subdivisions—Access, WAN, and Data Center (DC) (along with an undefined “other”).  They appear to link the DC with the NFV elements only.

The classic interpretation of the NFV ISG model is that connection services are a subset of infrastructure services, meaning that they’d be expected to be supported by a (Virtual) Infrastructure Manager or VIM.  Verizon’s splitting of the data center connections off into the SDN control space firmly divides the SDN from the NFV, with cooperative behavior created above in the E2E function.  This somewhat mirrors the separation that AT&T proposes in its ECOMP model, where “Controllers” handle the cloud, the network, and applications.

The management flank is “Service Assurance”, and it consists of the traditional NMS FCAPS applications plus log management and correlation tools.  There are NMS links into both the SDN and NFV forks we’ve already described, and the links are both to E2E and to the lower forks, which implies a complex management relationship.  The OSS/BSS flank comprises connections to the OSS/BSS system from E2E and also from PNFs.  The “management” functions in the Verizon model are designed around the notion that function management is the same for either PNFs or VNFs.  Thus, you deploy a VNF using NFV tools, but you manage the functional aspects using a management toolset evolving from today’s EMSs to something like SDN control.

Verizon’s document starts its detailed description with the NFV Infrastructure (NFVI) element.  Verizon goes into great detail explaining the relationship between hardware elements (physical infrastructure) and software elements (virtual).  They also explain things like how a VIM “discovers” what its infrastructure is capable of, which is a nice advance in thinking from the ETSI starting point.  They do the same on the SDN side, including framing the future direction around intent-based interfaces.  All of this facilitates the interworking of components of the architecture with each other, critical if your intent is (as I think Verizon’s is) defining a framework in which vendor elements can be interworked confidently.

This is one area where Verizon’s document shines.  They’ve gone a long way toward defining the hardware for NFV, right down to CPU features, and they’ve also done well in defining how the physical infrastructure would have to be managed for consistency and reliability.  Every operator interested in carrier cloud should look at the document for this reason alone.

Another area where Verizon has the right approach is service modeling.  Verizon’s architecture shows a kind of succession of layers—service to functional to structural.  Each layer is governed by a model, and that allows vendors to incorporate model-driven deployment they may already have offered.  You can also model different layers in different ways, or even use two different models in the same layer.  YANG, for example, is a good architecture to model real network configurations, but I firmly believe that TOSCA is better for cloud deployments and functional/service-layer stuff.

As always, there are issues, and the big one here starts with the goal (can you hope to define an open architecture for vendors, and if so can you move the ball relative to the standards groups) and moves to some details.  I think that two issues are paramount.,

One area I think may pose a problem is the lack of specific support for multiple Infrastructure Managers, virtual or otherwise.  The biggest risk of lock-in in NFV comes because a vendor provides a VIM/IM for its own gear to the exclusion of all other gear.  If multiple VIM/IMs are allowed that’s not a major problem, but clearly it’s a killer if you can have only one VIM/IM in the architecture and several (incompatible) vendors want to be it!

In both my CloudNFV architecture and my ExperiaSphere architecture, I proposed that the equivalent of the VIM/IM be explicitly referenced in the model element that connects to the infrastructure.  That would allow any suitable VIM/IM implementation to be used, no matter how many, but it does require that the E2E model have the ability to include the specific reference, which Verizon says it doesn’t do.  I think they’ll need to fix this.

My other area of concern is the VNF Manager.  Verizon has retained the ETSI approach, which defines both “generic” VNFMs that can support multiple VNFs, and Specific VNFMs (S-VNFMs) that are specific to a given VNF.  I’ve cataloged all my concerns about this approach in previous blogs, and those interested can use the Search function on my blog page to find them.  For now, let me just say that if you don’t have a standardized way of managing all VNFs, you’ll end up with a significant onboarding issue, which is where we are now with the ISG model.

Part of the VNFM issue, I think, arises from a bit of vCPE myopia on Verizon’s part.  Yes, Verizon has the geography where vCPE is most likely to deploy (they have over three times the opportunity that AT&T has in its own home territory, for example).  However, Verizon’s customers are also long-standing users of business WAN services, and its therefore less likely that they 1) need a managed service approach and 2) don’t already have a solution for it if they do.  The focus on NFV in the model, and then on vCPE as the NFV application of choice, could fall short of justifying a major NFV commitment, which would make the architecture moot.

I think it’s clear from the Verizon material that the goal is to guide vendor implementations of what’s supposed to be an open architecture.  Candidly, I think this is going to be a hard road to travel for Verizon.  First, it’s far from clear that vendors are interested in an open approach.  Second, once you get outside the very limited boundaries of SDN and NFV standards, there’s nothing to guide an open model or even to pick a specific approach.  Verizon’s architecture identifies a lot of things that are critical, essential, to a business case.  The problem is that they don’t define them in detail, and so implementations in these extended areas have no reference to guide converging approaches.

Whether this will work depends on the vendors.  Those same vendors, it must be said, who have not stepped up to NFV, in no small part because most of them either see a small reward at the end of a long road, or no reward at all.  Creating a framework for vendor participation does little good if they don’t want to participate, and whether they do is still an open question.  That question, if answered in the affirmative, will only expose another question—whether the Verizon framework delivers on its technical mission, and there I have questions of my own.  The dependence on the formal standards that Verizon has created is risky when those standards don’t cover enough to make the business case.  Will Verizon fix that?  I don’t know.