ONAP ETSI Alignment Proposals in Support of VNF

ONAP – ETSI Alignment Proposals in Support of VNF Scaling A focus on the VNFM plug-in scenario

Current ONAP Scaling Approach: VF Module • VF Module - A “subset” of a VNF (perhaps not proper) - Consisting of a collection of cloud resources: VMs/Containers, Networks, and Volumes - Considered by ONAP to be a “unit of deployment” for instantiation and scaling purposes • Types of VF Module - “Base” VF Module: the minimum viable configuration of a VNF; the "immutable" part of the VNF - “Add-On” VF Module • Represented in VNF TOSCA as a TOSCA Group • ONAP orchestration of VNFs is done at the VF Module level. - SO VNF-level workflow includes a loop which requests SDNC to make VNF assignments on a per VF Module basis - SO VNF-level workflow also loops through each VF Module as part of VNF instantiation and scaling. For each VF Module, either: • • A “VF Module Orchestration” sub-flow orchestrates the VF Module, generating cloud-agnostic requests to Multi. VIM on a per-cloud resource basis, or ONAP finds the associated opaque (to ONAP) template artifact (e. g. , a HEAT template, an Azure-specific ARIA blueprint) that corresponds to this VF Module, and forwards to Multi. VIM for passing on to the VIM • Note from the above that the VF Module concept is a generic construct and not in any way restricted to use with Open. Stack HEAT. - The VF Module construct allows ONAP scaling to be represented as adding or removing VF Modules from a VNF instance. - If the VNF is represented via an opaque template artifact (e. g. , HEAT) then it would be expected that a separate template would exist per VF Module. 2

ONAP Scaling Compared to ETSI • The ONAP construct of VF Module can be mapped to the ETSI concept of “Scaling Aspect/Level” • Thus, it should be possible for ONAP to accept an ETSI-compliant VNF descriptor and extract from that sufficient information to map to the ONAP VF Module construct • The following slides describe how this could be done: - Resource View: VF module in ONAP is mapped to Scaling. Delta in ETSI, where Base Module is mapped to Initial. Delta / Scaling. Level 0 in ETSI and Add -on Modules are mapped to Scaling. Delta in ETSI. - Deployment View: “Initial count” of VF module types in ONAP is mapped to one of Instantiation. Levels in ETSI. 3

ETSI VNF Descriptor Aspect=y Scaling Policy (VNF Event Handling): Event P: Increment Aspect y by 1 Event Q: Scale Aspect x to Level 3 Aspect=x Translating the ETSI View to the ONAP View 0, 0 VNF 1 For Scaling Aspect = y Associated Group = Scaling. Aspect: max. Scale. Level = 2 Aspect. Delta. Details: uniform. Delta = true For Scaling Aspect = x Associated Group = Scaling. Aspect: max. Scale. Level = 4 Aspect. Delta. Details: deltas: SDC SOL 004 (VNF Package) includes SOL 001 (VNFD) Translate ([x, 4]) ([x, 3]) ([x, 2]) ([x, 1]) Translation involves creating the equivalent VNF model in ONAP as per the formal ETSI spec. I. e. , translation results in an ONAP representation of VNF 1 (blue) that has only “deployment data” specified. 4

Mapping to ONAP VF Module Best Current Understanding of an Approach: • Disable Autoscaling for VNFM plugged in to ONAP • Determine the requirements, connection point definitions, instances, etc. for a given VM/Container from the corresponding VDU definition in the ETSI VNF descriptor • Map the Aspect/Levels to ONAP VF modules as follows: - Create an ONAP “Base Module” by including the number of VDUs (as per the VNFD) with initial Delta across all Aspects. - For each Aspect that is “uniform delta”, create a corresponding “Add-On” VF Module containing the VDU instances for that Aspect. - For each Aspect that is “non-uniform delta”, then create a separate “Add-On” VF Module for each defined Level delta. The VDU instances in each VF Module are those defined for that Aspect/Level. • Create ONAP run time scaling policies that correspond to the “scale” and “scale. To. Level” policies in the VNF descriptor. (ONAP cannot support a “script” in the SOL 001 because it has no way to know how to gather the proper assignments. )

Mapping to ONAP VF Module • In the future perhaps we can optimize by combining VF Modules with the same content (such as [x, 1] and [x, 3] to the left) by analyzing their VDU contents.

