Deployment Scenarios Fernando Fred Oliveira ONAP with Legacy

Deployment Scenarios Fernando ( Fred ) Oliveira

ONAP with Legacy Orchestration, EMS, SA and Inventory #1 a (Deployment) OSS / BSS SOL 005 Os-Ma-nfvo ONAP Portal U-UI CLI Legacy Inventory 1 NTLS ONAP External APIs Dashboard OA&M Suppliers/ Partners Internal VNF Package (images, descriptors, scripts) VNF / PNF Onboarding 1 Data Collection, Analytics, and Events Correlation Policy Framework Service Design 2 Service Orchestration Policy Creation & Validation Analytic Application Design 3 Active & Available Inventory External Registry Micro Services Bus / Data Movement 2 Closed Loop Design 4 Change Management Design Multi-Cloud Adaptation Design Test & Certification Application Authorization Framework ONAP Common Optimization Services Framework Generic NF Controllers SOL 003 Adapter SDN Controller Common Services Logging Others Configuration 3 Catalog 5 6 Legacy Service Assurance 7 SOL 003 Or-Vnfm 2 VNF Manager C EMS VNF Manager B EMS VNF Manager A XXX YYY ZZZ BBB AAA CCC Collect Visualize Self-heal Correlate Proprietary 9 8 Cloud Platform (VNFs deployed on Core, Lite, Edge and Far Edge Sites) Private IP Network Far Edge Sites Customer Site u. CPE ONAP Operations Manager Resource Onboarding VNF Vendors UTS RUN-TIME CCSD K DESIGN-TIME Customer Site u. CPE Edge Sites Core Sites Network (RAN, Front/Back Haul, Core) Design/Develop Time: 1. Onboard and catalog a SOL 004 VNF package with a SOL 001 VNFD. 2. VNFM C registers as a SOL 003 compliant VNFM 3. Design an ONAP Service A with only deployment configuration referencing the onboarded VNF and VNFM C to manage it. Run Time: 1. ONAP receives request to create an instance of Service A. 2. ONAP “decomposes” request into VNF 1 and homes it a cloud region. 3. ONAP makes resource assignments for scale-out of VNF 1 based on information in the VNF-D a) Issue on if/how resources are “reserved” 4. ONAP makes assignments (IP Address) for the VNF 5. ONAP calls VNFM C via SOL 003 API, requesting creation of VNF 1, passing necessary “deployment data” values. 6. VNFM C upcalls ONAP asking for a “grant” of resources based on information in the VNF-D. a) Should be same resources as were allocated in 3 7. ONAP responds with resource information allocated in #3 along with VIM credentials. 8. VNFM C 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. 9. External user updates the EM(s) with the appropriate application configuration data which gets pushed to the VNF via a proprietary mechanism Lite Sites Message Bus Goal: Design and deploy a composite Service consisting of multiple vendor VNFs in an automated and repeatable way leveraging vendor provided SOL 003 compliant VNF Manager(s) and out of band application configuration. (Legacy approach) 2

