OSM Integration Guidelines

Once OSM functionality and management have been throughly described, it is worth a recap of the strategies tham may be followed in order to integrate OSM into a global NFV/Network architecture based on a service platform approach and understand the expected interaction with other platform’s services and a reference set of pre-existing common management and auxiliary services.

Reference Architecture of Service Platforms and Common Management

In order to conduct the exercise, in our example we will take as starting point the service platform presented during the discussion of OSM Scope and Functionality and we will add a tentative set of auxiliary services and tools for joint management of the service platforms which will be taken as reference during the rest of the chapter:

OSM in Service Platform architecture with Common Management

Based on the Service Platform view thoroughly described in the discussion about OSM’s scope and functionality:

OSM as Network Service Orchestrator is in charge of controlling the lifecycle of Network Services and Network Slices offered on demand as a service northbound.
There is a number of VIMs that work as managers of Virtual Infrastructure Platforms. They would expose the reference point Or-Vi northbound to provide IaaS on demand. This reference point would be accessible for OSM to obtain any IaaS needed to compose and manage the NS/NSI. In cases where a given VIM where unable to provide underlay connectivity, it might be possible to follow the SDN Assist approach, where OSM will work with an augmented VIM API, composed of a vanilla VIM API and an SDNC API.
Likewise, there would be a set of WIM(s) that would work as managers of SW-Defined Networks. The WIMs would expose the reference point Or-Wi northbound to provide connectivity as a service among the VIMs (even if they required inter-datacenter connections). This reference point would be accessible for OSM to serve to the NS/NSI creation and lifecycle.

It must be noted that a proper connection with these service interfaces is, strictly speaking, the only integration required to allow OSM to be completely functional and work normally.

In addition to these well-known interfaces, the sample architecture incorporates a set of well-known auxiliary services and tools for joint management of the service platforms, which we can classify into different categories based on their nature:

Common services. These functions offer basic functionalities, available for all the Service Platforms that may require them, which are intended to offer a common context easily accessible to all of them:
- Identity. This service eases the management of user identities that can be shared across the different platforms with a well-known protocol (e.g. LDAP). In the context of API calls, this service typically works as a common service callable by the RBAC (role based access control) subsystem of each platform prior to any operation that requires issuing a token.
- Single Sign On (SSO). This service is intended to provide a context after logging that is common across different web portals available in a portal collection, so that authentication in one of them can be trusted by the others.
- PKI. A PKI infrastructure would facilitate the management of the different certificates as well as providing a common root source of trust for the local environment. This role is essential, among other purposes, to give client platforms means to recognize and trust the available serving platforms in a dynamic fashion.
- DNS. A local name resolution service facilitates the use of common fully qualified domain names (FQDN) across the platforms, so that components and API endpoints can be easily referred by a name understandable by all the platforms.
O&M. Collection of tools coming from the different platforms to ease their respective O&M operations and control their lifecycle, including the own platform setup process. One typical example are installers and lifecycle environments that come with different OpenStack distros.
Backends. These functions are intended to ease the treatment of different types of data (permanent or volatile) that are generated by the platforms, so that it can be conveniently aggregated, filtered and correlated in a single point and also ease recurrent housekeeping tasks (e.g. replication), which can be conveniently centralized. Typically, these types of backends include a logs backend, an alarms backend and a metrics backend. Alarms and metrics backends can be used by the platforms to inject alarms and metrics related both to the platform itself or to the service objects that it offers on demand, so that they can be referred afterwads. On the other hand, logs and alarms backends might share the same type of backend technology in practice if the ingestion mechanisms can be normalized. On the contrary, the metrics backend might require a faster type of technology, such as a Time Series Database (TSBD).
Web portals and wizards. In order to ease some common operation tasks or gain a human-friendly/real-time view of the state of the platform and its components, there might be a set of tools of web-based portals that will facilitate such common interactions and might access both the service APIs and/or their respective O&M components. Into this category, we may typically find:
- Dashboards. Intended to provide a global view of the state, either per platform or per global states that can be aggregated and/or filtered (e.g. alarms). Graphical visualization of topologies, templates and objects is a common feature, as well as the listing of the different catalogs and backend data, or various CRUD operations over them. These dashboards are usually capable of working as means to invoke on the demand the services offered by the respective platforms, requiring access to the corresponding service northbound APIs.
- Wizards. In some cases, it is convenient to coordinate complex O&M operations that might involve more than one platform or which might benefit from a guided step-by-step process to minimize potential errors. Sometimes the roles of dashboard and wizard can be found bundled into the same tool (e.g Horizon).

