Streaming services orchestration using post-boot network services configuration framework

Описание: A post-boot network services configuration system offers an OpenAPI swagger, using a REST API for a third-party interaction. The third party could be an NFV Convergence Layer, an end-user or the OSS component. Thanks to the use of OpenAPI swagger, the post-boot network services configuration system is platform-independent and easy to use. For each Network Service Descriptor (NSD), it offers a list of functionalities, in a standardized JSON format using OpenAPI swagger, that could be explored either by the OSS layer or NFV Convergence Layer. Then, accordingly, different configuration instructions could be effected by consuming the well-defined and developed API end-points. In order to enable the scalability of the proposed framework, besides OpenAPI swagger, RabbitMQ, Ansible, and Celery software have been leveraged in the development of the platform. Moreover, the post-boot network services configuration system supports multiple ETSI-NFV compliant administrative cloud domains. In fact, the proposed framework is able to communicate simultaneously with multiple OSM to instantiate and configure the different network services in an efficient manner.

This video shows how the Post-boot network services configuration system is able to horizontally scale a video streaming application, which could in fact be any other application. In this demo, we show how this component is able to make the horizontal scaling of streaming service within one cloud, easily extensible to multiple cloud domains. We used two different NSDs: the first NSD consists of one VNF streamer while the second one consists of a load balancer VNF that can be configured to accept multiple load-balancing policies. Initially, we call the post-boot network services configuration system to deploy one streamer using the first NSD and a web server (i.e., alternatively any third-party application), such as NFV Convergence Layer. The deployed streamer starts serving different clients.

After a while, the intelligent Algorithm at the NFV Convergence Layer detects that the number of users and their requests have increased enormously and could have a negative impact on the QoE perceived by the different UEs. To mimic this process, using a web browser, we list all possible actions that can be offered by the platform, and we found that we can make horizontal scaling by adding a load balancer and multiple streamers. As a result, spawning additional streamer instances has become inevitable. Similarly, this task could be triggered by NFV Convergence Layer. Hence, we decided to horizontally scale up the streaming service using three streaming VNFs instead of one. In this case, we communicated through the REST API to our post-boot network services configuration system to create two extra streaming servers and a load balancer in addition to the already running streamer. After instantiating the additional servers, the post-boot network services configuration system manages to connect both the new and older VNFs together in a smart way as a single network service. The newly instantiated servers could be running at the same or different clouds. After the instantiation of the different streamers and the load balancer, our post-boot network services configuration system automatically configures the four VNFs to work in a unified and harmonic manner. It configures the load balancer to use the weights 1, 4, and 9, respectively, when distributing the loads on each streaming server. In order to make this process in a transparent manner to the end-users, our post-boot network services configuration system assigns the same IP address of streamer to the load balancer. This means that there is no need to inform the users about the new IP address or making any changes in DNS server.