Any time a Tier One decides to open the kimono a bit on their planning for transformation it’s important. AT&T did that with its paper on ECOMP, which stands for “Enhanced Control, Orchestration, Management, and Policy” and the topic makes the comments doubly important. As operators seem to be looking to take on more of the heavy lifting in transformation ECOMP is a signpost on what a major operator thinks it has to do. Which of course means it’s an exemplar for doing the right thing.
ECOMP, like so many other things we now seem to be seeing, is a top-down, service-lifecycle-focused approach. AT&T link it to their Domain 2.0 (D2) project, which has been evolving for almost five years now, and which guides infrastructure procurement. It seems that ECOMP is an indicator that service lifecycles exist outside the pure infrastructure realm; “ECOMP is critical in achieving AT&T’s D2 imperatives” according to the white paper.
As an architecture for D2, ECOMP is more than SDN, more than NFV, and even more than OSS/BSS, and in fact it displaces some of the functions of all of these things. Service lifecycle management ECOMP-style steals lifecycle management features from all of these things, and so it can be seen as a kind of shim that connects the next generation of infrastructure and the next generation of services and facilitates evolution both in the service and infrastructure spaces.
The structure of ECOMP is interesting. At the top, it’s a multi-dimensional portal that offers both direct access to design and operations functions and an interface through which current OSS/BSS systems and presumably NOC tools and procedures can access information. There’s also provision for big-data analytics integration at the top. Below that on the “left” in the figure, are the new elements ECOMP introduces, primarily in the area of design and policy specifications. On the “right” are the collection of applications, services, and tools from legacy and new sources that form the engine of ECOMP, under the control of the Master Service Orchestrator (MSO). Controllers and infrastructure managers fall into this portion.
The main diagram for ECOMP doesn’t name SDN or NFV (NFV’s VNFs are listed as managed element examples) but it’s pretty clear that ECOMP and MSO live well above both these technologies and that legacy management interfaces and the devices they represent are co-equal with the new stuff in terms of creating service resources. Thus, like Verizon, AT&T is creating a model of future networking that embraces current technology. That’s in part for evolutionary reasons, but also I think to keep their technology options open and to introduce orchestration for efficiency and agility without committing to major infrastructure changes.
According to the paper, “Orchestration is the function defined via a process specification that is executed by an orchestrator component which automates sequences of activities, tasks, rules and policies needed for on-demand creation, modification or removal of network, application or infrastructure services and resources.” No technology specificity and no indication of reliance on higher-level OSS/BSS processes. The process specification drives orchestration. It’s also clear in a later section that ECOMP so extends NFV specifications as to totally subsume them, creating a higher-level structure that the NFV ISG might have created directly had they taken a top-down approach.
The biggest advance ECOMP specifies, IMHO, is the metadata-driven generic VNF Manager, which presumably eliminates the need for one-off VNF integration during onboarding, something that the VNF-specific VNFM concept of the ETSI ISG leads to. This, says the paper, “allows us to quickly on-board new VNF types, without going through long development and integration cycles and efficiently manage cross-dependencies between various VNFs. Once a VNF is on-boarded, the design time framework facilitates rapid incorporation into future services.” This concept of metadata-driven VNF management is critical, and while the paper doesn’t say so it would appear that the same model could be applied to legacy network elements, which means management could be generic overall.
AT&T Service Design and Creation (ASDC) is the modeling application that manages all this metadata, and metadata also controls the integration of the components of ECOMP themselves. Thus, ECOMP is a realization of a data-model-driven approach, the very thing I think that the ETSI ISG, the ONF, and the TMF should have worked for from the first. It appears that metadata from the resource side and from the service side are model-bound, which makes deployment of services resource-independent as long as the modeling defines conditional selection of infrastructure based on things like location or performance—which appears to be the case.
The modeling approach taken by ECOMP seems to draw from a lot of sources. They have separate service, resource, and product models and that’s a feature of the TMF’s SID approach. They use inheritance and some of the cloud-centric features of TOSCA too, and in configuration they use YANG. There’s nothing wrong with multiple modeling approaches, though as I’ve said in the past I believe there are benefits to having a common modeling language down to the level right above the resources themselves.
There’s a lot to like about ECOMP even if you forget for the moment that it’s an operator’s solution to operators’ problems. There’s also at least a chance (if there’s enough interest, says AT&T) that it will end up open-sourced. Obviously that would create competition for vendor approaches, but ECOMP could have an impact on vendor solutions whether AT&T opens it up or not.
There is nothing here that a full-spectrum business-case-ready NFV solution could not provide. Every one of the six vendors I’ve cited in that space could frame something functionally close enough to ECOMP to be suitable. It would be tempting to suggest that if vendors had jumped out quickly enough, AT&T might have adopted a vendor approach, but from what I know of ECOMP evolution that’s not true. ECOMP concepts go back to 2013 before any of the implementations of NFV from those six vendors was even announced.
What is relevant at this point is how ECOMP could impact the market dynamic. If you add it to the CORD interest I’ve recently blogged about, it’s obvious that operators are well into a new stage of SDN and NFV, one where CTOs and standards people have to take a back seat to CFOs, CIOs, and product/service management. The result of that is a quick upward welling of focus toward the business-case issues.
There are similarities between CORD ant ECOMP, mostly at an architecture or goal level. CORD seems to take things further and in a slightly different direction, helping operators assemble infrastructure by assembling feature-repository offices instead of trying to glue zillions of technical elements. The CORD orchestration model, XOS, binds all the functionality and resources. With ECOMP, the binding and lifecycle processes themselves are the goal, but you probably end up in the same place.
CORD, and now at least for AT&T, ECOMP, represent the new generation in transformation visions. At least a dozen operators I’ve heard from are looking at something bigger, broader, and more directly aimed at securing benefits than either SDN or NFV. While some may believe this kind of thinking would kill the two recent industry favorites, the fact is that it could save them. If SDN and NFV are incorporated in a benefit-capable framework they have a chance. If not….
If I were a vendor in the NFV space, what I’d do now is to jump on CORD and forget any specific worries about SDN and NFV standards. ECOMP blows kisses at NFV in particular, but it clearly is a redo of an awful lot, and it ignores even more. I think any vendor who sticks with the ETSI vision at this point as being sufficient is dooming themselves. But you can’t roll your own NFV as a vendor, which means you need to lock onto another architecture. CORD is then only game in town.
CORD isn’t complete. SDN and NFV aren’t complete. Nothing much is “complete” in the transformation space or we’d have transformed by now. But ECOMP shows what at least one form of completeness would look like, would include. It’s close enough to CORD that it can be reached from there. ECOMP also shows how badly we’ve messed up what we’re saying are our most transformational network technologies. I hope we don’t mess up the next one too.
