You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 29 Next »


STATUS: DRAFT

1. Scope


DESCRIPTION: Service Orchestrator performs orchestration for:
• Service activation requests or changes to an existing service
• Service scaling, optimization, or (migration)
• Controller instantiation
• Capacity management

This flow will focus on instantiation of a Service (first bullet). SO automates the end-to-end service instance provisioning activities. The service instantiation procedure is obtained from the Service Design and Creation (SDC), where service models and designs are created and distributed for consumption by SO. Service instantiation is currently done with GR flows (Generic Resource flows). Also, SO is responsible for the instantiation and release, and subsequent migration and relocation of VNFs in support of overall end-to-end service instantiation, operations and management.

WHEN EXECUTED: After Design Time. After SDC Service CSAR Distribution. (See ARCHCOM: InfoFlow - SDC Service Distribution)

PURPOSE: To instantiate a service designed in Design-time and requested by an operator at the OSS, VID or external API.

Information Model: Main information being used and a reference to the information model. Service name. In the case of VNF-based services: also the Cloud Region (where the VNF has to be deployed if HAS [homing allocation service] is not used in the workflow)

ACTORS:

  • Operations Specialist
  • Deployment and Service Designer

<<Optional: Replace with figure illustrating the scope >> 

2. Pre-Conditions

The preconditions are:

  • (Instantiation/Design Time) PNFD and VNFD have been mapped to ONAP platform data/information model. That is, the onboarded descriptor models (vendor provided) have been mapped onto ONAP platform data & information models that are useable and known to ONAP.
  • SDC contains the verified service and resource descriptor (models). These resource descriptors are provided by the vendor (PNFD and VNFD).
  • Associated resources (PNF, VNF, ANF) used by services have been properly onboarded.
  • Services have been defined in design time, and associated templates, control loops, blueprints have been incorporated into the service CSAR package.
  • SDC has composed the Service Design CSAR package ready for distribution.
  • The Certification Studio has certified the Package ready for distribution
  • The Deployment Studio operator has identified the Service Design CSAR package for distribution.
  • Software images loaded in OpenStack installation, where instantiation will happen (since no S/W image repository). Need to be available in Target Cloud Instances.
  • The User at OSS or VID has knowledge of the Service Model Identifier that they wish to create a service instance of. The Service is seen as available in the catalog.

3. Information Flow

