“What I’m suggesting is that we define services in a series of hierarchical modeling steps, with each step based on an intent model that offers a from-the-consumer-side abstraction of the service/feature being defined. For network services and features, we could assume the model had a standard structure, which defined FUNCTIONAL-PROPERTIES for the model, and INTERFACES that allow for connection of models or to users. The FUNCTIONAL-PROPERTIES would always include an SLA to describe performance and availability.
As I noted in the earlier blog, you can build basic connection services with three broad models—the point-to-point (LINE), multipoint (LAN), and multicast (TREE). A bit of deeper thinking would show that there could be two kinds of TREEs, the M-TREE that’s true multicast and the L-TREE that’s a load-balance point. You could divide other connection service models too, if needed.
For more complicated features, I proposed two additional models, the IN-LINE model for a service that sits across a data path (firewall is the classic example) and the ON-LINE model for a service that attaches like it’s an endpoint, as DNS would.
INTERFACEs are the glue for all of this. Depending on the functional model of the service we might have a single class of interface (“ENDPOINT” on a LAN) or we might have multiple classes (“SENDER” and “RECEIVER” on multicast TREEs). Connection services connect endpoints so you’d have one for every endpoint you wanted to connect, and you might also have Network-to-Network Interface (NNI) points to connect subsets of a service that was divided by implementation or administrative boundaries.
Given this setup, we can relate the process of selling or building a service to the specific model elements.”
Tom Nolle in a recent post.
Tom’s blog resonates with me, but I’m biased because I’ve been spruiking a similarly modularised approach to Telco for years. Call me Mr Oversimplification, but I believe that this approach is the only possible way that telcos can make the efficiency gains required to support the agility that their customers expect and their shareholders need. If current network tech doesn’t support this objective, then we need to come up with a solution that does.
We have a tendency to build bespoke solutions for almost every customer when with a bit of clever design, we could offer much more repeatable, templated solutions in a majority of customer service scenarios. Templating / automation becomes even more urgent in the highly transient SDN / NFV networks of the future so intent networking becomes essential. I’m still a little bemused that we maintain piles of legacy baggage when almost everything converges onto IP these days.
Software pre-build constructs like containerisation actually provide the potential for telcos to take templated service offerings beyond network services and offer the type of business enablement solutions that we discussed were missing in the “Peak Telco” set of blogs earlier this week.
I believe that OSS has been burdened with a reputation of failing to deliver as a result of too much complexity. Some of that complexity we bring upon ourselves, but a majority of the complexity is shovelled into the funnel long before it reaches a bottleneck at OSS implementation teams.
But with SDN and NFV, we potentially hold a stronger position of influence than in the past. They are software-driven networks, which implies that they rely on software (ie OSS) to realise operational benefits. If the Telco industry is to gain the efficiencies it yearns for from virtualised networks, it can only occur if we insist that the complexity is reduced at the top of the funnel.
This is “Intent OSS” in three words – simplification, abstraction and standardisation.Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email