Provided by Appledore Research
For as long as any of us can remember, fulfillment and assurance were two independent processes, mostly because they were conceived, operated and purchased by separate departments. As Alfred D. Chandler demonstrated in his classic book “Strategy and Structure,” operations and even business structure follow organizational charts and vice-versa. Fulfillment and assurance are no exceptions, with those organizations driving processes and supporting software purchases. While many know that its not ideal, the situation has mostly worked.
Virtualized networks promise agility and OPEX cost reductions, along with other significant benefits. But – a big but — these gains demand highly efficient, hands-off automation. One of the things we learn from control theory – which is one branch of engineering associated closely with real-world automation, is that there must be a single control method – and what we think of as “assurance” is simply an input (feedback) into that method. One method, not two, nor three.
Actually, feedback loops are beautiful things (especially if you’re a nerd). They are simple. Designed properly, they tend to converge, which means they are self-correcting. And, with a single method (loop), there’s effectively no “systems integration”, because there are not two independent systems.
Let’s also think about the practicality of fulfillment, especially in tomorrow’s world where a packet core, or a datacenter full of NFV-I must be shared among hundreds of services and 10,000s of customers. In the old days, we found a free loop, or trunk and “assigned” it to you. Done. Now, we have to figure out where there is sufficient spare capacity, on a statistical basis, to support your needs 99.99% of the time, or whatever the SLA or product requirement says. This is an assurance function, and it precedes the completion of an order. Let’s put that another way, assurance is a contributing function to a successful order. Not only should assurance and fulfillment not be separated, they cannot be.
This gets back to how SDN orchestration can be used to solve both fulfillment and assurance. Automated assurance can be used to detect that assigned bandwidth is no longer sufficient to meet service needs (eg “service path X is getting congested”), and to trigger a remediation effort, complete with all the new data, to rectify the situation (e.g.: “augment service path X by adding another Ethernet port to LAG Y” or “reroute service path X through higher capacity links YZ”). After a service has been instantiated, active assurance becomes a “re-fulfillment” effort – working around, for example, network saturation issues that can put a service at risk.
In our research, Appledore Research Group is witnessing several vendors implement these concept. NOKIA has introduced its Network Service Platform “NSP”, and in fact recently announced enhanced assurance as part of that platform. In a similar concept, but a very different (and often complementary) implementation, Aria Networks provides a controller to perform more complex, but non-real-time calculations – but again based on external, shared orchestration methods. Rather than focus on individual products, take-away these key points: a) suppliers large and small are working toward this common method; b) all are thinking first at the domain level and then aggregating up, and c) all are heavily policy and model driven. All of these are best practices as outlined in our published research.
In the end we still have a fulfillment process, an assurance process, and a capacity expansion process. But for many reasons, these should share many common components, such as common orchestration methods, common Active Inventory, and common live topology. This leaves next-generation assurance to migrate to what it does best – collect data, correlate events, and turn all this underlying data into intelligence. In effect assurance (and Analytics) become the “brains” driving myriad decision from smart fulfillment, to self-healing to self-scaling (capacity expansion) – and other actions outside the scope of this blog.