ONAP with Legacy Orchestration, EMS, SA and Inventory #1 b (Scale Out) OSS / BSS Legacy Inventory SOL 005 Os-Ma-nfvo ONAP Portal U-UI CLI NTLS ONAP External APIs Dashboard OA&M 1 Suppliers/ Partners Internal VNF Package (images, descriptors, scripts) VNF / PNF Onboarding Service Design Policy Creation & Validation 2 Data Collection, Analytics, and Events Correlation Policy Framework Analytic Application Design Service Orchestration 2 Active & Available Inventory External Registry 2 Micro Services Bus / Data Movement 2 Closed Loop Design 2 Change Management Design Test & Certification Multi-Cloud Adaptation SDN Controller Common Services Application Authorization Framework ONAP Common Optimization Services Framework Generic NF Controllers SOL 003 Adapter Logging Others Configuration Catalog 3 4 5 Legacy Service Assurance 1 SOL 003 Or-Vnfm VNF Manager C EMS VNF Manager B EMS VNF Manager A 6 1 XXX YYY ZZZ BBB AAA CCC Collect Visualize Self-heal Correlate Proprietary Cloud Platform (VNFs deployed on Core, Lite, Edge and Far Edge Sites) Private IP Network Far Edge Sites Customer Site u. CPE ONAP Operations Manager Resource Onboarding VNF Vendors UTS RUN-TIME CCSD K DESIGN-TIME Customer Site u. CPE Edge Sites Core Sites Network (RAN, Front/Back Haul, Core) Precondition: 1. VNF 1 was previously instantiated by ONAP using VNFM C. 2. Policy was created such that VNF scaling would be triggered upon VNF 1 busyness trigger. Run Time: 1. Legacy SA sends a a VNF 1 busyness trigger to ONAP. 2. ONAP makes resource assignments for scale-out of VNF 1 based on information in the VNF-D a) Issue on if/how resources are “reserved” b) If appropriate VIM resources are not available, the service could have to redeploy the VNF on another VIM or deploy another VNF instance 3. ONAP calls VNFM C via SOL 003 API, requesting a scale-out of VNF 1. 4. VNFM C upcalls ONAP asking for a “grant” of resources based on information from the VNF-D. a) Should be same resources as were allocated in 2 5. ONAP responds with resource information allocated in #2 along with VIM credentials. 6. VNFM C calls VIM to scale VNF 1. Lite Sites Message Bus Extension of scenario #1 Goal: Leverage ONAP policy platform and resource orchestration for a scale out use case leveraging vendor provided SOL 003 compliant VNF Manager(s), handling things like optimal placement, resource reservation and resource request granting based on well defined policies. 3

ONAP with Legacy Orchestration, EMS, SA and Inventory #1 b (Scale In) OSS / BSS Legacy Inventory SOL 005 Os-Ma-nfvo ONAP Portal U-UI CLI NTLS ONAP External APIs Dashboard OA&M 1 Suppliers/ Partners Internal VNF Package (images, descriptors, scripts) VNF / PNF Onboarding Service Design Policy Creation & Validation 2 Data Collection, Analytics, and Events Correlation Policy Framework Analytic Application Design Service Orchestration 5 Active & Available Inventory External Registry 5 Micro Services Bus / Data Movement 5 Closed Loop Design 5 Change Management Design Test & Certification Multi-Cloud Adaptation Application Authorization Framework ONAP Common Optimization Services Framework Generic NF Controllers SOL 003 Adapter SDN Controller Common Services Logging Others Configuration Catalog 2 4 Legacy Service Assurance 1 SOL 003 Or-Vnfm VNF Manager C EMS VNF Manager B EMS VNF Manager A 3 1 XXX YYY ZZZ BBB AAA CCC Collect Visualize Self-heal Correlate Proprietary Cloud Platform (VNFs deployed on Core, Lite, Edge and Far Edge Sites) Private IP Network Far Edge Sites Customer Site u. CPE ONAP Operations Manager Resource Onboarding VNF Vendors UTS RUN-TIME CCSD K DESIGN-TIME Customer Site u. CPE Edge Sites Core Sites Network (RAN, Front/Back Haul, Core) Precondition: 1. VNF 1 was previously instantiated by ONAP using VNFM C. 2. Policy was created such that VNF scaling would be triggered upon VNF 1 busyness trigger. Run Time: 1. Legacy SA sends a a VNF 1 busyness trigger to ONAP implying scale-in. 2. ONAP calls VNFM C via SOL 003 API, requesting a scale-in of VNF 1. 3. VNFM C calls VIM to scale in VNF 1. 4. VNFM C upcalls ONAP asking for a “grant” to release the resources from the scale in. 5. ONAP returns the resource assignments from scale-in of VNF 1 a) Issue on if/how resources are “reserved” Lite Sites Message Bus Extension of scenario #1 Goal: Leverage ONAP policy platform and resource orchestration for a scale in use case leveraging vendor provided SOL 003 compliant VNF Manager(s), handling things like optimal placement, resource reservation and resource request granting based on well defined policies. 4

