FUNCTIONAL Architecture for R2+ Every Resource can be exposed as a Service. Portal (GUI/CLI) Run-time Dashboard OA&M (VID) External Data Movement & APIs Design-time A&AI Service Orchestration Because every Resource can be exposed as a Service, we do not believe it wise to separate the Service Orchestration and the Resource Orchestration functions into separate ONAP components. Domain Service Descriptors Domain Service Descriptors ESR SDC Common Service Resource Orchestration Domain Resource Descriptors Domain Resource Descriptors VNF SDK DMaaP Auth. Microservice Bus … CLAMP Policy DCAE Alarm Correlation (Holmes) … SDN-C APP-C (g/s) vnfm Other? Addressed only tangentially in this discussion Multi-VIM/MultiCloud Cloud & WAN OpenStack VMware RackSpace Azure ...... Consensus on layered architecture. This picture does not imply project structure.

Terminology Mapping ONAP ETSI MANO (1) Service Network Service (Infrastructure Services only) (2) Service Orchestration Network Service Orchestration (2) Resource VNF and Network (NFVI) network resources (3) Resource Orchestration Specific NFVO functions that manage or coordinate the VNF or NFVI network resource’s lifecycle (3) Cloud Resource NFVI compute, storage, network Cloud Resource Orchestration Functions, perhaps provided by the underlying Cloud Provider (4), that manage or coordinate the NFVI compute, storage, network resource’s lifecycle Network An NFVI resource Allotted Resource (5) This concept is not discussed in MANO VF Module Virtualisation Deployment Unit (VDU) VF Component VNFC Because of this, ETSI TERMINOLOGY IN AND OF ITSELF IS NOT SUFFICIENT TO DESCRIBE THE ONAP PROBLEM SPACE. Ref: ETSI - NFV Terminology for Main Concepts in NFV ONAP includes “Customer Services” that ride on top of what ETSI would call a “Network Service”. Also ETSI considers a “Network Service” as always including at least one dedicated VNF, whereas ONAP allows for “Services” that do not include any dedicated VNFs. Concept of “Allotted Resource” is not discussed in MANO. The concept of “PNF” seems to be out of scope for an NFV-MANO implementation. For example, the orchestration provided by OpenStack HEAT An “Allotted Resource” is a resource that is provided by an underlying Service, and which is allotted to a customer’s (for example) Service Instance. E.g., a “VRF” would be modeled as an “Allotted Resource” provided by a virtual PE Router VNF.

Allotted Resources – vPE/VRF Example 1 4 Every Resource can be exposed as a Service. The ONAP model supports this today through the “Allotted Resource” construct. This concept of “Allotted Resource” does not seem to appear in the ETSI model. Perhaps this is due to ETSI seemingly covering only instantiation of Infrastructure Services, and not instantiation of end Customer Services. An instantiation request for a L3VPN_Cust Service would result in a VRF being instantiated. That VRF would be “homed” to an existing vPE_Infra Service instance (i.e., the vPE VNF instance on which this VRF will be configured). “Higher Level” Service 2 L3VPN_Cust Service: topology_template: node_templates: VRF In this case, the vPE VNF has been packaged as an Infrastructure Service. An instantiation request for this vPE_Infra Service would result in a new vPE VNF being instantiated. VRF Allotted Resource requirement: VRF_Capability “Lower Level” Service vPE VNF vPE_Infra Service: topology_template: node_templates: vPE VNF vPE_Network capability: VRF_Capability 3 The vPE_Infra Service exposes a capability to provide “VRFs” (a “VRF_Capability”). The L3VPN_Cust Service consumes this capability through its “VRF Allotted Resource” construct. Network

Model-Driven Orchestration “Generic” model-driven Service flow (limited existing) Each Resource Type has its own “Generic” model-driven flow. There currently exist such flows for “VNF” and “Network” Resource Types. Service Orchestration Resource Orchestration Cloud Resource Orchestration PNF Service X: topology_template: node_templates: PNF Network VNF Allotted Resource Network VF Module Note recursion VNF Service Orchestration Resource Orchestration Allotted Resource requirement: A PNF An Allotted Resource can be homed to an existing “underlying” Service Instance, or homing could determine that a new Service Instance is needed. This would result in a 2nd level of Service Orchestration. Service Y: topology_template: node_templates: PNF Network VNF Allotted Resource capability: A Network Service Y is being treated as a “Resource” from the perspective of Service X. VNF Allotted Resource

