Page History

...

1. Decomposition

   The first function is the request decomposition : essentially deriving all the required actions for this specific macro flow. 

   This step is executed every time the service recipe leverages the 'main' building block - WorkflowActionBWorkflowActionBB. 

   draw.io Diagram
   border true viewerToolbar true fitWindow false diagramName SO Building Block simpleViewer false width diagramWidth 815 revision 3

   
   

2. Homing

   The second function will be the homing of the service and resources, although for now not all macro flows implement the homing step.

   Homing consists of determining 'where' to place the service and all its resources, leveraging different models (through the OOF framework) based on various data points (location, inventory data, resource availability, business rules, etc.)

   draw.io Diagram
   border true viewerToolbar true fitWindow false diagramName SO Building Block - Home simpleViewer false width diagramWidth 815 revision 3

3. Assignment

   The third step is to perform assignment. Assignment will be performed per the orchestration plan - and will start from the service-level, then iterating through the various resources contained within the service.

   Assignment can involve different systems, business logic (policies) or other ONAP components in order to derive automatically what the service inputs or resource attributes/properties values will end up being.

   For example: for a 'management_ip' property on a specific VNF component, representing the management interface address, the system may have to reach out to an IPAM system, pulling information from a specific subnet (either rules-based, leveraging a database such as the controller data store, or provided through input). The ONAP Controller Design Studio (CDS) initiative implements an exhaustive framework to tackle this (through data dictionary, controller blueprints or other means as it evolves).

   These assigned values will be stored in the service context, inside the controller's data store (MDSAL). These can be leveraged at any time afterwards - this replaces the legacy preload function.

   
   

   draw.io Diagram
   border true viewerToolbar true fitWindow false diagramName SO Building Block - Assignment simpleViewer false width diagramWidth 815 revision 3

   
   

4. Creation

   The fourth function is the service creation - which, when executed by a Macro request, would perform the 'single click' actions required to bring up a service and all its resources.

   This applies mostly to VNFs and ANFs, but isn't applicable to PNFs for obvious reasons. It will spin up the VM/Containers in the NFVI, and provide basic device configuration in order to have an operational, manageable VNF - but not yet into the traffic path.

   
   

   draw.io Diagram
   border true viewerToolbar true fitWindow false diagramName SO Building Block - Create simpleViewer false width diagramWidth 815 revision 3

5. Configuration

   The fifth function is the configuration of the device - essentially applying service configuration or application type configuration to the device so it can become operational. 

   This is done involving the right controllers, and again leverages the service & resource context stored in the controller data store, the directed graphs and/or Controller Design Studio blueprints artifacts (which can include DGs, code, etc.). It will then transformed all the assigned values into configuration payload for the device, using the right protocol (Netconf/Restconf or just Rest APIs), and when triggered through CDS Blueprints will use Velocity templating for transformation/mapping. This applies to PNFs or VNFs - it is purely network device configuration. If any aspect of the configuration needs to be represented in the inventory, it will perform such updates.

   
   

   draw.io Diagram
   border true viewerToolbar true fitWindow false diagramName SO Building Block - Configure simpleViewer false width diagramWidth 815 revision 3

   
   

6. Activation

   The last function is activation of the service - which is bringing the device in the 'real' network traffic. It can be separate from the configuration so that you can fully configure the device to be operational, and then start steering traffic or attaching the device to the rest of the network afterwards. After this step the device should be considered 'live'. It also updates the device state in the inventory accordingly.
   
   

   draw.io Diagram
   border true viewerToolbar true fitWindow false diagramName SO Building Block - Activate simpleViewer false width diagramWidth 846 revision 3

   
   
   
   

...