If you have followed our work, you will already know that the SONATA project has worked closely with OSM almost since the project started.
OSM is an ETSI-hosted project to develop an Open Source NFV MANO (Management and Orchestration) software stack aligned with the ETSI NFV standards. OSM recently announced its Release THREE which reaches a level of maturity both in the supported features and in the robustness of the code. It includes SONATA’s emulator, as part of the DevOps environment, with our service validation tool planned for inclusion in the next release.
SONATA is also playing a central role in a White Paper that OSM is currently writing. It will capture some of the points that have been learnt from implementing the NFV architecture, interfaces and information models. This blog provides a preview of some of the key points. We hope that these will be considered by the ETSI NFV ISG as it develops its next iteration of the NFV standards.
In its current Release OSM has made a couple of architectural decisions about how it implements the ETSI NFV architecture:
• It splits the NFV Orchestrator (NFVO) between two components: a Network Services Orchestrator (NSO) and a Resources Orchestrator (RO);
• It implements a generic VNF Manager (VNFM) as an integral component of OSM.
OSM has implemented the architecture successfully. Whilst thinking about the next steps for the OSM work, we realised that there are several scenarios that we’d like to support more naturally than is currently possible.
The first type of scenario is where the operator wants to cooperate with another operator to deliver the network service. For instance, it may devolve provision of the infrastructure, or of a specialist VNF, to another operator. A similar example is where an operator constructs its services by using several major platforms, each of which is supplied by a different vendor with its own orchestrator. The implication is that we need an architecture that allows us to orchestrate orchestrators.
Secondly, an operator would like to be able to modify the internal operation of a running network service with zero or minimal interruption to it. For instance, it may need to modify the chain of VNFs or alter the firewall’s configuration.
Another type of scenario involves modification to a network service, say ‘video delivery’. The internal operation of the service may vary according to the specific device type, content source and so on – hence the network service may consist of an initial firewall that steers a request into the appropriate chain of VNFs. If the NS is modified in-life (perhaps to handle a new type of mobile device or to add a new feature like copyright detection), then the NS should be able to automatically make the necessary change (say to the firewall’s configuration or to the topology of the VNF-chain) with zero or minimal interruption to a running NS.
Motivated by these scenarios, we believe that the OSM and ETSI NFV should target the following (linked) objectives in its next round of work:
• The network service should be presented as a single entity, even where it is constructed of sub network services;
• Another way of putting this is that network services are recursive, meaning they can be built from other network services in hierarchical fashion;
• The northbound API needs to be parsimonious, meaning that it includes only what is necessary and all that is sufficient;
• This API should be client-server style.
Presenting the network service (NS) through the northbound interface as a single coherent entity in terms of control of its configuration, capacity, fault and performance has the critical benefit that in-life changes usually do not need to be exposed northbound. This seems critical for automation, as it allows internal changes to be made without having to check with some unspecified system above the NS. The current ETSI NFV standard for the northbound interface of the NSO do not take this approach, as it exposes the component VNFs and VLs for in-life control.
This approach also enables a recursive architecture, meaning that the operator can sub-contract provision of part of the service to a ‘lower’ service provider, who in turn may arrange for some of the service it provides to be delivered by a ‘yet-lower’ SP (and so on). The advantages of such an approach are commercial and technical: it has clear lines of responsibility, allows flexibility in service provision and only a single, standardised API is needed.
Specifying an interface parsimoniously makes implementations easier to realise and more likely to be interoperable. Taking the latter point, if a specification is insufficient, then the implementer needs to make additions sufficient to achieve proper operation of the overall system, and each implementer is likely to make a different choice. For instance, the ETSI specification for fault and performance management (SOL005) includes an operation ‘subscribe to a monitor’ but doesn’t include details of what the monitor actually monitors and what parameters are used.
In the SONATA project, the development of our Pilots is helping us to explore some of these issues, and we are leading the OSM activity to publish a Whitepaper about “Experience with NFV architecture, interfaces and information models”.