N-Level Run Time Nesting? Let The Service Providers Decide Each Service/Resource “reuse unit” results in a separate thread of orchestration. This would allow for “on demand” spin up of “lower level” (Infrastructure) Service instances. Could be extended to allow multiple “higher level Services” to each have a “share” of a “lower level Service’s” instance For the case whereby a “higher level Service” consumes the entirety of a “lower level Service’s” instance, then rather than using an “Allotted Resources” modeling approach, the Service Provider could use a “substitution mapping’ modeling approach. This would result in “flattening” the run-time orchestration

Conclusions Service Providers require the ability to define Services that can be leveraged by higher order Services. We should not separate Service Orchestration and Resource Orchestration into two separate named components, because each Resource can be exposed as a Service. What appears as a “Resource” from one Service’s perspective, may actually be a Service from another perspective. ONAP includes the modeling of “Customer Services” in its charter, whereas ETSI does not appear to do so. Thus, the ETSI terminology and modeling in and of itself is not sufficient to cover the ONAP problem space. ONAP should provide Service Providers the ability to model their “Service reuse” to drive run-time behavior on a service-by-service basis, including: Allowing each Service/Resource level to result in a separate set of orchestration threads. Allow the Service Provider to “flatten” some levels of reuse at run time (e.g., through design time substitution mapping).

ONAP Proposed Target Merged Architecture OSS BSS ONAP Portal – Design Studio & Dashboard Design-time (SDC) Run-time Lab Integration & Certification ONAP Operations Management (OOM) External Data Movement & APIs Modeling (specs & Utilities) Resource Onboarding A&AI DCAE Policy Active / Available VNF SDK Orchestration Framework Analytic µServices Runtime Policy Execution Engine Service & Product Design Entitlements Service Orchestration CDAP Holmes … Policy Creation & Validation Resource / Service Topology Data Distribution Resource Orchestration ESR Data Collection Layer Analytic Application Design Common Service DMaaP AAF Logging Micro Services Bus Catalog Testing & Certification SDN-C gVNF-Controller (prev. App-C) Products Resources Eng. Rules Services Policies Analytics Multi-VIM L0-3 Network Controller Addressed only tangentially in this discussion L4-7 Generic VNF Controller Model Driven Infrastructure Adaption Layer Config Database Service Logic Interpreter Life Cycle Mgmt DGs Config Database Service Logic Interpreter Life Cycle Mgmt func. Recipe / Engineering Rules & Policy Distribution Adaption Layer Standard & sVNFM Adaption Layer Open Stack AWS Azure Netconf Yang CLI 3rd Party Network controller Chef Netconf Ansible Vendor A Vendor B sVNFM EMS VNF 1 VNF 2 VNF n PNF VNF x Infrastructure OpenStack VMware RackSpace Azure ......

Backup Slides

VoLTE Use Case (Approved)

Release 1: VoLTE Allotted Resource Modeling Approach (TOSCA) Service Level (TOSCA) vIMS_Edge Service: topology_template: node_templates: vSBC (VNF): vPCSCF (VNF): VoLTE_Edge Service: topology_template: node_templates: vEPC_Edge (Allotted Resource): vIMS_Edge (Allotted Resource): “Run Time” Nesting vSBC VNF: vPCSCF VNF: “Run Time” Nesting vSPGW VNF: Service Level (TOSCA) VNF Level (TOSCA or HEAT) Allotted Resource Level Key: vEPC_Edge Service: topology_template: node_templates: vSPGW (VNF): vEPDG (VNF): vPEDG VNF:

Service Level VNF Level (TOSCA) (TOSCA or HEAT) Key: Alternative Possible Modeling Approach VoLTE Substitution Mapping Modeling Approach – Design Time View Service Level (TOSCA) VNF Level (TOSCA or HEAT) vIMS_Edge Service: topology_template: node_templates: vSBC (VNF): vPCSCF (VNF): VoLTE_Edge Service: topology_template: node_templates: vEPC (Service): vIMS (Service): “Compile Time” Nesting (For Service Designer Reuse Purposes) vSBC VNF: vPCSCF VNF: “Compile Time” Nesting (For Service Designer Reuse Purposes) vSPGW VNF: Service Level (TOSCA) VNF Level (TOSCA or HEAT) Allotted Resource Level Key: vEPC_Edge Service: topology_template: node_templates: vSPGW (VNF): vEPDG (VNF): vPEDG VNF: SDC would support the ability to construct an “upper” Service Definition from other Services definitions. One approach to this would be to use “compile time nesting”. See the next slide for the “distribution time” structure which would be distributed from such a design approach.

