There are a lot of ways to get to the network of the future, but I think they all share one common concept. Services are in the eye of the beholder, meaning buyer, and so all services should be viewed as abstractions that define the connectivity and SLA they offer but are realized based on operator policies and resource versus service topologies. In the modeling sense this is the “intent model” I’ve blogged about, and in the service sense it’s Network-as-a-Service or NaaS.
SDN and NFV have focused on what might be called “revolutionary NaaS”, meaning the specification of new technologies that would change infrastructure in a fundamental way. Last year, the Metro Ethernet Forum embarked on what it called the “Third Network”, and this defines “evolutionary NaaS”. I noted it at the time but didn’t cover the details as they emerged because it wasn’t clear where the Third Network fit. Today, with SDN and NFV groping for a business case, evolutionary NaaS sounds a lot better. Some operators are looking at the approach again, so it’s worth taking some time now to have a look ourselves.
According to the MEF, the Third Network “combines the on-demand agility and ubiquity of the Internet with the performance and security assurances of Carrier Ethernet 2.0 (CE 2.0). The Third Network will also enable services between not only physical service endpoints used today, such as Ethernet ports (UNIs), but also virtual service endpoints running on a blade server in the cloud to connect to Virtual Machines (VMs) or Virtual Network Functions (VNFs).” The notion is actually somewhat broader, and in their white paper the MEF makes it clear that the Third Network could be used to create ad hoc connections even over or supplementing the Internet, for individuals.
Taking this goal/mission set as a starting point, I’d say that the MEF is describing a kind of virtual overlay that can connect physical ports, virtual ports, and IP (sockets?) and utilize as underlayment a broad combination of Ethernet, IP, SDN, and NFV elements. The Third Network would be realized through a combination of operations/management elements that would orchestrate the cooperation of lower-level elements, and gateways that would provide for linkage among those underlayment pieces.
I mentioned orchestration above, and the MEF says that “embracing complete Lifecycle Service Orchestration” is the key to realizing the Third Network’s potential. LSO is envisioned not as a singular “orchestrator” but as a hierarchy, with the operator who owns the retail relationship running a top-level LSO instance that then communicates with the LSO instances of the underlayment pieces.
This, in my view, is very much like the notion of an intent model hierarchy of the kind I’ve been blogging about. Each “service” that an LSO level is working on is decomposed by it into lower-level things (real deployment or other subordinate LSOs) and any LSO levels above will integrate it as a subordinate resource. There’s an SLA and connection points and an implied service description, again like an intent model of NaaS. That’s good, of course, because NaaS is what this is supposed to be.
It doesn’t take a lot of imagination to see that the Third Network could be the “orchestrator of orchestrators” or higher-level process that unifies SDN, NFV, and legacy technology and also operator, vendor, and administrative domains. The LSO white paper shows this graphically, in fact. From that, one might reasonably ask whether LSO has the potential of being that unifying concept that I’ve said SDN and NFV both need. Yes…and no.
The Third Network’s approach is the approach that both the NFV ISG and the ONF should have taken to describe their own management and orchestration strategies. That a service is made up of a hierarchy of models (intent models in my terminology) should have been fundamental, but it wasn’t. The good news is that the Third Network now creates such a hierarchy, but the problem is first that it doesn’t go low enough, and second that it doesn’t go high enough.
The MEF can (and does) define LSO as a top-level service lifecycle orchestrator, and it can (and does) subordinate SDN and NFV implementations and legacy management to it. But it can’t retroject the service model hierarchy into these other standards processes. That means that in order for LSO to define a complete orchestration model for a complex service made up of all those technology pieces, it has to model the service entirely and pass only the bottom-level elements to the other standards’ implementations. Otherwise whatever limits in terms of service structure those other standards had, they still have.
It’s possible that the MEF could take LSO to that level. Their diagrams, after all, show LSOs talking to LSOs in a hierarchy, and there’s no reason why one of those subordinate LSOs might not itself be top of a hierarchy. But it’s a lot more complicated to do that, and it extends the work way beyond the normal scope of a body like the MEF.
There’s a similar issue at the top, where the LSO connects with the OSS/BSS. The diagrams the MEF provide show the LSO below the OSS/BSS, meaning that it would have to look to operations systems like a “virtual device”. That’s not something unique to the Third Network approach; most NFV implementations and SDN implementations try to emulate a device to tie to management systems, but it can create issues.
A service lifecycle starts with service creation and ends with sustaining an operational service for a customer. While there are events in a service lifecycle that have no direct OSS/BSS impact (a rerouting of traffic to correct congestion that threatens an SLA is one), many events do require operations system interaction. The service lifecycle, after all, has to live where services live, which is really in the OSS/BSS.
It’s not clear to me from the Third Network material just how the MEF believes it could address the above/below orchestration points. There is value in the kind of orchestration the MEF proposed, even if they don’t address the holistic orchestration model, because for business services like Carrier Ethernet, VLANs, and VPNs we have established management models. However, if somebody does develop a full orchestration model, then the Third Network functions would duplicate some of the functions of that broader model. It might then have to be treated as a “domain” to be integrated with OSS/BSS, SDN, and NFV orchestration through federation techniques.
LSO is good in concept, but it’s still in concept and so I can’t really say where the concept will go. The MEF white papers outline a highly credible approach and even indicate the specific information models and specifications they plan to develop. Even with a limited-scope target, this is going to be a formidable task for them. It would be facilitated, of course, by a broad notion of how new-age operations and management looked from the real top, which is above current operations systems.
We really need a true vision of top-down services for next-gen networks. You can see that vendors and operators are working on this and that, pieces of technology or standards that have real utility but only in a broad and operationalizable context that we’re still groping to identify. The main signals of real progress so far are in some of the TMF Catalyst demonstrations, which for the first time are starting to look at both the service realization below and the operations modernization above. Hopefully the vendors involved will push their efforts earnestly, because there’s a lot riding on the results.