Deployment Scenarios Fernando Oliveira Fred Based on slide

Deployment Scenarios Fernando Oliveira ( Fred )

Based on slide from Gil Bullard’s ETSI MANO NS/ONAP Service Proposal An ETSI Service Provider’s Operations Environment 1 Does not formally specify application level data, only deployment data Service A’ NS A VNF 1’ 2’ VNF (Service A’ Request) SM (Service A’) 8 (Service A’ Request) 2 VNF 2 Ntw A SOL 005 (“NS A” request) NFVO SOL 001 (VNFD & NSD) SOL 003 3 SOL 001 (VNFD) 5 VNFM 1 VNFM 2 Ntw A 4 VIM 7 VIM Does not formally specify application level data, only deployment data 3 Application Level configuration of VNF 2 in context of Service A’ NM NS A VNF 1 (*EM is optionally considered part of OSS) Application Level configuration of VNF 1 in context of Service A’ 2 1 BSS/OSS 6 Proprietary (deployment data) VNF 1 VNF 2 EMs EM Design/Develop Time: 1. Create and distribute Service A’, VNF 1’, and VNF 2’ definitions (outside of the scope of MANO) to OSS/BSS. In this example VNF 1’ and VNF 2’ “descriptors” capture the application level configuration needs of what the VNFM knows as VNF 1 and VNF 2. 2. Create and distribute VNF 1, VNF 2, and NS A descriptors to NFVO. 3. Create and distribute VNF 1 and VNF 2 descriptors to VNFM. Run Time: 1. OSS/BSS receives request to create an instance of Service A’. OSS/BSS “decomposes” request into NS A, VNF 1’, VNF 2’. 2. OSS/BSS calls NFVO via SOL 005 API requesting instantiation of NS A. 3. NFVO calls VNFM 1 via SOL 003 API, requesting creation of VNF 1, passing necessary “deployment data” values. 4. VNFM 1 calls VIM to create VNF 1, and applies any needed deployment data via proprietary API. At this point VNF 1 only has “deployment data” (networking data) configured. “Deployment data” can be thought of as the functional equivalent of the sort of data one might expect to find captured in a HEAT ENV. 5. NFVO calls VNFM 2 via SOL 003 API, requesting creation of VNF 2, passing necessary “deployment data” values. 6. VNFM 2 calls VIM to create VNF 2, and applies any needed deployment data via proprietary API. At this point VNF 2 only has “deployment data” (networking data) configured. 7. Connectivity between the VNFs is configured via a direct interface between the NFVO and the VIM 8. The BSS/OSS stages the EM(s) with the appropriate application configuration data. (Note that this is outside of the scope of ETSI, and so different Service Providers can use different triggers for sending application level data to the EMs, and triggering the application of that data into the VNFs. )

ETSI NFV Reference Architecture

Legacy NFVO, VNFM, EMS and Service Assurance Legacy OSS SOL 005 SOL 004 CSAR SOL 001 VNF-D & NS-D Application Data SOL 003 & SOL 004 CSAR & SOL 001 VNFD S-VNFM Proprietary VNF VNF deployment data VNF VNF VIM NFVI Trigger LCM operation NFV-O VIM NFVI Service Assurance VIM NFVI Proprietary App Config and Monitoring EMS EMS

ONAP with external VNFM, EMS and Service Assurance Legacy OSS SOL 004 CSAR SOL 001 VNF-D & NS-D Onboarding SOL 001 NS-D SOL 005 Trigger LCM operation SDC NFVO SO Service Assurance App-C / GNF-C SOL 003 & SOL 001 VNF-D S-VNFM Proprietary VNF deployment data VNF VNF Proprietary App Config and Monitoring EMS EMS

Example Use Case: ETSI VNF Onboarding and management • Description: ONAP manages an onboarded VNF, application management of the associated VNF is done through out-of-band non. ONAP means; External VNFM used to create VNFs • Assumptions: A Service comprised of a set of one or more NFs (VNFs or PNFs) • Design Time: - Onboard into ONAP VNF(s) via SOL 001/004 Design ONAP Service referencing VNF(s) with deployment data but no application configuration data • Run Time Orchestration Scenario #1: Service Instantiation - ONAP receives a request for Service instantiation ONAP decomposes into component NFs (VNFs, PNFs), homes VNFs to cloud region(s) ONAP makes assignments (e. g, . connection point IP Addresses) for the homed NFs ONAP invokes appropriate VNFM(s) via SOL 003 to create VNFs End (Note: Application configuration is done out-of-band via EM(s) • Run Time Orchestration Scenario #2: VNF Scaling - ONAP receives a SOL 005 or Service Assurance request to Scale the VNF (either “Scale to Level” or “Scale by Increment”, validated) ONAP makes resource assignments for scale out ONAP invokes appropriate VNFM(s) via SOL 003 to scale in or out VNF ONAP releases resource assignments for scale in End (Note: if any application configuration changes need to be applied as part of the scaling, these will be done out-of-band via EM(s)

