When AT&T and Verizon released their architecture models for SDN and NFV, I did a quick blog overview of the two. I’ve had a chance to talk with operators and vendors about the approach now, and I’d like to revisit the two architectures based on what I’ve heard. This is going to be a three-part series, with this (the first) focused on broad architecture and goals and the other two on the specifics of the two architectures.
To me, the important starting point for the discussion is the fact that both operators believe that they have to step up and define an architecture on their own. We’ve seen in other areas (like 5G and IoT) that operators are increasingly unhappy with the pace of standards development and the support they believe they’re getting from vendors. The market doesn’t wait for I-dotting and T-crossing, nor can the operators. They need something for SDN and NFV that delivers benefits that justify deployment and, at deployment, solve the problem of profit-per-bit compression. Standards haven’t delivered.
On the other hand, operators have spun a lot of cycles in activities like the TMF, ONF, and NFV ISG and they don’t want to just toss the work (and money) away. Thus, it’s not surprising that these two operators think that they have to blow a few kisses in the appropriate directions. The biggest risk that these two operator initiatives share is the one they’ve inherited from those other activities. It’s not just a matter of not having gotten enough done, or of not working fast enough to do more. Some of what was done, having been approached wrong, was done wrong. Some break with the past may be essential in avoiding the pitfalls that have already been created.
My read on the AT&T and Verizon models is that they have some similarities but also some fundamental differences, and these differences reflect what I think are basic differences in the goal of each of the operators. AT&T is defining an open-source project that effectively puts vendors in their place, where Verizon is defining an open framework to encourage vendors. Keep these missions in mind because I’ll refer back to them and even expand a bit on their implications.
AT&T’s ECOMP is an element in its Domain 2.0 (D2) strategy, and that’s important because D2 tries to divide up networking into functional pieces where AT&T can then establish a number of specific bidder/competitors for future deals. Fundamental to D2 is the idea that vendors can’t create vast connected ecosystems that put the operator in an all-or-nothing position. ECOMP, as an architecture for the software elements that create the service lifecycle and manage infrastructure, has to insure that vendors stay where they’re put. Thus, it doesn’t try to create open elements within itself, which would risk the substitution of a vendor element that might pull through other stuff. Instead it creates specific low-level points where equipment and software can be placed.
Because D2 isn’t limited to virtual elements, the AT&T strategy has relevance to all its services and infrastructure. You could orchestrate a service made up completely of legacy equipment with the AT&T approach, though it seems clear that AT&T intends to use both SDN and NFV as broadly as it can. Still, the D2 focus when combined with the open-source implementation implies that AT&T is truly building a “software-defined” network.
Verizon’s “SDN/NFV Reference Architecture” has no company-offered convenient acronym, so I’m going to refer to it as “SNRA” here. Whatever you call it, the contributors and acknowledgements page makes it clear that there were more vendor people involved than Verizon people. I’m not suggesting that outside pressure is what creates the “encourage vendors” model; from what I hear Verizon’s explicit goal was to frame the way vendors approached Verizon with offerings. Vendor participation in something that’s supposed to encourage vendors is essential, and that’s why there were seven vendors listed (Cisco, Ericsson, HPE, Intel, Nokia, Red Hat, and Samsung). Verizon aims at open implementation by a community that contributes entire pieces, and so pays a lot of attention to both interfaces and to the ETSI NFV E2E model that created at least a rough (if not totally functional) consensus.
SNRA is what the name suggests, meaning that it’s really about SDN and NFV. While you can definitely provision legacy elements with the model, it seems pretty clear that Verizon is seeing SNRA as deploying lock-step with SDN and NFV and not being prominent where those technologies haven’t reached. Again, I’m not surprised with this given Verizon’s apparent goal of creating an architecture into which vendors can fit their wares. Displacing legacy gear or reducing its differentiation would be a hard sell to many of the contributors on the list.
The scope of both models is set by the need to harness benefits more effectively. One of the issues I’ve raised repeatedly in both SDN and NFV is that deployment depends more on operations improvements than on capital savings. Since neither the OSF nor the ETSI NFV ISG chose to address full-scope operations and the full-service lifecycle in their models, and since the TMF has yet to provide its own approach to operational orchestration, one of the key questions that both Verizon and AT&T will have to address to make their approaches successful is “can this do opex efficiency?” The answer has to start with the relationship between the two architectures and OSS/BSS systems.
In both the ECOMP and SNRA models, infrastructure (including both legacy elements and virtualization-enhanced SDN/NFV elements) is composed into what could fairly be called “service-specific virtual devices” that present a simple model of the service to the OSS/BSS layer. Neither of the approaches propose to modernize OSS/BSS by introducing event-driven concepts or OSS/BSS functional orchestration. In my past characterization of the ways in which service orchestration could be applied, they both operate below the OSS/BSS boundary. While this doesn’t foreclose securing opex benefits, it doesn’t fully address the question of how you’d orchestrate OSS/BSS processes into service operations. I’ll comment on some approaches as we develop this series to cover the specifics of each approach.
We have competing approaches here, and what’s particularly helpful I think is the fact that what they compete on is fundamental to the evolution of networking. One operator is embodying the “go it alone” trend, taking control of its software evolution, subordinating hardware to software, and limiting vendor contributions so they fit into the overall scheme. The other has tried to rehab a vendor-participation process that has broken down in the standards bodies. Verizon realizes that it is very difficult for operators to drive progress alone, and in many areas impossible for them to cooperate outside formal standards groups without risking anti-trust action.
How is this all going so far? Obviously, operators are happy with the AT&T model; Orange is running trials of ECOMP. What may be particularly telling is that the vendors whose chestnuts Verizon may be trying to pull out of the fire aren’t being particularly helpful in promoting the Verizon approach. For example, I have had a number of vendors ask for details on ECOMP and (so far) none have asked for similar details on SNRA.
Vendors have done a generally abysmal job with SDN and NFV at the positioning and benefit-securing level, and they may now be shooting down their last, best, chance to redeem themselves.