End-to-end means multiple networks, operators and services – Part 2
Once upon a time — that is, maybe two or three years ago — every service provider would have created a custom solution with no common interfaces and no common architecture. That approach won’t scale, especially not when trying to define and orchestrate multi-carrier services that conform to the Third Network vision.
“Part of what we did to address the complexity was provide a multi-tier view of abstractions,” explained Dr. Mayer. “We have the elements, equipment and level abstraction. That’s where all the complex details are spelled out, at the bottom. On top of that we created this view of sub-networks or clouds or control domains where we are providing connectivity across a specific sub-network cloud from interface to interface.”
He continued, “We had to think how to stitch all that together with the orchestration model which actually provides a view of the end-to-end or as a service concept. End-to-end lies within the single service provider domain. End-to-end also incorporates aspects of partner domains like the access piece of a network, says Alan Zeichick, principal analyst at Camden Associates.
That’s what the orchestration aspect is. So we have a service view abstraction that stitches together the cross-administrative domain pieces of the service. There is also a product view, which is actually what the customer buys. Of course, from the customer’s perspective, a product might consist of multiple services.”
Shahar Steiff of PCCW Global added: “one of the key components of LSO is its non-hierarchical orchestration architecture. Most orchestration frameworks currently in the market are based on a hierarchical approach that culminates, through a hierarchy of controllers, orchestrators and orchestrators-of-orchestrators, towards a single top-level orchestrator that, supposedly, has end to end visibility and control of the entire network.
While this may be a valid approach for a single administrative domain, it does not scale when service is delivered across multiple domains. The delivery of multi-domain services thus must be based on a federated-orchestration approach using east-west interfaces between equal-level independent orchestrators.
The LSO architecture, when accompanied by standardised processes and standardised service definitions, allows such federated orchestration to occur and enables automated multi-domain services.”
Jack Pugaczewski, principal architect, CenturyLink, who contributed to development of the LSO Architecture, summarised why he feels it is important to the industry: “The LSO Architecture provides a clear and concise layered framework from which FCAPS+T/I (Fault, Configuration, Accounting, Performance, Security, Topology and Inventory) APIs can be developed at each layer.
These APIs will be the cornerstone for automated service fulfillment and service assurance of customer MEF services within a single carrier and across multiple operators. The LSO Architecture enables the management of MEF services and network resources management across existing networks, SDN and NFV enable networks, and hybrids.
In addition, the LSO Architecture and Framework interface boundaries simplifies the development of functional specifications for systems development at each layer. This jump starts the development of open source solutions and potential collaboration between standards organisations on common object models.
The end game is the building blocks – APIs, open source which allows the realisation of simplified customer experience with the entire lifecycle of MEF services.”
Strong industry support for the LSO architecture
CENX, CenturyLink and PCCW Global were a few of the many important organisations that contributed to the LSO Reference Architecture. Others included Alcatel-Lucent, AT&T, Avaya, CableLabs, Calix, Ciena, Cisco, Comcast, Ericsson, Huawei, Iconectiv, Iometrix, Oracle, RAD, Sprint, Verizon, and Veryx Technologies.
“We had great involvement across multiple different types of organisations for this project,” said Dr. Mayer. “Service provider participation was essential because they’re the ones that actually have the special needs for it. We had equipment vendors as well as traditional management system vendors and non-traditional management system vendors.”
CENX’s Mr. Purdy added, “It’s quite fascinating. There really is this concept of a service provider with multiple domains, where each domain can be orchestrated and provide a nice abstraction on top. We at CENX are living that every day!
I have been reviewing the Reference Architecture document and providing feedback in the context of how it is really happening by service providers. It has been a very valuable interaction. In addition, there has certainly been some really good analyst feedback on the Reference Architecture, as well as a lot of customer feedback that this document is setting the right direction.”
Shahar Steiff of PCCW Global added: “While a growing number of service providers are able to automate their internal processes and allow customers to order and change services through a portal or through application-awareness, this automation today is still limited to each service provider’s own administrative domain.
The adoption of LSO by multiple service providers, as well as alignment of processes and service definitions, will allow service providers to extend this automation beyond their own domain into their LSO-enabled partners’ domains.”
The Lifecycle Service Orchestration: Reference Architecture and Framework document is available for download from the MEF, and will be the focus of a Workshop and numerous sessions at the MEF’s global networking conference, MEF16, that will be held in Baltimore during Nov. 7-10, 2016
The author of this blog is Alan Zeichick, principal analyst at Camden Associates.
Comment on this article below or via Twitter: @ VanillaPlus OR @jcvplus