It must also be noted that, although these auxiliary and common services are not strictly required to set up and operate the platform, are highly convenient to ease integration and troubleshooting across platforms, so it is a good practice to leverage on them for production setups, and hence we will consider them in these integration guidelines.

Integration points

Taking as starting point the sample architecture described above, the following picture summarizes which integration points from the ones described above are relevant from OSM’s perspective and might require a careful consideration and proper identification in the target environment:

OSM integration points

(DNS is ommitted, as it is self-explanatory).

Service view (northbound and southbound)

VIM(s)

To proceed with this integration, the following checks are recommended:

Check if the VIM(s) to be used belong to VIM families already supported by OSM (otherwise a new VIM plugin might be required).
Obtain the respective service endopoints of the VIM(s).
Obtain accounts and tenants per VIM with the required permissions and privileges to perform all NSO operations.
Check if there is a management network (sometimes called OAM network) in the VIM to attach the management interfaces of the VNFs and which is reachable from outside by OSM. Othewise, create it.
If some VIMs were unable to create underlay connections intra-VIM, consider for those VIMs the use of and SDN Assist configuration. In those cases:
- Check if the SDN Controller(s) are connected to a fabric that is properly configured to perform those intra-VIM underlay connections. If so, obtain the proper port mapping.
- Check if the SDN Controller(s) to be used belong to an SDNC family already supported by OSM (otherwise a new SDNC plugin might be required).
- Obtain the respective service endopoints of the SDNC(s).
- Obtain accounts and tenants per SDNC with the required permissions and privileges.

Once these checks are made and the proper information is gathered, the integration would be completed by the mere addition of these boundary conditions via one of the regular procedures in OSM (GUI, CLI, API). In this case, this action would mean the addition of VIM accounts (‘targets’), including credentials, API endpoint, name of management networks, etc. Whenever required, the VIM account would also include the rest of the information required for SDN Assist.

In case there were some PDUs (or PNFs) which needed to be considered in an initial setup, they would be added to OSM via this same procedure in OSM, providing their management IP addresses, their type (if they should be pooled), their VIM of reference and the physical connections to the site (e.g. switch and port of the infrastructure where the PDU is connected).

WIM(s)

To proceed with this integration, the following checks are recommended:

Check if the WIM(s) to be used belong to WIM families already supported by OSM (otherwise a new WIM plugin might be required).
Obtain the respective service endopoints of the WIM(s).
Obtain accounts and tenants per WIM with the required privileges to perform all NSO operations.
Learn 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).

Once these checks are made and the proper information is gathered, the integration would be completed by the mere addition of these boundary conditions via one of the regular procedures in OSM (GUI, CLI, API). In this case, this action would mean the addition of WIM accounts and set of mappings.

OSS/BSS

OSM’s NBI should be accessible from the OSS and BSS platforms. In addition, at least an user and tenant in OSM with sufficient privileges would need to be created to be used by the respective OSS/BSS platforms.

Common auxiliary services and tools

Common services consumed

If properly instructed, OSM can use existing available common services in order to minimize the provisioning time and improve the coordination with the rest of platforms in the environment. These kinds of platforms can be successfully leveraged by OSM:

User database. OSM’s RBAC can be leverage on an external user database via well-known protocols (e.g. LDAP) to support the user authentication during the RBAC phase.
Single Sign On Server (SSO). OSM’s web GUI can work in coordination with other pre-existing web portals sharing authentication via SSO, so that login/logout info is common across them.
Public Key Infrastructure (PKI). OSM by default validates the authenticity of the endpoints of any platform it interacts with (VIMs, WIMs). In order to ease the setup for thus purpose, OSM may leverage on a pre-existing PKI to validate the autenticity of the endopoints.

Backends for OSM’s outputs

OSM produces and manages a large set of relevant information related to:

Events and states in the Network Services and Network Slices and their components.
Information related to its internal events as manager function.

OSM feed this information regularly to three types of events:

Log entries, which can be fed to a central log collector.
Alarms and other types of events, which can be fed to a central alarm collector.
Likewise, there are a number of metrics related to the NS/NSI and OSM as manager function which can be fed to a metrics collector.

O&M tools

OSM’s installer (community-based or commercial) and companion OSM’s O&M tools should be deployed in the same architectural region (i.e. with the same restrictions, security and access rules) as the rest of O&M tools of the architecture.

GUI and dashboard for alarms, logs and metrics

OSM’s web-based GUI can be added to a pre-existing collection of web portals (i.e. with the same restrictions, security and access rules), only by granting access to OSM’s NBI and the common SSO service.

Likewise, it is also possible to include OSM’s dashboard for alarms, logs and metrics in the collection of web portals provided it has proper access granted to the approrpiate backends as well as the SSO service.