SONATA Network Service Adaptation

Home / News / SONATA Network Service Adaptation

SONATA Network Service Adaptation
By François KULCZAK from On 31 July 2017  0 Comment

Network services are a combination of application and network functions. They offer an end-to-end process while supporting and securing complex data flows. The SDN revolution is shaking up the network infrastructure, but the complexity of the network services is growing up alongside.

First, the trend of micro-services shapes those functions to their bare core features; this allows more flexibility, but complicates their inner workings and increases the number of manipulated components. Second, a network service is a composition of specialized and differentiated security network functions. Reusing the same configuration across several services may not be adapted, as the SDN transformation focuses on adapting the network and its attached security to the task at hand. Moreover, third-party’s VNFCs (Virtual Network Functions Components) might have an unbalanced level of configuration and customization. Third, NFV services will inherit the on-demand and scaling characteristics from the Cloud, which will increase the complexity of their orchestration and maintenance. Finally, the infrastructure itself may be heterogeneous. It can also be split (as SONATA supports it) across many PoPs.

All these characteristics open new challenges and highlight the necessity of autonomous service adaptation. This adaptation must happen not only at the application level (as in the IaaS context), but it also must take place at the network and network function levels. In the 5G vision, the service must continuously and automatically recompose itself, as it needs to match the current or incoming context. SONATA supports those features with the introduction of FSMs (Function Specific Manager) and SSMs (Service Specific Manager) components.

A Management and Orchestration (MANO) framework is the core of the SONATA Service Platform. Service developers can create and ship plugins in a SONATA service package, beside the application and network components (VNFCs). The SONATA Service Platform deploys and isolates these plugins inside the MANO framework. From there, they are integrated in the inner working of the SONATA Service Platform. Therefore, service developers can participate in the management of the corresponding service and customize its lifecycle.

SONATA supports two kinds of plugins, the SSM and the FSM, which operate at the service and function level respectively. The service developer can implement them using a full-fledged programming language. SONATA provides Python skeletons to quickly bootstrap a SSM or a FSM plugin. A plugin can manage, scale, choose the placement of VNFs, or orchestrate and adapt services. For example, it can request a new topology for a service. These features and this level of power and customization will propel the service developer into the 5G vision.

With a SSM, a service developer can create a process to improve the SLAs of a service. They can do so by moving VNFs between the available PoPs or they could also cut the global cost of a running service by adapting the topology to the resource cost. For example, imagine that a service containing three VNFs is deployed on three separate PoPs and that the service is packaged with a custom placement SSM:

  • If the quality of the link between PoP2 and PoP3 degrades too much, then the SONATA MANO framework will generate alerts.
  • The placement SSM registers itself to the corresponding alert topics, so those alerts will trigger it. By looking at the situation, the SSM may decide to move one VNF from PoP3 to PoP2 in a rolling fashion. To do so, it needs to trigger a scaling operation by sending a crafted message to the MANO framework.
  • The placement SSM will receive a message to compute the VNF placement for the requested scaling. The message contains the Network Service Descriptor (NSD), the Virtual Function Descriptors (VNFDs) and a filtered map of the available resources for all PoPs. The descriptors detail the architecture of the service and its functions. The placement SSM can also request the actual instantiation map by fetching the service and function records (NSR, VNFR). Given the map of all available resources in the PoPs, the placement SSM can attach the new VNFs in PoP2. It will then send the placement decision to the SONATA MANO framework.
  • The SONATA Service Platform will instantiate and configure the new VNF. Then the placement SSM can start a scaling down of the service by explicitly removing the VNF in Pop3 and updating the forwarding graph.

A configuration SSM/FSM can adapt a service or function to create a fast path for data. It can identify some service clients that are trustworthy. After this identification, the configuration SSM can move their data to a fast path to lower the service latency.

A set of authentication, protection and classification components could create a VNF. This security oriented VNF would protect end users from external threats:

  • The VNF is configured by default to send all end users through the heavy but secure upper path.
  • After an end-user’s data has been classified as harmless, one of the VNFC informs the configuration FSM.
  • The configuration FSM can reconfigure the front-end firewall. It injects fast rules targeting the end-user data and reroutes the traffic to another interface, directly to the VNF output.

In this setup, the FSM switches the data corresponding to its trust in the user. But the same principle could be applied to dynamically prioritize critical users.

SONATA allows this flexibility by packaging configuration, placement and orchestration behaviors within the service package. The plugins have a tight integration to a MANO framework. The service developer can fully customize them to the service. They can automatically adapt the application, the network components and links at run-time. The plugin can also be changed at runtime. Those features will help developers and system integrators to enter the SDN era.

REFERENCES: