Platform Operation view: management of OSM as Manager Platform

Interaction with Common Services for platform operation

Authentication

Following the recommendation of the standards (GS NFV-SOL005 – V2.4.1 Network Functions Virtualisation (NFV) Release 2; Protocols and Data Models; RESTful protocols specification for the Os-Ma-nfvo Reference Point), the APIs offered by OSM can only be accessed by authorized consumers. Therefore, OSM has the ability to authenticate users against a user database and to authorize them to do a set of operations in the context of a project.

Authentication/authorization schemes in OSM can be standalone or integrated with external common services (company’s user databases and systems). Specifically, in the case of an integrated/brownfield deployment with other components, OSM can interact with authentication/authorization servers using the protocols/mechanisms exposed by them; this interaction could vary, depending on the capabilities offered by the external systems from a simple user authentication to a user and project-based authentication and authorization.

It must be noted that the workflow for user and project management might differ depending on the case. In a standalone/greenfield case, users and projects can be created and managed directly via API. In the integrated/brownfield case, the management of users and projects might be stored in the organization’s user databases and systems.

Logging

OSM can export its logs to external systems using the protocols/mechanisms exposed by them. Logs can include:

System information, relevant to know the status of the servers hosting OSM and the relevant processes
Operational information. Each API call should be properly logged by the system

Data exportation

OSM provides the appropriate mechanisms to expose metrics and relevant data to be consumed by external systems (e.g. data lakes). The simplest mechanism for this purpose is a messaging bus where multiple consumers can be connected, read the information from the bus and export it to any external system.

The minimal information expected to reach the previous bus would be:

NF metrics (either coming from the NFVI/VIM or from the VNF itself)
NF and NS alarms (either coming from the NFVI/VIM or from the VNF itself)

Nothing prevents that API calls and LCM events might also reach that bus and feed external systems.

Management of OSM

Authentication and Authorization Management

From the perspective of the real operation, OSM allows the partitioning of OSM resources into different projects (also known as tenants), providing a separate space for:

A given set of accessible NF packages
A given set of accessible NS packages
A given set of accessible NST
The set of running NS
The set of running Network Slices (NSI)
Authorized VIM accounts.
Authorized WIM accounts.

Some of the previous resources (e.g. NF packages, NS packages and Network Slices) might be declared public (available for all projects) or available for a list of them. However, instances of Network Servers and Network Slices will only belong to one project.

In addition, not all operations are expected to be allowed to all users. OSM allows the definition of roles, with the set of privileges or access rights allowed from the whole set of operations:

CRUD operations over a NF package
CRUD operations over a NS package
CRUD operations over NST – see next section
CRUD operations over Network Services (instances)
CRUD operations over Network Slices (instances) – see next section
Advanced LCM of Network Services (e.g. scale out/in)
Day-2 operations over Network Services
Day-2 operations over Network Slices
CRUD operations over VIM accounts
CRUD operations over WIM accounts
System operations (user, project and role mgmt. in a standalone/greenfield configuration)

Users of the system belong at least to one project, and each user might have potentially different roles depending on the project. This is what is commonly known as a role-based access control (RBAC) on a per-project and per-user basis, i.e. for each project a user belongs to, the user will have a role with specific access rights. It must be noted that RBAC mechanisms typically involve the definition of admin/root roles (with all privileges) and admin users, authorized in all projects with the admin/root role.

The way to enforce that the actual privileges are preserved is typically through the NBI. For REST APIs, this is typically achieved through token-based mechanisms, which means that:

The client platforms of OSM are authenticated and authorized on a project basis, and get a token based on the role in the project. That token identifies the set privileges for subsequent operations.
Client platforms will make API calls using that token. Based on the authorization rights identified by the token, some operations will be allowed and others forbidden.

Bootstrap and addition of boundary conditions

The creation of Network Services and Network Slice Instances requires OSM to be previously fed with enough information to deploy and operate them. The life cycle management of some of these inputs (NF Packages, NS Packages and NS Templates) is fully managed by OSM. However, there are some inputs whose lifecycle is managed by other service platforms:

