Skip to end of metadata
Go to start of metadata

Beijing Release Update (Jan 24, 2018) - Manual Scale Out has been approved for the Beijing Release.  Auto scaling is being planned for Casablanca.  The work flows for Auto Scaling are still being actively developed.


This Use Case was originally written as a guide for VNF Providers.  The goal was to augment the VNF Requirements and Guidelines and to give context to how a VNF should handle a life-cycle event such as scaling. However, this same use case may be very useful in the coordination of all the ONAP components for orchestrating this basic life-cycle event.

Use Case Descriptions

Manual Scale Out – This is a first step towards auto-scaling and will be useful beyond the development of auto-scaling.  This involves Operations triggering a scaling event through VID.  The scaling event will be sent to SO to orchestrate the instantiation of a new VNFC.  APPC will then need to finalize the configuration and Healthcheck of the new instance before putting it into service.

Auto Scale Out – This will be a closed loop process that will use telemetry from the VNF to determine if a new instance of a VNFC is needed.  If a scaling policy is triggered by the telemetry then a scaling event is sent to the SO for orchestration of the new VNFC.  Once the VNFC is built APPC will take over configuration and Healthcheck before placing the new instance into service.

Scale In - Scale In is generally more complicated than Scale Out.  Scaling In requires moving traffic off of an instance of a VNFC.  Since many VNFCs are stateful, moving traffic requires either waiting for existing flows to end (This could be a very long time - up to weeks) or moving the state of the instance along with the flows (This is non-trivial).  For this reason most of our work so far has focused on Scale Out.  We recognize that Scale In is just as important and it will be the next phase of work.

The following diagram shows how what we have done on each of these use cases:


S3P Impacts

Manual Scale Out and Auto Scale Out are automated processes that will help bypass many manual operations steps for scaling VNFs.  Therefore this cannot be treated as most ONAP components are treated from a S3P point of view.

Scalability – Manual and Auto Scale Out will be a major step in allowing VNFs to easily scale and use only the resources that are required for the current demand.  Scale out use cases should also be exercised in parallel to determine how many scale out operations can be done simultaneously.

Stability – As part of initial tests, both scale out use cases will need to be aggressively exercised in varied conditions to ensure the processes work and are resilient to failure.

Security – New instances of the VNF(C) should be tested from a security point of view to ensure there are no vulnerabilities.

Performance – the scale out use cases will need to be measured to determine the length of time it takes to do a single scale out operation.  This will likely vary greatly amonst different VNF types and therefore conducting the tests across multiple VNFs would result in better measurements.  There might also be significant differences based on process changes.  Experimentation might be the best way to determine the most efficient process to use for scale out.

Platform Impacts

Manual Scale Out will impact VID, A&AI, SO, APPC and maybe MultiCloud

Auto Scale Out will impact SO, A&AI, APPC, CLAMP, Policy, DCAE and maybe MultiCloud

Details on Impacts to ONAP Projects can be found on this page.

Documentation Impacts

VNF Guidelines and Requirements (VNFRQTS) will need to be updated to show how VNFs should handle Scaling events

Integration Testing Impacts

Test descriptions for integration testing of VNF scaling behavior

Use Case Authors


Detailed Flows

ONAP Scale Out Homing and License Flow 

ONAP Scale Out Work Flow

 ONAP Scale Out Paper

  • No labels


  1. Scott,

    I am wondering why scaling is being treated as a business use case, rather than a general-purpose platform feature and would be utilized by different use cases as appropriate. From the looks of things it seems to be yet another project that is being proposed for R2 in support of the business use cases, e.g. VoLTE, vCPE, 5G, etc...

    I would suggest that you get in touch with Chris Donley and see if you arrange a presentation for the architecture subcommittee.

    Kind regards,

    Alex Vul

    1. Thanks for the feedback Alex,

      We presented this VNF Scale Out Use Case to the Use Case subcommittee last week and they were interested in more detail and us adding the Use Case to the Wiki. That is why we created this page.  Now the Use Case team can give it a more detailed review and determine what to do with it.  Steven Wright will get in touch with Chris Donley to be sure the architecture subcommittee is also aware of this work.

      Scott Blandford

  2. Hello,

    Is the auto scaling functionality already available in ONAP Amsterdam ? 

    I'm interested in implementing auto scaling for the CW vIMS VNF and if it's doable with the current version of ONAP.


  3. The point of bringing it here is to have it become a platform use case that is tested by the integration test team as part of the normal ONAP  development processes. ideally this would lead to an example of standard VNF behavior that other VNFs could emulate. 

  4. Hi,

    Just a quick question and a comment.  Maybe this has been discussed in detail, but does the scale-out use case also cover scale-in?

    The figure in the wiki here includes MSO.   The Whitepaper version of the figure has SO which seems more correct.

    Thanks, Steve

    1. This use case only addresses Scale Out.  Scale In has enough complications that we thought it should be its own use case. 

      Thanks for the MSO/SO issue.  I will fix it now.

  5. Is On Demand Scaling supported in ONAP or what is plan for it?

    1. It is currently supported in a very limited fashion  (vDNS can scale automatically), but this is not a generic capability of the platform yet.  That is why there are several scaling efforts for the Beijing release.  Hopefully, by May we will support On Demand Scaling.

  6. There seems to be some discrepancy in the call flow as depicted in "Scale out Work Flow" or "Flow Diagram" as against the one depicted in "ONAP Scale Out Homing and License Flow".

    In the former ones, the policy engine directly triggers SO, while in the later flow, the policy triggers APPC which then triggers SO. The ONAP scale out paper also seems to suggest the former call flows (Policy directly invoking SO).

    Which one of the above two is true? 

    1. Milind, the second one is now correct.  I have not updated the other flows.  Talking with several architects we determined that the Scaling request required by SO needs more information than Policy can easily provide.  Therefore it was decided that the scaling event would be sent to APPC so that it could assemble the information required by SO to scale the VNF Component.  I will fix this page to show those changes.

      It is also important to note that Auto Scaling is not part of the Beijing Release.  So this flow will not used in Beijing.  Manual scaling is the only thing being developed as a part of Beijing.  At this time, we are planning on doing the Closed Loop, Auto Scaling as part of Casa Blanca.

      1. Thanks Scott.

        I would like to make only one point that scaling requirements and interface should be the same regardless whether it's manual trigger or through the policy. In that sense the same SO workflow should be invoked for manual and policy driven scale-out scenarios. In the former case (Manual scale out), this new SO workflow shall be invoked by VID, while for the latter case (Automated and Policy driven) it shall be invoked by APPC as per the new design.

        1. I agree and that is what the goal is.  In Beijing we will define the Manual trigger that comes from VID to SO.  In Casablanca, APPC will construct the same request for auto scaling that VID does manual scaling.

  7. Scott BlandfordSeshu Kumar MRanda MaherSastry Isukapalli

    How would the HPA  related requirements be handled as part of the scale out?



  8. Hello, one question for the diagram 'ONAP Scale Out Homing and License Flow'. 

    Why is OOF checked with AAI for the region capacity? Shouldn't it check with Multicloud which owns the runtime data of the VIMS?  Pls correct me if i am wrong. Thanks.

    Best Regards,


  9. Hi Ruoyu: You are correct. It is a query to AAI to get the VNF information, it is not a capacity check. This needs to be fixed in the diagram. Also, after discussing the Homing/Placing checks at the OOF subcommittee weekly call last week, the flow will be updated to reflect a check to multicloud. I am still verifying whether there is an interface to SDNC to do other capacity checks in ONAP or whether this would be a new impact.