docs/guides/onap-developer/architecture/blueprint-enr.rst

   1 ONAP Blueprint Enrichment
   2 -------------------------
   3
   4 The ONAP Beijing release includes four functional enhancements in the
   5 areas of manually triggered scaling, change management, and hardware
   6 platform awareness (HPA). These features required significant community
   7 collaboration as they impact multiple ONAP projects. These features are
   8 applicable to any use case; however, to showcase them in a concrete
   9 manner, they have been incorporated into VoLTE and vCPE blueprints.
  10
  11 Manually Triggered Scaling
  12 ~~~~~~~~~~~~~~~~~~~~~~~~~~
  13
  14 Scale-out and scale-in are two primary benefits of NFV. Scaling can be
  15 triggered manually (e.g., by a user or OSS/BSS) or automatically via a
  16 policy-driven closed loop. An automatic trigger allows real-time action
  17 without human intervention, reducing costs and improving customer
  18 experience. A manual trigger, on the other hand, is useful to schedule
  19 capacity in anticipation of events such as holiday shopping. An ideal
  20 scaling operation can scale granularly at a virtual function level (VF),
  21 automate VF configuration tasks and manage the load-balancer that may be
  22 in front of the VF instances. In addition to run-time, this capability
  23 also affects service design, as VNF descriptors need to be granular up
  24 to the VF level.
  25
  26 The Beijing release provides the initial support for these capabilities.
  27 The community has implemented manually triggered scale-out and scale-in
  28 in combination with a specific VNF manager (sVNFM) and demonstrated this
  29 with the VoLTE blueprint. An operator uses the Usecase UI (UUI) project
  30 to trigger a scaleing operation. UUI communicates with the Service
  31 Orchestrator (SO). SO uses the VF-C controller, which in turn instructs
  32 a vendor-provided sVNFM to implement the scale-out action.
  33
  34 We have also demonstrated a manual process to Scale Out VNFs that use
  35 the Virtual Infrastructure Deployment (VID), the Service Orchestrator
  36 (SO) and the Application Controller (APPC) as a generic VNF Manager.
  37 Currently, the process is for the operator to trigger the Scale Out
  38 action using VID, which will request SO to spin up a new component of
  39 the VNF. Then SO is building the ConfigScaleOut request and sending to
  40 APPC over DMaaP, where APPC picks it up and executes the configuration
  41 scale out action on the requested VNF.
  42
  43 Change Management
  44 ~~~~~~~~~~~~~~~~~
  45
  46 NFV will bring with it an era of continuous, incremental changes instead
  47 of periodic step-function software upgrades, in addition to a constant
  48 stream of both PNF and VNF updates and configuration changes. To
  49 automatically deliver these to existing network services, the ONAP
  50 community is creating framework to implement change management
  51 functionality that is independent of any particular network service or
  52 use case. Ideally, change management provides a consistent interface and
  53 mechanisms to manage complex dependencies, different upgrade mechanisms
  54 (in-place vs. scale-out and replace), A/B testing, conflict checking,
  55 pre- and post-change testing, change scheduling, rollbacks, and traffic
  56 draining, redirection and load-balancing. These capabilities impact both
  57 design-time and run-time environments.
  58
  59 Over the next several releases, the community will enhance change
  60 management capabilities in ONAP, culminating with a full CI/CD flow.
  61 These capabilities can be applied to any use case; however, specifically
  62 for the Beijing release, the vCPE blueprint has been enriched to execute
  63 a predefined workflow to upgrade the virtual gateway VNF by using
  64 Ansible. An operator invokes an upgrade operation through the VID
  65 interface. VID drives SO, which initiates a sequence of steps such as
  66 VNF lock, pre-check, software upgrade, post-check and unlock. Since
  67 virtual gateway is an L3 VNF, the specific operations are carried out by
  68 the SDN-C controller in terms of running the pre-check, post-check and
  69 upgrade through Ansible playbooks.
  70
  71 Hardware Platform Awareness (HPA)
  72 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  73
  74 Many VNFs have specific hardware requirements to achieve their
  75 performance and security goals. These hardware requirements may range
  76 from basic requirements such as number of cores, memory size, and
  77 ephemeral disk size to advanced requirements such as CPU policy (e.g.
  78 dedicate, shared), NUMA, hugepages (size and number), accelerated
  79 vSwitch (e.g DPDK), crypto/compression acceleration, SRIOV-NIC, TPM, SGX
  80 and so on. The Beijing release provides three HPA-related capabilities:
  81
  82 1. Specification of the VNF hardware platform requirements as a set of
  83    policies.
  84
  85 2. Discovery of hardware and other platform features supported by cloud
  86    regions.
  87
  88 3. Selection of the right cloud region and NFV infrastructure flavor by
  89    matching VNF HPA requirements with the discovered platform
  90    capabilities.
  91
  92 While this functionality is independent of any particular use case, in
  93 the Beijing release, the vCPE use case has been enriched with HPA. An
  94 operator can specify engineering rules for performance sensitive VNFs
  95 through a set of policies. During run-time, SO relies on the ONAP
  96 Optimization Framework (OOF) to enforce these policies via a
  97 placement/scheduling decision. OOF determines the right compute node
  98 flavors for the VNF by querying the above-defined policies. Once a
  99 homing decision is conveyed to SO, SO executes the appropriate workflow
 100 via the appropriate controller.