WIM Adaptor Usage
This section continues the deployment example documented in Vim-Adaptor example section of this documentation. 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-Adaptor sub-module is 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 WIM adaptor receives the request and calls the relevant WIM wrapper, passing it the ordered list of the involved PoPs and the identifier of the traffic flow to be redirected. The VTN WIM 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 adaptor to the relevant 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.