“Plugging In” a VNFM Into ONAP: Instantiate VNF • Locate the ordered set of VF 2 Modules associated with the requested instantiation level (from the transformed VNF TOSCA). • Determine if requested instantiation level is allowed. (If not, return Error) SO SO Internal: VNF Level Workflow Inventory 5 Instantiate VNF 3 Assign VNF (Instantiate) 11 Configure VNF 10 SO Loop: Per VF Module SO or VNFM Adaptor would be responsible for retrieving the assignments from SDNC (organized by VF Module) and consolidating them (organizing by VM type). If necessary VNFM Adaptor 9 6 SOL 003 (Create. Vnf, Instantiate. Vnf, Grant) 4 Assign VF Module VNFM (Doesn’t necessarily care about VF Modules) SDNC 7 8 Deployment Data (SOL 002) VIM 1 Instantiate VNF (Instantiation Level) Resource Data VID SO Service Level and VNF Loop Level Workflows not shown for simplicity. VNF A&AI Gen NFC Application 10 Data

“Plugging In” a VNFM Into ONAP: Scale Out by Level Increment – Option A SO Service Level and VNF Loop Level Workflows not shown for simplicity. 6 SO SO Internal: Scale Out By VF Module Workflow 9 Extract scaling. Aspect and Aspect. Level from VF Module description 7 Assign VF Module 8 Create VF Module 14 13 VNFM Adaptor 10 SOL 003 (scale. By. Aspect +1, Grant) Update Scale Level 2 Scale Request (SOL 002) A&AI If necessary 15 Configure VNF Gen NFC VIM 11 Resource Data (Doesn’t necessarily care about VF Modules) 12 Deployment Scale Indicator Data (SOL 002) 1 VNF Scale Request Event 5 Policy Scale Request Event 4 Application 16 Data SDNC VNFM • Determine if Aspect y is “uniform” or “non” • Query A&AI for Current Aspect=y Scale Level • Determine VF Module type associated with Current Level +1 3 VES Scale Request DCAE Event P: Increment Aspect y by 1

“Plugging In” a VNFM Into ONAP: Scale Out to Level – Option A SO Service Level and VNF Loop Level Workflows not shown for simplicity. SO 6 7 For Each VF Module (in proper sequence) SO Internal: Scale Out By VF Module Workflow 9 Create VF Module 10 Extract scaling. Aspect and Aspect. Level from VF Module description 8 Assign VF Module SDNC Update Scale Level 14 VNFM Adaptor 11 SOL 003 (scale. By. Aspect +1, Grant) 15 2 Scale Request (SOL 002) A&AI VNFM VIM 12 Resource Data (Doesn’t necessarily care about VF Modules) 13 Deployment Scale Indicator Data (SOL 002) 1 VNF If necessary 16 Configure VNF Gen NFC • Determine if Aspect y is “uniform” or “non” • Query A&AI for Current Scale Level • Determine the ordered set of VF Module types that form delta between current and target Level Scale Request Event 5 Policy Scale Request Event 4 Application 17 Data 3 VES Scale Request DCAE Event Q: Scale Aspect x to Level 3

“Plugging In” a VNFM Into ONAP: Scale Out by “Add VF Module” SO Service Level and VNF Loop Level Workflows not shown for simplicity. Add VF Module k • Locate the single VF Module 2 k (from the transformed VNF TOSCA). • Extract its scaling-aspect and aspect-level properties. • Determine if Aspect y is “uniform” or “non” • Query A&AI for Current Aspect=y Scale Level • Determine if aspect-level of requested VF Module != next level (if so, return Error) SO SO Internal: Scale Out By VF Module Workflow 4 Create VF Module 3 Assign VF Module 5 Extract scaling. Aspect and Aspect. Level from VF Module description VNFM Adaptor 10 Update Scale Level 6 SOL 003 (scale. By. Aspect +1, Grant) VNFM (Doesn’t necessarily care about VF Modules) SDNC 7 8 Deployment Data (SOL 002) VNF If necessary 11 Configure VNF 9 A&AI VIM 1 Resource Data VID Gen NFC Application 12 Data

