Lifecycle Service Orchestration, or LSO, provides open and interoperable automation of management operations over the entire lifecycle of Layer 2 and Layer 3 Connectivity Services as well as Cloud applications and VNFs. The importance of the word “Lifecycle” should not be missed. LSO goes well beyond the initial setup of these services. It includes all the aspects of Service Assurance through the full lifecycle of these services, from when they are initially conceived until they are eventually disconnected.
An article by Alan Zeichick, Principal Analyst at Camden Associates.
Lifecycle Service Orchestration: Reference Architecture and Framework (MEF 55). This 57-page document from the MEF is the essential, foundational specification for agile end-to-end communications services that work within one carrier’s network or can span the globe linking multiple service providers.
What’s included in the document? Everything from design to fulfillment, from control to testing, and everything in-between. That spans quality management, billing and usage, security, service performance, service failure resolution, analytics and policy capabilities, and change management over all the network domains that require coordinated management and control in order to deliver and assure the service.
The Reference Architecture, written in the first half of 2016, describes the management and control domains and entities that enable cooperative LSO capabilities for a host of Connectivity Services and Cloud Applications. Indeed, the LSO architecture and framework enables automated management and control of end-to-end Services that span multiple provider domains. For example, a service provider may use LSO to define how external operators can manage, control and add value to its end-to-end services — and the Reference Architecture document explains how to make that work in a standard interoperable way.
According to Chris Purdy, Chief Technology Officer of CENX, the secret sauce of Lifecycle Service Orchestration is encapsulated in the word “orchestration,” where Connectivity Services are orchestrated across all internal and external network domains from one or more network operators.
“Within each provider domain, the infrastructure may be implemented with WAN technologies, as well as NFV and SDN,” Mr. Purdy explains. “Not only does this dramatically decrease the time to establish and modify the characteristics of the connectivity service, it also assures the overall service quality and security for these services.”
Shahar Steiff, AVP New-Technology at PCCW Global, adds that LSO pertains to the three fundamental building blocks of automation: “Lifecycle is the process through which one or more operators turn a customer requirement into an order, deliver and assure a service, and bill for a service. Service is the combination of computational, storage and connectivity resources to address the customer’s requirement. Orchestration describes the entities and elements involved in the delivery of said service through its lifecycle – and the relations and information flows between them. By combining those three elements into the unified LSO approach we can achieve automation, which in turn allows network programmability that yields responsiveness and the ability to enrich the portfolio of services offered by service providers.
Why Service Providers Need the LSO Reference Architecture
It all starts with the Third Network vision for agile, dynamic and assured services, explains Mr. Purdy. The Third Network vision combines the best attributes of the low cost, flexible and rapid provisioning of public Internet services, with the high reliability, business-class security and predictability of services like Carrier Ethernet 2.0.
“The very beginning of LSO was the creation of the whole concept of the Third Network,” says Mr. Purdy. “Remember, MEF was very much Ethernet-centric, but there was a recognition that when it came to the data plane and the control plane, everything was pretty much settled. The biggest problem with Ethernet was the operational challenges. How do we make it significantly more dynamic? How do we make it more ubiquitous? How do we allow the interconnect between parties? That is essentially what the problem space was, which grew into the whole Third Network vision.”
From there, he explains, it became apparent that in order to allow for rapid and automated provisioning, management, operations and billing of services between different carriers, there needed to be consistent definitions of those services, so that the carriers could speak the same language. Those definitions needed to span the entire lifecycle of a service, from ordering and quoting, to setup, billing, problem resolution, and tear-down. Once those lifecycle definitions were in place, carriers could then use software to orchestrate business and technical processes. Thus: Lifecycle Service Orchestration, and a Reference Architecture to spell out the details in a standard, vendor-neutral way.
Dr. Andrew Mayer, MEF LSO Chief Architect, laid out a common LSO scenario:
“So you have the main service provider and you have the customer who is buying the service. But then you have other partner domains involved that may be providing access pieces or specific network functionality, which are service components of the end-to-end service. The main service provider needs an orchestration mechanism to coordinate all those different pieces, and orchestrate them into a single view on behalf of the customer. In order to achieve dynamic services you really need to have that coordinated view.
CENX’s Purdy adds: “That’s a start — from which the situation becomes even more complex. Even within that main service provider there are multiple different network domains, as well as services across those network domains. Those services may not have been defined in a consistent manner. However, those network domains are now all starting to become virtualized, with some of them under SDN (Software Defined Networks) control. So we are seeing the complexity associated with actually setting up and managing the full lifecycle of these services. It is very, very complex and challenging.”
“And that’s the opportunity created by the LSO Reference Architecture,” continues Dr. Mayer. “We can now actually migrate from our legacy environment to emerging SDN controllers and NFV orchestrators. But no one is going to throw their entire investment away and just say ‘everything is SDN now.’ It’s going to be a lengthy migration process. LSO is essential to that migration because it allows the coexistence of all of those diverse technologies together in one orchestrated view so that carriers have a transition strategy by simply gluing the pieces together using standards-based definitions.”
End-to-End Means Multiple Networks, Operators and Services
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,” explains 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 continues, “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. 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 adds: “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 standardized processes and standardized 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, summarized 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 organizations on common object models.
The end game is the building blocks – APIs, open source which allows the realization 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 organizations 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 organizations for this project,” says 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 adds, “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 adds: “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.