Detailed Network Slice Instantiation Flow
This page tries to describe with more details the instantiation procedure by checking the steps of each one of the 6 phases:
- Network Slice Request
- Network Services Placement
- Network Slice Networks Creation
- Network Slice Services Deployment
- WIM Enforcement (ONLY if the network slice isntantiation is splitted among multiple VIMs)
- Network Slice Notification
The user sends a request (step 1) to instantiate a slice (based on an available NSTd) from the Portal which is received and forwarded (step 2) by the Gatekeeper towards de the Network Slice Manager (slicer). When the slicer receives the request, it processes the request to create a NSIr object based on the NSTd within the incoming information (at this moment, the next phases start in parallel to the current one). Once the object is saved in the database, the slicer answers back to the Gatekeeper (and this, to the portal) that the request has been accepted and is being carried on (steps 4,5).
While the first phase is in process, the slicer (main processor) starts a parallel sub-processor (from now on, lcm-slicer) in which the whole instantiation lifecycle management of the slice is being managed. Initially, the lcm-slicer has to check if the VIM (or VIMS) registered in the Sonata SP have enough resources to instantiate all the services within the desired network slice. To do this, the lcm-slicer requests the information to the Gatekeeper and this to the Infrastructure Abstraction (IA) component (step 6,7). The IA sends back (forwarded by th eGatekeeper) all the current information (steps 8,9) and the lcm-slicer decides (stp 10) either it is possible to deploy the slice (enough available resources) and where (all in one VIM or different VIMS if one has no enough resources). If there are no esources at all, then the lcm-slice notifies the GTK with an error message and updates the NSIr with an error status and the information.
If there are enought resources, the lcm-slicer assigns an id to each one fo the networks defined within the NSIr (step 11) and requests to the IA (through the Gatekeeper) to create all the necessary networks into the right VIM (steps 12 - 15).
Once the networks are all completed and ready to be used, the lcm-slicer will start to send a request to the Gatekeepr to deploy (into the right VIM) each one of the network services defined in the NSIr. Contrary to the networks, here each NS has its own request (steps 16 - 24) to allow an easier track of each service status due to their individual deployment time. Then, the Gatekeeper forwards (step 18) each request to the MANO component which si in charge of the service lifcycle management and together with the IA to stitch the NSs into the right network (steps 19 - 22). As previously said, each NS has it own deployment time and so, updated information (regarding the status) might come at any moment. While this is happenning, the lcm-slicer (the sub-processor in charge of the slice lifcycle) is waiting until it has all the services with a status "Instantiated". For this condition to be fulfilled, update messages for each NS will come (steps 25 - 29) and once all NS have their status as "Instantiated", then the Network Slice is ready.
With this requests is possible to interconnect two different VIMs and so, if NSs of a NSI are deployed in different VIMs, the NSi si still interconnected and keeps its unity.
Once the whole process is done (networks created, services deployed) and the status of the NSIr is "Instatiated", we can consider the network slice completed and so, the slicer can finally notify the Gatekeeper (step 30) about it, so this component can finish its internal procedures (closing connections, etc.).