Usage and examples
As an example, let us take into consideration the "infrastructure.service.prepare", the "infrastructure.function.deploy", the "infrastructure.service.chain.configure" and the "infrastructure.service.wan.configure" calls documented in the API reference. This needs several steps to be completed:
- In the first place, the IA-NBI receives the call "infrastructure.service.prepare", and forward to the correct compute VIM Wrapper(s). The compute VIM Wrapper(s) receives the call and must prepare the environment in the selected PoP(s) in order to host the deployment. This step includes pre-load (if needed) the VM images used by the service in the relevant VIM image repository. After this step, the compute VIM Wrapper(s) notify the IA-NBI, witch join the reply(s) and forward through the NBI.
- In the second place, the IA-NBI receives the call(s) "infrastructure.function.deploy", and forward to the correct compute VIM Wrapper(s). The compute VIM Wrapper(s) receives the call(s) and the VNFD that comes with the request can be passed to the translation and deployment process. The actual deployment phase happens asynchronously under the hood of the compute VIM wrapper, which notifies the IA-NBI when the process is completed, witch forward all the replys(s) separately through the NBI.
- In the third place, once the service has been successfully deployed by the compute vim wrapper(s),the IA-NBI receives the call "infrastructure.service.chain.configure", and forward to the correct network VIM Wrapper(s). The network VIM Wrapper(s) receives the call(s), and enforce the network configuration based on the Service Forwarding Graph (SFG) contained in the request.
- In the fourth place, the service instance is ready to be used, so the WAN can be configured to route the relevant traffic to/through them. The IA-NBI receives the call "infrastructure.service.wan.configure", and forward to the correct network WIM Wrapper(s). The WIM Wrapper(s) receives the call(s), with the ordered list of the involved PoPs and the identifier of the traffic flow to be redirected, and will set up the WAN so to redirect traffic that was previously flowing from the server to the users, through the involved NFVI-PoP.
To better understand how the combination of these wrapper and models can be used to ensure the foreseen functionalities we will navigate through an example. The following figure shows the initial state of a NFVI composed by two PoP, both using their instance of OpenStack heat as a compute VIM (VIM1 and VIM2 in the figure), and an instance of our OVS SFC agent as Network VIM (for simplicity, we omit the compute VIM operation from the picture).
The SLM receives a request to instantiate a service composed by three VNFs:
- VNF1 is composed by two VNFC
- VNF2 and VNF3 are composed both by a single VNFC.
- Traffic is flowing from a server to users, but after the NS deployment the traffic coming from the server needs to be processed in order by VNF1 VNF2 and VNF3 before reaching users.
- The SONATA placement executive decided that VNF1 and VNF2 should be deployed on VIM1 and VNF3 should be deployed on VIM2.
The SLM sends a first request to the IA to prepare the selected VIMs to host the deployment. The IA-NBI will receive this request and forward the call to the compute vim wrapper (Heat Wrapper) in order to create in the OpenStack VIMs the virtual networks and sub-networks to connect the VNFs that will be deployed in the future. Each VIM creates four Data networks, which will be used to exchange user data between VNFs and VNFCs, and a management network, that will be used for management and monitoring traffic. To do this, the Heat Wrapper will create a stack with just this five networks and will connect the management network to the external gateway of the OpenStack tenant, in order to ensure external connectivity to the virtual machines through the management network. This is depicted in the top-left sub-figure, where bold dotted lines between the IA and the VIMs represent the interface through which a given operation is carried out.
After this process is completed the SLM triggers the FLM to handle the deployment of each VNF separately. In turn, The FLM sends a request for VNF1 to be deployed in VIM 1 to the IA. The IA-NBI receives this request and forward call to VIM1 compute wrapper (Heat Wrapper) to deploy the function. The Heat Wrapper receives the call, translates the VNFD sent, connecting each VNFC connection point to the data network or to the management network depending on the connection point type specified in the descriptor (internal->data; external/public->management). Then, it retrieves the stack template from the Heat controller and updates it with the new resources. After this process is completed, the deployment will look as the top-right sub-figure. The same procedure is repeated for VNF2 and VNF3, as depicted in the bottom-left and bottom-right sub-figures. Before the actual instantiation, the IA-NBI could also call the storage/compute wrapper of each PoP in order to load the needed VDU images into the image repository of the VIM for the future deployment. We omitted this step from the pictures for simplicity.
After all the VNFs have been deployed, the control goes back to the SLM, which issues another request to the IA to configure the VNF chain(s). Also in this case, the IA-NBI receives the request and forward the call to the network VIM wrapper (Ovs Wrapper) of PoP1 and PoP2 to serve it. The Ovs Wrapper will receive the NS forwarding graphs, together with the NSR and the VNFRs of the deployed service instance, so to be able to compute the the service graph, and configure it through the OVS SFC agent they wrap. The following figure shows the status of the system after this procedure is completed. The red arrows represent forwarding/routing rules configured in the Neutron controlled through the SFC agent.
After these steps, the service instance is ready to be used, so the WAN can be configured to route the relevant traffic to/through them. Therefore, the WIM Wrappers are called to deal with the configuration of the underlying WIM(s). Also in this case, the configuration is kept hidden by a relevant WIM wrapper, that receives the configuration parameters for the WAN, and enforces it with the specific technology it is wrapping.
The SLM calls for the WAN to be configured, so that user traffic could be processed by the new NS instance. This time, the IA-NBI receives the request and forward the call to the relevant WIM wrapper (VTN Wrapper). The VTN Wrapper receives the request with the ordered list of the involved PoPs and the identifier of the traffic flow to be redirected, and will set up the WAN so to redirect traffic that was previously flowing from the server to the users, through the involved NFVI-PoP (Green numbered arrows in the figure).
With the proposed model explained in the previous section, we also provide to the MANO framework the level of control needed to change the status of a service/function lifecycle. When the MANO framework wants to put a service instance in a paused state it can leverage the IA functions, by sending a call to deconfigure the WAN, so that there's no connectivity disruption between the server and the user (steps 2 and 3 in the figure), and to pause the service instance (steps 4 and 5 in the figure). The call will be fetched by the WIM Wrapper and mapped into a request to the WIM to disable the WAN forwarding rules set for the given service instance. The status after this calls is depicted in the following figure.
Resuming a service follows the inverse procedure. First, each VIM Wrapper is called in turn by the IA-NBI to resume the execution of the relevant VNFs. Then, the IA-NBI requests the WIM Wrapper to reactivate the WAN forwarding rules set for the given service instance.