The following diagram shows the SO Service Instantiation Flow:
 SDC Service Distribution-1 VID VID SO SO AAI AAI OOF OOF SERVICE CREATION REQUEST SO/VID API Svc Model ID, Recipe ID 1Service Creation Request INVENTORY RECORD CREATION AAI API 2Inventory Record Creation Request 3Create Inventory Record INVENTORY RECORD 4Inventory Record Creation Response HOMING REQUEST xNF Resources, Service ID 5Homing Assignment Request 6Homing Assignment 7Homing Assignment Response

  1. SERVICE CREATION REQUEST – User at the VID or OSS requests for a Service instance to be created from the available services that could be instantiated. He 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. (Q: Catalog of Services at VID?)

    When you create a Service Model (you give it a human-friendly name) and a UUID is associated with the Service Model. Resources & how they are connected. When you instantiate a Service Model (service instances), they have names and UUIDs generated, you are using UUIDs. When you want an INSTANCE of a service model ONAP is using the UUIDs. There is a catalog of service models & list of service recipes that can be used. (1) Macro W/Fs. Recipes for service deploy (2) Al carte svcs, pic resource deploy manually (3) Macro GR flows use like building blocks to create recipes. Specific to the service (Generic) and GR (generic resource) flows, custom a la carte recipes. Select which recipes to use. Catalog available at VID termind, SDC makes this catalog available. Create it, distribute it, it should then appear in VID. List of service model, can search, button to “Deploy.

  2. SO/A&AI CREATES SERVICE RECORD – SO requests A&AI to create a Service record. SO requests A&AI to create records for the resources (VNFs, PNFs) associated with the service.

  3. A&AI CREATES SERVICE RECORD – A&AI creates the Service Record.

  4. SO/A&AI SERVICE CREATION RESPONSE – A&AI responds to SO with the create Service record completion and status (success/fail)

  5. SO/OOF: HOMING ASSIGNMENT – SO requests for a homing request to OOF for VNFs (and PNFs?). [Damian and I discussed what does homing mean for PNFs, this probably will see evolution from R5+]

  6. OOF: PERFORMS HOMING – OOF performs the Homing function. For VNFs, the concept of “homing” means assigning the VNF to the best “cloud” region to service that VNF. For a PNF, the concept of “homing” would mean finding the best ONAP instance to serve the PNF. Event collection for VNF/PNF pick best DCAE instance and/or controller instance. OOF assigns the VNFs that are part of the service to appropriate cloud locations. OOF queries A&AI for a cloud instance that has the number and type of cloud resources needed and reserves them in A&AI.

  7. SO/OOF: HOMING COMPLETION – OOF responds to the Homing request



 SDC Service Distribution-1 SO SO NFVOrches NFVOrches SDNC SDNC OpenStack OpenStack CLOUD RESOURCE REQUEST Resources API Resources Needed 1Cloud Resources Request 2Assign Cloud Resources VM ID 3Cloud Resources Response NETWORK ASSIGNMENTS SO API 4Network Assignment Request 5Perform Network Assignments AAI Update 6Network Assignments Response INSTANTIATION REQUEST xNF Resources, Service ID 7Instantiation Request 8VNF Instantiations 9Instantiation Response

  1. SO/OPENSTACK: CLOUD RESOURCE REQUEST – SO requests Openstack (Blazer) for a cloud resources request to OOF. OOF = NVF Orchestration. Does OOF do this? Is this not done? MEC instances.

  2. OPENSTACK: ASSIGN CLOUD RESOURCES – Openstack Blazer assigns cloud resources based on the needs of the service. Assignments are balanced against NFV compute resources in each region, what is currently used/reserved and total capability. Compute resources availability to deploy a VM are consider. The NFV-Orchestration is defined in ETSI NFV.  SO can trigger a reservation request. NFV orchestration can create instances of different types. NFV orchestration has a policy. OpenStack Blazer, reservations localized to the cloud instance.

  3. SO/OPENSTACK: CLOUD RESOURCE RESPONSE – Openstack responds with the allocated resources.

  4. SO/SDN-C NETWORK ASSIGNMENTS – SO requests SDN-C to perform the Network Assignments needed by the Service instance. Can a Subnet, Network Port be assigned? (Virtual MAC, IP address), connect to VM. VM > create port > connect to VM.

  5. SDN-C NETWORK ASSIGNMENTS – SDN-C performs Network Assignments needed by the Service instance.

  6. SO/SDN-C NETWORK ASSIGNMENTS – SDN-C responds to SO with the Network Assignments needed by the Service instance and the status (success/fail).

  7. SO/MCLOUD INSTANTIATION REQUEST – SO requests M-Cloud to perform the VNF instantiations needed by the Service instance.

  8. MCLOUD INSTANTIATION REQUEST – MCloud performs VNF instantiations.

  9. SO/MCLOUD INSTANTIATION RESPONSE – MCloud responds to SO with the VNF instantiations needed by the Service instance and the status (success/fail)




Continuation of SO Service Instantiation Flow:
 SDC Service Distribution-1 VID VID SO SO Controller Controller ASSOCIATED RESOURCES Service Instance ID, Configuration information 1Associated Resource Created CONFIGURE & ACTIVATE SERVICE Service Instance ID, Configuration information 2Activate Service 3Configure Associated Resources 4A&AI Updates 5DCAE Monitoring Activated 6Activate Service (State) 7Service Activated USER RESPONSE Service Instance UUID 8Service Creation Response, Inform User

  1. ASSOCIATE RESOURCES WITH SERVICE – Ala 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://wiki.onap.org/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.

  2. 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??)

  3. CONTROLLER: ACTIVATE SERVICE – The controller (SDN-C, SDN-R, VF-C, APP-C) to activate the service.

  4. CONTROLLER: CONFIGURE SERVICE – The controller configures the service, and configures the associated xNF resources.

  5. 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.

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

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

  8. SO/A&AI UPDATE RECORDS – SO updates the appropriate A&AI records with activation information. [What info is saved and in which records: Service vs VNF/PNF??]

  9. USER NOTIFIED - SO notifies service initiator that the service is active.

4. Post Condition

The post-conditions are:

  • Service has an A&AI Service Record Entry.
  • Resources associated with the Service have been successfully given network assignments.
  • Cloud resources have been successfully assigned necessary to support the service
  • Network assignments have been assigned for the service
  • Security assignments have been successfully performed (IAK, RV, CA root cert, CA URL)
  • VNF instantiations have been successfully performed
  • Configurations from Controller to xNFs have been successfully performed.


5. References


  • No labels