Orchestrating GP4L service provisioning

Overview

The goal of orchestrating GP4L service provisioning is to automate the configuration of experiments over the infrastructure of the GP4L experimental testbed. As such, GP4L service provisioning targets an adaptation to GP4L of the work done in the Polish NREN PIONIER network.

As a first step towards this goal, we deploy a virtual twin of the GP4L core network that can be used as a target to validate the service provisioning workflows developed. Using Maat as a source of truth, and using TM Forum APIs for Resource Inventory and Service Inventory, the state of the digital twin is kept as shown in the image below.

In the first phase of GP4L service provisioning, the interface provisioning and the L2 Circuit service provisioning workflows are supported. These workflows are designed to maximize reusability across services, and several tools and platforms are used for this purpose.

Ansible is used for the configuration of GP4L devices. A setup playbook can launch an HTTP API service available in RARE/freertr devices in order to accept subsequent configuration of services via HTTP requests. All Ansible configuration employs Jinja templates for their flexibility in parametrizing said configuration provided by higher orchestration layers. Additionally, the execution of Ansible playbooks is done via GÉANT Lightweight Service Orchestrator (LSO). LSO acts as a proxy that can wait for a given playbook to complete in order to return feedback. This is useful to ensure the smooth execution of service workflows. LSO accepts a JSON file with parameters and vars for Ansible, that eventually the playbook tasks use to fill up Jinja templates. This means that the core functionality can be reused across services.

Finally, Apache Airflow is used as workflow orchestrator, also following the approach taken in the PIONIER network.

As said before, this lab consists on two orchestration workflows. The first one is used to provision network interfaces in order to prepare them for services. The second workflow is used to provision layer-2 circuits across geographically distributed GP4L devices. As such, the interfaces provisioned through the execution of the first workflow can then be used to provision a layer-2 circuit service.

For the interface provisioning, a DAG has been prepared, that contains three main tasks.

1. First the user introduces parameters for the interface to be provisioned, including the device where the interface exists, speed, MTU, and tagging mode (VLAN tagged or untagged).
2. Next, the DAG validates the inputted data and triggers the configuration in the device via LSO.
3. Finally, if the configuration has taken place correctly, the DAG triggers an update of the source of truth in Maat, by submitting an update to the corresponding Interface resource, using schemas aligned with the TMF 639 API.

The following diagram represents the interface provisioning workflow.

For the L2 circuit service provisioning, a DAG has been prepared, that contains three main tasks.

1. First the user introduces parameters for the service, including origin and destination switch and interfaces, and the VLAD ID of each side involved in the L2 circuit.
2. Next, the DAG validates the inputted data and triggers the configuration in the relevant switches via LSO.
3. Finally, if the configuration has taken place correctly, the DAG triggers an update of the source of truth in Maat, by submitting two new Service Attachment Point (SAP) services and a L2 Circuit service, using schemas aligned with the TMF 638 API. The usage state of the interface resources involved in the services are also updated in Maat (TMF 639 API).

The following diagram represents the L2 Circuit service provisioning workflow.