Versions Compared

Old Version 41

changes.mady.by.user Benjamin Cheung

Saved on

compared with

New Version Current

changes.mady.by.user Byung-Woo Jun

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. SERVICE CREATION REQUEST – User at the VID CLIENT or OSS requests for a Service instance to be created from the available services that could be instantiated. The user picks the service and finds the corresponding identifier. The user identifies the Service Model ID (what to deploy) and Service Recipe ID (how deploy). There is one Identifier per service that they wish to make an instance of. There is a catalog of available to Services that the user can select from in VID.

    When the user wishes to create a Service Model, it is given a human-friendly name and a UUID is associated with the Service Model. Resources & how they are connected to the service are defined. When the user instantiates Service Model (service instances), they are given names and UUIDs are generated. When an INSTANCE of a service model is to be created, ONAP uses the UUIDs. There is a catalog of service models & list of service recipes that can be used. The user can select: (1) Macro Work-Flows and Recipes for service deploy, or (2) A la carte services: the user deploys resources manually or, (3) Macro Generic Resource flows which use "building blocks" to create recipes. The user can pick Specific Service (Generic) and GR (generic resource) flows, or custom a la carte recipes. The user Selects which recipes to use. There is a Catalog available at VID terminal and SDC makes this catalog available. The user can Create a service, distribute the service, and then it appears VID. The user sees a List of service model, he can search, and then Deploy.


         CLIENT - The client that invokes this flow can be one of four types of clients. These components are described at this wiki: ARC Service Orchestrator Component Description - Dublin

  1. VID - ONAP GUI
  2. UUI - User Interface
  3. CLI - Command Line Interface
  4. External API / NBI - External API (North bound interface)

         INFORMATION PASSED - The user inputs the Service Model ID and associated input parameters, and Service Recipe ID (the BPMN Workflow ID). The service recipe ID is distributed with the SDC Service CSAR package and is received by SO.

INVENTORY RECORD CREATION

...

ASSOCIATE RESOURCE WITH SERVICE

1718. ASSOCIATE RESOURCES WITH SERVICE – A la carte Create resource. Macro W/F needs service instance ID associate resource w/ Service Instance. When instantiate PNF service (PNF name) subscribe ID. Update instance in A&AI. Create a relation object where service instance ID & PNF instance ID. Relation modeled service instance + resources. Resource and can see which services it is used. VNFs create service have UUID of service instance. At creation of VNF create the Instance object.

https://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/VNF+and+PNF+Building+Block+Strategy

CPE, BBS, starts when you startup the PNF. Cloud environment creates a VNF. Registered/discovered PNF, build a homing service PNF. How will this work w/ 5G RAN. BBS U/C, registering the Box, customer starting up the box. Waiting for registration event. When receive the registration configure the network, additionalfield has domain-specific information to calculate best configuration of network to configure the PNF. After homing, SO creates a resource level sub-flow w/ a globally unique UUID in A&AI. In that that in sub-flow there is a correlation done with VES. The configuration that takes place happen in the resource level sub-flows. Svc instantion, correlation ID in A&AI. VES w/ correlation ID SO does the correlation (Plug n Plug).

ACTIVATE RESOURCES

1819. SO/CONTROLLER: ACTIVATE SERVICE REQUEST – SO requests the controller (SDN-C, SDN-R, VF-C, APP-C) to activate the service. (Where does SO get data to configure a service??). SO determines the order in which to instantiate the xNF resources. Right now SO does networks first then VNFs. Eventually this should be model-driven from TOSCA. Heirarchical resource creation & nested services.

1920. CONTROLLER: ACTIVATE xNF – The controller (SDN-C, SDN-R, VF-C, APP-C) to activate the xNF resources associated with the service.

2021. CONTROLLER: CONFIGURE xNF – The controller configures the service, and configures the associated xNF resources associated with the service.

2122. A&AI Published to DMaaP - A&AI publishes on DMaaP that a new service is active, How does it know? A change in status? #1 when dealing with VNFs, the contents of A&AI created when doing something in VID. Create a VNF in a service. Record in A&AI is created immediately. (no VMs are deployed). Same for VF modules. Get back info from OpenStack, HEAT. States are then updated. #2 BBS event CPEauthenticated. BBS & Service, send registration w/ SO & Controller configure networking. Sending CPE authenticated (event means running, active, successfully configured). Go to service instance mark it as “activated”. Confirm end-user can use the services. W/F specific to services. Refer to generic building blocks. TOSCA Modeling of nodes. TOSCA orchestrator has plug-ins for clouds. Cloud specific parameters, unable to create a node in AWS/Azure. A&AI can be configured to “announce” a state change of a service.

2223. DCAE LISTENING - DCAE is listening for a new service notifications and starts to monitor the service.

2324. SO/CONTROLLER: ACTIVATE SERVICE RESPONSE – The controller responds with the Service configuration, and responds to the activation service request back to SO.

2425. SO/A&AI UPDATE RECORDS – SO updates the appropriate A&AI records with activation information.

USER NOTIFIED

2526. USER NOTIFIED - SO notifies service initiator that the service is active. In this example flow, it would be the user at the VID who gets informed that the Service is available and active.

...