-
Notifications
You must be signed in to change notification settings - Fork 13
Service and Function Specific Managers
The 5GTANGO MANO Framework is customizable on a per service/VNF basis. This means that the MANO internal workflows, associated to the supported requests (instantiate, scale, migrate and terminate) can be changed for a single service or VNF. This is done through specific managers. A specific manager is associated to a single network service (service specific manager (SSM)) or VNF (function specific manager (FSM)), and contains instructions which customize the MANO Framework behavior when dealing with this network service or VNF. These instructions are defined as code, and need to be formatted in accordance with the MANO Framework API. A specific manager needs to consume the MANO Framework RabbitMQ message bus, as it is used for all MANO communications. Furthermore, since all MANO Framework components are Docker containers, a specific manager also needs to be packaged as a Docker container. To assist developers in creating and testing specific managers, tng-sdk-sm can be used.
There are currently three supported SSM actions (placement, configure and state), and four supported FSM actions (start, stop, configure and state). To inform the MANO Framework that you have a specific manager for any of these actions, the specific manager should be referenced in either the NSD (for SSMs) or VNFD (for FSMs), together with the action, as follows
service_specific_managers:
- id: foobar_ssm
description: "An foobar SSM."
image: <path to docker image>
options:
- key: "type"
value: "configure"
- key: "type"
value: "state"
function_specific_managers:
- id: foobar_fsm
description: "An foobar FSM."
image: <path to docker image>
options:
- key: "type"
value: "start"
- key: "type"
value: "configure"
Once the MANO instantiates a service or a VNF with a descriptor extended like this, it will download the specific manager image and start it. Once again, it is advised to follow the steps in tng-sdk-sm to create specific managers, as they auto-connect to the MANO when started. More information regarding the onboarding and registration process can be found here. At the appropriate moment during workflow execution, the MANO will contact the running specific manager with the request to execute the event it is customizing.
Further down, you can find API descriptions for the request and expected response for each of the supported specific manager events.
All requests and responses are made by posting messages on the RabbitMQ broker. The topic for all messages related to an SSM is generic.ssm.<ssm_uuid>, and generic.fsm.<fsm_uuid> for an FSM. Each FSM/SSM communicates with the MANO through a virtual host, to ensure isolation.
All messages need a header with the following properties:
-
app_id: to indicate the sender of the message -
correlation_id: an id to identify the message
All payloads are and should be yaml formatted. Each request payload contains either a ssm_type or fsm_type key. The associated value indicates which event is being requested with this request.
The SSM placement event performs the mapping of the VNFs and virtual links on the available resources, instead of the MANO Framework. This can be used in cases where a service requires a specific placement algorithm to ensure a good QoS, which can't be obtained by the generic placement algorithm used in the MANO Framework.
An example of a request can be found here
The response should look like
error: null | <error message>
mapping:
du:
<vdu1 uuid>: <vim_uuid>
<vdu2 uuid>: <vim_uuid>
<vdu3 uuid>: <vim_uuid>
vl:
<vl id>:
vim_id:
- <vim uuid>
<vl id>:
vim_id:
- <vim uuid>
The SSM configure event prepares for FSM configuration events. It indicates for which VNF an FSM configuration event should be triggered, and what the payload it receives should look like.
An example of a request can be found here
The response should look like
vnf:
- configure:
payload: <optional payload for the VNF FSM configure event. If not provided, default payload will be injected>
trigger: <bool, should the VNF FSM configure event be triggered or not>
id: <VNF uuid>
The SSM state event is used during the migration workflow. If state is being extracted from the VNF that is destroyed, and afterwards injected in the new VNF, this SSM state event will have to opportunity to manipulate the state in between, when it belongs to the MANO. This can be used to change the format, enrich, etc.
An example of a request can be found here
The response should look like
status: 'COMPLETED' | 'ERROR'
error: null | <error message>
content: <the resulting state, any format>
This FSM is triggered directly after the VNF is booted. It should contain any action that is needed to make a VNF operational after it is started.
An example of a request can be found here
The response should look like
status: 'COMPLETED' | 'ERROR'
error: null | <error message>
envs: <a list of key value pairs, in case the VNF is container based, to be injected as env variables>
The FSM stop event is triggered right before a VNF is destroyed. This event should be used to perform any final action on the VNF (e.g. extract some state).
An example of a request can be found here
The response should look like
status: 'COMPLETED' | 'ERROR'
error: null | <error message>
The FSM configure event is used to configure VNFs throughout there life cycle. It is typically triggered from a configuration SSM.
The request can have various formats. The configuration SSM that triggered this FSM event can customise the payload of the request. If it is not customised, it will look as described here
The response should look like
status: 'COMPLETED' | 'ERROR'
error: null | <error message>
envs: <a list of key value pairs, in case the VNF is container based, to be injected as env variables>
The FSM state event is triggered when a state related action is needed with regard to a VNF. Two such actions are possible: inject and extract. This action is specified in the request payload with the action key. In a state extract event, the state should be extracted from the VNF and sent back to the MANO Framework. IN a state inect event, the state received through the request should be injected in the VNF.
An example of a request can be found here and here
The response should look like
status: 'COMPLETED' | 'ERROR'
error: null | <error message>
persist: <optional, should contain the state in case of an extract action.>