ONAP with external VNFM, EMS and SA + App Config Legacy OSS SOL 004 CSAR SOL 001 VNF-D & NS-D Onboarding SOL 001 NS-D SOL 005 Trigger LCM operation SDC NFVO SOL 003 & SOL 001 VNF-D SO Service Assurance App-C / GNF-C App Config / Monitoring SOL 002 S-VNFM Proprietary VNF deployment data VNF VNF Proprietary App Config and Monitoring EMS EMS

Onboard NSD and VNFDs, External VNFM, Application Management by ONAP • Description: ONAP enriches an onboarded NS, application management of the associated NFs done via ONAP; External VNFM used to create VNFs • Assumptions: - A Network Service (A) comprised of a set of one or more NFs (VNFs or PNFs), no application data in descriptor - An ONAP Service (A’) comprised of a set of one or more NFs, application data in descriptor • Design Time: - Onboard into ONAP VNFD(s) via SOL 001/004 - Onboard some descriptor (standard) of the VNF application level configuration requirements so as to “enrich” the ONAP descriptor - Onboard into ONAP or Design an NSD via SOL 001/004, referencing the above VNFDs (no application management requirements at the VNF or NS level) - ONAP translates NS input artifacts into an ONAP Service with no application management requirements/information associated with the VNFs/Service. - Enrich the ONAP Service by referencing the enriched VNF descriptors to include application management requirements of the VNFs; create application management requirements for the ONAP Service, mapping to drive those of the component VNFs. • Run Time Orchestration Scenario #1: ONAP Service Instantiation ONAP receives a Service Instantiation request for the ONAP Service (optional input “Instantiation Level” to be validated) ONAP decomposes into component NFs (VNFs, PNFs, ANFs), homes VNFs to cloud region(s) ONAP makes assignments (e. g, . connection point IP Addresses) for each homed NF ONAP invokes appropriate VNFM(s) via SOL 003 API to create VNFs ONAP creates ANFs (as needed) ONAP configures the appropriate NF(s) (VNF, PNF, ANF) with needed application configuration data via (standard) NF provisioning API - End -

ONAP with external NFVO, VNFM, EMS and Service Assurance Legacy OSS SOL 004 CSAR SOL 001 VNF-D & NS-D Onboarding SOL 001 NS-D SOL 005 Trigger LCM operation SDC NFVO SOL 001 NS-D SOL 003 & SOL 001 VNF-D VNFM VNF VNF VNF App-C / GNF-C SO SOL 005 Legacy NFVO SOL 003 VNFM VNF VNF VNF Proprietary App Config and Monitoring EMS EMS Service Assurance

ONAP with external NFVO, VNFM, EMS and Service Assurance Legacy OSS SOL 004 CSAR SOL 001 VNF-D & NS-D Onboarding SOL 001 NS-D SOL 005 SDC NFVO SOL 001 NS-D SOL 003 & SOL 001 VNF-D VNFM VNF VNF VNF App-C / GNF-C SO Service Assurance Trigger LCM operation SOL 005 Legacy NFVO SOL 003 VNFM VNF VNF VNF SOL 002 App Config and Monitoring Proprietary App Config and Monitoring EMS EMS

Actions & Questions • Add SDN configuration slide • What does the internal model look like? • Scale: What and where? • Does NFVO get implemented in ONAP (VF-C) or in SO? • How does DCAE fit into SA and what is migration from legacy? • How to control nested service and/or an E 2 E service that includes an external NS(NFVO)?

• CM: Incremental addition of ONAP capabilities is preferred • CM: Can SDC design a “Network Service” that can be managed by an ETSI NFVO? • CM: Can the application configuration aspects of ONAP be leveraged on a “Network Service” that is managed by an external NFVO?