Stable ONAP Ecosystem Onboard ETSI VNF with VNFM, ONAP Service Designer enriches the “VNF 1” model to describe the input level data that must be supplied with the instantiation request to configure the application data, and the data transformation and mapping to VNF configuration API(s). This enrichment can be automated if there exist formal artifacts that describe the application data (e. g. , 3 GPP NRM IOC). But automation of enrichment is out of scope of this discussion. OSS/BSS SDC SOL 004 (VNF Package) includes SOL 001 (VNFD) Translate Enrich ONAP SD, VNFD ONAP Service A’ SM/NM/EM Translate -> VNF 1 SOL 003 VNF 1’ VNFM 1 application data SOL 002 (deployment data) SOL 002 (indicator) VIM If the VNF is supported by a “plug in” VNFM, then the SDC “Translate” function would map ETSI “resource data” and “deployment data” into ONAP “cloud services” data for submission across a SOL 003 API. In this case, ONAP interacts with the VNFM at the “Create” operation, and not with a VIM directly. Local Recovery Translation involves creating the equivalent VNF model in ONAP as per the formal ETSI spec. I. e. , translation results in an ONAP representation of VNF 1 (blue) that has only “deployment data” specified. When a VNFM is “plugged in” to ONAP, ONAP will automatically disable ETSI “auto-scale”. Rather, the VNF-specific “indicator” notification will be directed to DCAE, Policy which determines when scaling is needed. The SDC “translate” function includes translating any scaling policies captured in the ETSI VNFd. (E. g. , A formal “opaque” policy that says “if you see this event then run this script”. A formal “LCM policy” grammar where you can define more elaborate behavior. ) TBD (Service A’ request) VIM Telemetry VNF 1 Service Designer defines the “Service A’” model which includes VNF 1’. Included is the definition of the input level data that must be supplied with the Service A instantiation request, and the associated data transformation and mapping to the VNF 1’ “deployment data” and “application data”. VNF 1 VES (telemetry)

Scaling Down and Change Management Considerations • The ETSI VNFM remembers the VDU instances that were applied to a VNF and the order in which they were applied. • For VDUs corresponding to a “non-uniform” Aspect, the VNFM itself determines which VDU instances to delete (e. g. , deleting on a LIFO basis). • For VDUs corresponding to a “uniform” aspect, the VNFM allows the client to specify which specific VDUs to delete, not enforcing LIFO (useful for ONAP “change management” flows; see below). • Thus any ONAP flows that depend on ONAP selecting a particular VF Module instance to delete in a non. LIFO manner would not be able to support doing so for a “non-uniform” Aspect. • Thus the VNFM must assume responsibility for any such functionality not available to ONAP. • For example: - ONAP change management (software upgrade) “build and replace” flows, which assume a software upgrade pattern of “scaling out” to add a VF Module on the “new” software version, followed by a “scaling in” to delete a VF Module on the “old” software version, would not work. Thus the VNFM would need to assume responsibility for software upgrades for such VNFs. - ONAP “scale down” flows which use policy to select the VF Module to delete (e. g. , that with the least utilized VDUs) would not be work. Thus the VNFM would need to implement such a policy. • The pattern of defining “uniform” scaling Aspects is the preferred approach, which would provide ONAP the opportunity to support more VNFM functionality through the ONAP policy/model-driven behavior. • Note that a VNF vendor could choose to represent any “non-uniform” scaling approach as a “uniform” approach through adding Aspects and policies. 12

Next Steps • Further Study: - Determine the necessary VNFM Adaptor (or other ONAP) functionality required to translate the SDNC approach of assignments organized per VF Module into that which is required by the ETSI VNFM - Work through the details of the “grant” request and the mechanism for delivering assignments to VNFM. - Study the implications of the ETSI assumption that a VNF “scaling” (out/in) event does not result in any “topology” changes. • Consider ONAP changes for Casablanca: - SDC: add attributes to the VF Module that capture the concept of “aspect. Id”, “scaling. Level”, and “max. Num. Of. Instances” (for uniform delta) - SDC: add a formal language for expressing scaling policies (perhaps based on that specified by ETSI), and translate ETSI VNF descriptor policies into the ONAP format. - A&AI: add attributes to capture the “Aspect” and for each an associated “Aspect Level” to VNF instance. • Do a POC in Casablanca? 13

Other scenarios being discussed Scenario: ONAP calling external VNFM Evaluating scenarios for technical complexity and business motivation ONAP VNFM 1 14