VIM accounts. In order to be able to deploy in a specific datacenter managed by a VIM, OSM needs to know and store the access information and credentials of the VIM account to be used. Those credentials are created by a VIM administrator, and should grant OSM sufficient rights to perform CRUD operations on flavors, networks, images, volumes and instances. Those VIM accounts need to be added to the NSO, previously to any deployment in that datacenter.
Management networks visible from the VIM account. Each VNF deployed by OSM needs to be accessible for configuration and operation, and this means that at least one of the VNF interfaces will have to be connected to a management network with an IP address that is reachable from OSM. This requires not only the creation of the network in the VIM, but also guaranteeing that the network is usable from the VIM account that will be added to OSM, and is reachable via IP from OSM.
SDN controller accounts and relevant port mapping info for SDN Assist. In those cases where OSM has to manage underlay networks on a datacenter through an SDN controller (SDN Assist), OSM needs to know the access information and credentials to reach the SDN controller and perform CRUD operations related to underlay networks. The setup of the SDN controller and its accounts, and its connection to the datacenter infrastructure needs to happen in a provisioning phase, typically by an administrator of the datacenter. Then, the SDN controller access information and credentials need to be added to OSM and associated to a specific VIM prior to any deployment in the datacenter controlled by that VIM. In addition, OSM will need to know the mapping between compute node interfaces, e.g. the tuple (compute node, physical interface), and SDN ports, e.g. the tuple (switch, port). That mapping will guarantee the coherence of the operations from OSM to the VIMs and SDN controllers.
WIM accounts and relevant port mapping info. In order to be able to deploy inter-datacenter or inter-VIM NS/NSI, OSM will have to contact potentially one or several WIMs, and it will need to know the access information and credentials of the WIM account to be used. Those credentials are created by a WIM administrator, and should provide OSM enough rights to perform CRUD operations on inter-DC/inter-VIM networks. Those WIM accounts need to be added to OSM, prior to any multi-site deployment that may require the creation of inter-DC/inter-VIM networks. In addition, OSM will need to know the mapping between external DC/VIM ports, e.g. the tuple (VIM, swich, port) and the transport service point, e.g. the tuple (transport switch, port), which will guarantee the coherence of operations from OSM to the VIMs and WIMs.
PDUs. In those cases where we want to define NS packages or NST consisting of PNF packages or HNF packages, OSM is instructed about the available PDUs, i.e. the network appliances that will be the building blocks of those PNF and HNF packages. We will need to provide the management IP address of those PDUs, their type (so that they can be managed as a pool if appropriate), their location (VIM) and the physical connections to the site (e.g. switch and port of the infrastructure where the PDU is connected).
PNFs and external networks. In those cases where the Network Service (or Network Slice) needs to be connected to existing networks or PNFs that are not part of the Network Service itself, we need to feed OSM with appropriate information to connect those entities to our Network Service. One possibility among others would be adding those entities in OSM as external networks of a VIM so that they could be mapped to a Virtual Link in the Network Service at instantiation time. In addition, if OSM controls the creation of underlay networks, it will be necessary to provide the datacenter switch and port where the PNF or external network is attached.

Catalogs and shared databases

In a standalone/greenfield configuration, without the possibility of relying on an external catalogue service, OSM is able to manage the catalogue of the different resources used to build, create and operate Network Service and Slices:

Physical Deployment Units
Network Function packages (VNF, PNF, HNF)
Network Service packages
Network Slice Templates
Network Functions: instances of running VNFs, HNFs or PNFs
Network Services: instances of running NS
Network Slice Instances
VIM accounts
SDN controller accounts
WIM accounts

The catalogue of Network Services and Network Slice Instances also stores the history of operations over that NS/NSI.

Regarding the technologies for storing those catalogues, OSM may support different types back-end options for brownfield/integrated setups.

Platform logs and alams

In addition to the capability to export the logs to external systems, OSM can store internally the following logs:

System information, relevant to know the status of the servers hosting OSM and the relevant processes
Operational information. Each API call should be properly logged by the system

Log rotation policies are expected to be configurable and they should follow the log rotation company’s policies.

Security

OSM has to provide the following security-related functionalities with respect to its northbound interface:

Authentication and authorized access from the clients.
Proper isolation of catalogues per project. In some cases, as mentioned before, some of the catalogue resources could be shared between projects.
Secured NBI based on TLS

In addition, OSM provides mechanisms to hinder malicious access that could compromise both the system and the data stored by the system. As an example, the internal architecture of OSM is prepared to follow common security practices in commercial distributions and installers, so that there are:

No passwords stored in text files
No default users and passwords in internal databases
Proper encryption of the account information fed to the system (e.g. passwords from VIM accounts)
No processes running as root user directly in the system host.
Secured and authenticated communication between internal modules only if they run in different servers.