CenturyLink, Ciena, Cisco and other vendors have advanced a new effort related to the MEF 3.0 Transformational Global Services Framework by releasing two new specifications focused on orchestration of MEF 3.0 connectivity services over multiple network technology domains.
Developed within MEF’s LSO (Lifecycle Service Orchestration) Reference Architecture, the standards are Network Resource Management: Information Model (MEF 59) and Network Resource Provisioning: Interface Profile Specification (MEF 60).
MEF said these specifications are important steps toward accelerating the delivery of orchestrated services over automated networks using LSO, SDN and NFV.
MEF’s LSO Reference Architecture (RA) guides agile development of the models, processes, tools, and APIs that will enable orchestration of MEF 3.0 services (e.g., Layer 1, Carrier Ethernet, IP, and SD-WAN) across multiple providers and over multiple network technology domains.
The LSO RA extends the traditional MEF scope related to service modeling to cover a range of operational, orchestration, and network management behaviors, including SDN and NFV paradigms.
“MEF members have been working diligently to develop and demonstrate model-driven ‘North-South’ intra-provider LSO APIs and ‘East-West’ inter-provider LSO APIs that are required to orchestrate MEF 3.0 services,” said Nan Chen, president of the MEF, in a release. “The new specifications enable us to define the critical LSO Presto NRP (Network Resource Provisioning) API for orchestrating services over a mix of underlying network technologies."
MEF 59 focuses on managing resources
CenturyLink, Ciena, Cisco, Coriant, Ericsson, Huawei, Infinera, NEC, and RAD joined Nokia in contributing to the MEF 59 standard.
Supporting the LSO RA, MEF 59 defines the information model to facilitate the orchestration of Carrier Ethernet connectivity services through WAN SDN controllers, OTN subnetwork managers and legacy network management systems.
The MEF NRM model is specified in Papyrus UML and is based on current and developing best network management solutions by ITU-T, ONF, and TM Forum to allow for wider interoperability across multivendor and multitechnology platforms.
Jack Pugaczewski, editor of MEF 60 and distinguished architect for CenturyLink, told FierceTelecom that the new standards aren’t just about developing new APIs or data models.
“The LSO architecture and framework offers a well-defined architecture that’s in place with the components of business application service function control and well- defined interfaces,” Pugaczewski said. “When you have those interfaces and those functional components it becomes easy on where the API development of that interfaces belongs and what you need.”
This could include a mix of older technologies like an element management system or new technologies like an SDN controller or an NFV orchestrator. By having that logical architecture it enables service providers to break elements down to an API and what the API functions are.
“MEF 59-60 are one particular effort at the Presto interface, which is on the orchestration layer or the ICM,” Pugaczewski said. “What we do there is we say how are we going to in an intent-based way take what would come from a Legato interface as a MEF service request and determine that I need one or more domain controllers to meet this request of this MEF service and the corresponding network resources via the NRP API are called one or more domain controllers.”
MEF said this approach also facilitates upcoming work on operations administration and maintenance and OAM and optical transport network (OTN).
Along with the LSO RA, the MEF NRM serves as a basis for the new MEF 60 specification and thus supports the LSO Presto interface.
What was also different about the development of MEF 59-60 was that there was a hybrid approach of doing traditional SDO work and conducting proof of concept events, MEF got immediate feedback on how the specifications work.
“I would say that the work that was done with the model for MEF 59 and MEF 60 really benefitted from that hybrid approach,” Pugaczewski said. “It was an excellent collaboration between SDOs, which in this case was the ONF, and the TAPI model where we saw some excellent results in the software patterns that the TAPI model provides such as connectivity and topology services.”
Standardizing LSO APIs
With MEF 60, members have created a suite of standardized LSO Presto APIs defined in MEF Interface Profile Specifications (IPSs) dealing with network resource provisioning, performance monitoring, and other functions over various technology domains.
MEF 60 is an LSO Presto NRP IPS. The specification provides an abstracted, intent-based solution for activation of—as well as topology retrieval of—network resources in support of MEF-defined services. It's complemented by an enhanced LSO Presto SDK (software development kit) that has been made available to the MEF Developer Community on the MEF GitHub.
“With Presto if you don’t have a common API with a common model then what you end up having is multiple APIs or multiple integration efforts between every vendor,” Pugaczewski said. “By having a common API it’s a win-win for the carrier as well as the vendor because if a vendor has to implement an API for every carrier integrator that requires the cost of professional services.”
Pugaczewski added that the MEF 60 standard can be useful for service providers purchasing wholesale circuits in an out of territory scenario. This would be where a service provider purchases Ethernet to fulfill a business customer service request in a building where the carrier does not have network facilities, a process that’s been traditionally complex.
“It’s a win-win for carriers that interwork with one another to have a common API because otherwise you end up with having to integrate with every other operator,” Pugaczewski said.
So what’s next for the MEF? For the Presto NRP, MEF plans to provide additional support for Layer-1 or OTN-based optical networks.
“In this case you could have an E-Line service that’s provided with 1-10 Gbps Ethernet on the edge, but as you go across the network that could be an OTN-based network,” Pugaczewski said. “By moving to support OTN, you now can activate from an orchestrator the overlay and the underlay, which will provide value to carriers and customers as well.”
This article originally appeared on FierceTelecom.com and can be found here