Euro telco standards wonks publish third iteration of open source orchestrator
ETSI goes MANO et MANO et MANO for better NFV
The European Telecommunications Standards Institute (ETSI) has published the third release of OSM, its open source management and orchestration (MANO) stack for network function virtualisation.
Key features in this release include a new admin user security model, shared projects, and expanded service assurance and monitoring capabilities.
The role-based access model recognises that once it's out of the laboratory, an orchestrator like ETSI's MANO needs a team rather than an individual to run it.
The tool can automate tasks such as spinning up virtual network functions (VNFs); designing, deploying and shutting down network services; adding new data centres and more. To deal with this, admins can now define different roles mapped to these functions, with different privileges.
Shared projects in this release include another security-related access control concept.
Projects group VNF descriptors, network service descriptors, network service instances, and virtualised infrastructure managers (VIMs, which define individual data centres in a network).
In shared projects, role-based access controls let an admin apply consistent access to these groupings.
As the white paper describing the new tool [PDF] explains: “Each user is associated with one or more projects and each user has one or more roles on each project. The role is system-wide and is defined based on permissions on API endpoints.
Project definitions enable “more flexibility in grouping access to resources than if OSM allowed a VIM tenant view to permeate up the MANO stack.”
OSM's service monitoring capabilities received a lot of work between Release TWO and Release THREE. As the announcement stated, the enhancements “allow the orchestrator to act on events and metrics gathered from VNFs and infrastructures, in a technology-agnostic manner. Other features such as anti-affinity rules as well as explicit port ordering and device role tagging facilitate VNF deployments, availability and resiliency.”
The release added an experimental monitoring module that collects metrics and alarms from VMware, Amazon CloudWatch, and OpenStack.
Release THREE metric collection
|Metric||Unit||VMware support||AWS CloudWatch support||OpenStack support|
|Disk read latency||ms||Yes||No||No|
|Disk write latency||ms||Yes||No||No|
|Total disk reads||#||No||Yes||Yes|
|Total disk writes||#||No||Yes||Yes|
|Disk read bytes||Bytes, B/sec||No||Yes||Yes|
|Disk write bytes||Bytes, B/sec||No||Yes||Yes|
Release THREE alarm collection
|Alarm (over threshold)||VMware support||AWS CloudWatch support||OpenStack support|
|Disk read latency||Yes||No||No|
|Disk write latency||Yes||No||No|
|Total disk reads||No||Yes||Yes|
|Total disk writes||No||Yes||Yes|
|Disk read bytes||No||Yes||Yes|
|Disk write bytes||No||Yes||Yes|
Container restart capabilities were extended in Release THREE to improve resiliency, and now include maintaining components' state externally to those components. That way, state can be preserved across restarts. ®
Sponsored: Becoming a Pragmatic Security Leader