VNF Level Service Level (TOSCA or HEAT) (TOSCA) Alternative Possible Modeling Approach VoLTE Substitution Mapping Modeling Approach – Run Time View VNF Level (TOSCA or HEAT) Service Level (TOSCA) vIMS_Edge Service: topology_template: node_templates: vSBC (VNF): vPCSCF (VNF): vSBC VNF: vPCSCF VNF: VoLTE_Edge Service: topology_template: node_templates: vSBC (VNF): vPCSCF (VNF): vSPGW (VNF): vEPDG (VNF): groups: vIMS [vSBC, vPCSCF] vEPC [vSPGW, vPEDG] vSPGW VNF: vPEDG VNF: vEPC_Edge Service: topology_template: node_templates: vSPGW (VNF): vEPDG (VNF): “Compile time nesting” results in a substitution mapping at the time of model distribution. At that point the VoLTE_Edge Service no longer has a modeling relationship with the vIMS_Edge or vEPC_Edge services, but is rather “flattened”. All appropriate model constructs of vIMS and vEPC are inherited by VoLTE. Note that the vIMS and vEPC VNF grouping does remain in the VoLTE Model.

ETSI MANO – Network Service Instantiation Flow Orchestration Framework SDN-C and gVNF-C (APP-C) Multi-VIM Homing

ETSI MANO – VNF Instantiation Flow Orchestration Framework SDN-C and gVNF-C (APP-C) VNF Multi-VIM

ETSI Terminology network service: composition of Network Functions and defined by its functional and behavioural specification network service orchestration: subset of NFV Orchestrator functions that are responsible for Network Service lifecycle management Network Functions Virtualisation Orchestrator (NFVO): functional block that manages the Network Service (NS) lifecycle and coordinates the management of NS lifecycle, VNF lifecycle (supported by the VNFM) and NFVI resources (supported by the VIM) to ensure an optimized allocation of the necessary resources and connectivity Virtualisation Deployment Unit (VDU): construct that can be used in an information model, supporting the description of the deployment and operational behaviour of a subset of a VNF, or the entire VNF if it was not componentized in subsets NFV Infrastructure (NFVI): totality of all hardware and software components which build up the environment in which VNFs are deployed

vCPE Use Case Used in These Examples

Residential Broadband vCPE Use Case Model: vCpeResCust & vGMuxInfra Topology TOSCA HEAT TunnelXConn AllottedResource: Requirement: TunnelXConnCapability vCpeResCust Service: topology_template: node_templates: TunnelXConn (AllotRes): BRG (PNF): vG (VNF): HEAT indicates that the single vG VM is to be connected to network “vGMUX_LAN” for the vGMuxInfra Service Instance referenced. BRG PNF Resource: vG VNF Resource: VFC (single) Ext_Conn_Pt (vGMUX_LAN) vG VF Module: vGMuxInfra Service: topology_template: node_templates: vGMux_LAN (Ntw): vGMux (VNF) Capabilities: TunnelXConnCapability Local network to the cloud zone. No need to touch the WAN. So OpenStack only. vGMUX_LAN Network Resource: HEAT indicates that the single vGMUX VM is to be connected to network “vGMUX_LAN” vGMUX VNF Resource: topology_template: node_templates: VFC (single) Ext_Conn_Pt (vGMUX_LAN) Ext_Conn_Pt(vBNG_WAN) vGMUX VF Module: SDNC uses the TOSCA to determine that these connection points need to be assigned; SDNC returns a structure to SO, which SO maps to the HEAT.

vGMuxInfra Service Level Processing

vGMuxInfra Resource Level Processing (Network)

vGMuxInfra Resource Level Processing (VNF) To incorporate ARIA option, need to show that the SO Adaptor determines from the SDC Model that the VNF is described using TOSCA versus HEAT. In the former case the Adaptor will generate a TOSCA document to forward to ARIA, rather than what is shown here. Need to flesh out the interactions between HEAT and OS and ARIA and OS