ONAP with Legacy Orchestration, EMS, SA and Inventory #2 (NS deployment) OSS / BSS Legacy Inventory 1 SOL 005 Os-Ma-nfvo ONAP Portal U-UI CLI NTLS ONAP External APIs 1 Suppliers/ Partners Internal VNF Package (images, descriptors, scripts) 1 VNF / PNF Onboarding Service Design Data Collection, Analytics, and Events Correlation Policy Framework UTS RUN-TIME 2 Service Orchestration Active & Available Inventory External Registry Micro Services Bus / Data Movement 3 Closed Loop Design Change Management Design Test & Certification Multi-Cloud Adaptation SOL 005 Adapter SDN Controller Application Authorization Framework ONAP Common Optimization Services Framework Generic NF Controllers Logging Others Configuration 3 Catalog 3 H R 45 6 SOL 003 Or-Vnfm VNF Manager C SOL 005 Os-Ma-nfvo EMS VNF Manager B EMS VNF Manager A 7 Legacy Service Assurance Legacy Orchestrators 2 E XXX YYY ZZZ BBB AAA CCC Collect Visualize Self-heal Correlate Proprietary 8 Cloud Platform (VNFs deployed on Core, Lite, Edge and Far Edge Sites) Private IP Network Far Edge Sites Customer Site u. CPE Common Services Policy Creation & Validation Analytic Application Design ONAP Operations Manager Resource Onboarding VNF Vendors Dashboard OA&M CCSD K DESIGN-TIME Customer Site u. CPE Edge Sites Design/Develop Time: 1. Onboard and catalog a SOL 004 VNF package with a SOL 001 VNFD. 2. NFVO R registers as a SOL 005 compliant NFVO 3. Design an ONAP Service A with only deployment configuration referencing VNF 1 and NFVO R to orchestrate it. Run Time: 1. ONAP receives request to create an instance of Service A. 2. ONAP “decomposes” the request into an NS. 3. ONAP calls NFVO R via SOL 005 API, requesting creation of NS 1, passing necessary “deployment data” values. 4. NFVO R calls VNFM C requesting creation of an instance of VNF 1. 5. VNFM C upcalls NFVO R asking for a “grant” of resources. 6. NFVO R responds with resource information and VIM credentials. 7. VNFM C calls VIM to create VNF 1, and applies any needed deployment data via proprietary API. 8. External user updates the EM(s) with the appropriate application configuration data which gets pushed to the VNF via a proprietary mechanism. Core Sites Lite Sites Message Bus Goal: Leverage ONAP VNF onboarding and Service Design capabilities to develop a composite service that can be instantiated and managed by an existing SOL 005 compliant orchestrator. (ONAP acting as an OSS/BSS) Network (RAN, Front/Back Haul, Core) 5

Backup

ONAP with Legacy Orchestration, EMS, SA and Inventory OSS / BSS Legacy Inventory SOL 005 Os-Ma-nfvo ONAP Portal U-UI CLI NTLS ONAP External APIs VNF Package (images, descriptors, scripts) VNF / PNF Onboarding Suppliers/ Partners Service Design Data Collection, Analytics, and Events Correlation Policy Framework UTS RUN-TIME Service Orchestration Active & Available Inventory External Registry Common Services Application Authorization Framework ONAP Common Optimization Services Framework Policy Creation & Validation Analytic Application Design Micro Services Bus / Data Movement Closed Loop Design Change Management Design Test & Certification Multi-Cloud Adaptation Generic NF Controllers SDN Controller ONAP Operations Manager Resource Onboarding VNF Vendors Dashboard OA&M Logging Others Configuration CCSDK DESIGN-TIME Catalog Internal SOL 005 Os-Ma-nfvo Legacy Service Assurance Legacy Orchestrators R SOL 003 Or-Vnfm VNF Manager EMS EMS VNF Manager E XXX YYY ZZZ BBB AAA CCC Collect Visualize Self-heal Correlate Openconfig SOL 002 Ve-Vnfm-vnf AWS Cloud Platform (VNFs deployed on Core, Lite, Edge and Far Edge Sites) Private IP Network Far Edge Sites Customer Site u. CPE H Customer Site u. CPE Edge Sites Core Sites Network (RAN, Front/Back Haul, Core) Lite Sites Message Bus 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. ) 7

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)

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 -