Versions Compared

Old Version 24

changes.mady.by.user Scott Blandford

Saved on

compared with

New Version Current

changes.mady.by.user Scott Blandford

Saved on

Key

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

The Auto Scale Out Use Case will impact each of the Projects listed on this page. We also list the requirements for each project to support the Casablanca Scaling Use Case.

Pre-requisites for Auto scaling

  1. VNF must be in Service with the VNF Orchestration Status = Active  and PROV_Status = PROV
  2. The VNF must be onboarded via SDC
    1. TOSCA model should have been distributed
  3. The VNF must be orchestrated via SO

AAI

  1. (This requirement is no longer needed) Implement and develop a new custom query to get the IP Addresses that will be used to communicate to the VF-Module Instance being scaled. The custom query should be generic so it can be used for different configuration actions
  2. Add Topic ID for VNF Controller to VNF instance information

APPC

  1. (Provided in Beijing) For L4-L7 VNFs, process a HealthCheck action from SO via DMaaP
  2. (Provided in Beijing) For L4-L7 VNFs, process a ConfigScaleOut action from SO via DMaaP.  
    1. Receive ConfigScaleOut(VNF_ID, VF_Module_ID)
  3. (This requirement is no longer needed) Retrieve the IP addresses from A&AI for the ConfigScaleOut action  
    1. Obtain Configuration information for new instance from A&AI

CLAMP

  • Ensure CLAMP has access to VF_Module_Name at design time
  • Create Threshold Crossing Alert (TCA) policies for Scaling of vDNS  
  • Create Guard policies for Auto Scale Out

DCAE

  •  Test Support Only

OOF (Not Pursing in R3)

  • OOF will process Homing and license capacity placement request from MSO.

OOF will support additional Policies for Scale Out to check the following:

  • If there is enough capacity in the region or close to the region
  • For the VNF Instance, is the license sufficient to satisfy the configuration requested

Modeling (Not Required)

  • Need to add Controller type to the VNF Model in SDC 

Policy 

  • Create API call to SO with VNFInstanceID and VF_Module_Type as arguments
  • Set up proper Guard Policies
  • Compare number of instances to both Min and Max values
  • Check Prov_Status = PROV


 

SDC

  1. Support a Common Controller communication i.e. common Controller architecture to process LCM actions 
    1. Model new parameters, Controller Cluster and Topic (Channel), in the TOSCA Service Model.  The Controller Cluster and Topic can be defined by geography. Note: Controller Type will Not be used in Casablanca release and going forward. The Controller Cluster  should be one of: APPC, SDNC, VF-C
    2. The Topic (Channel) will be a two (2) way communication
  1. ** CURRENTLY, NO REQUIREMENTS

SDNC

  1. For L1-3 VNFs, process a HealthCheck action from SO via DMaaP
SDNC
  2. Import Scaling changes from APPC so that all configuration changes may be done on VNFs controlled by SDNC
After Resource Assignment for new instance, IP Addresses need to be added to AAI 
  2. Retrieve the IP addresses from A&AI for the ConfigScaleOut action  
    1. Obtain Configuration information for new instance from A&AI

SO

  • Create API for VID and Policy to call that will allow SO to scale a VNFC
  • Create work flow to get all needed information to Scale a VNFC
  • Call API for Homing and capacity checks (Moved to Dublin)

VID

  • Change Manual Scaling Use Case to use the same SO API that Policy is using in Auto Scaling Use Case (Common Actor API)