FUNCTIONAL Architecture for R 2 can be exposed

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

Terminology Mapping ONAP Service Orchestration Resource Orchestration Cloud Resource Orchestration Network 2 Network Service (Infrastructure Services only) (2) Network Service Orchestration (2) VNF and Network (NFVI) network resources (3) Specific NFVO functions that manage or coordinate the VNF or NFVI network resource’s lifecycle (3) NFVI compute, storage, network Functions, perhaps provided by the underlying Cloud Provider (4), that manage or coordinate the NFVI compute, storage, network resource’s lifecycle An NFVI resource Allotted Resource (5) This concept is not discussed in MANO VF Module Virtualisation Deployment Unit (VDU) VF Component Because of this, ETSI TERMINOLOGY IN AND OF ITSELF IS NOT SUFFICIENT TO DESCRIBE THE ONAP PROBLEM SPACE. ETSI MANO (1) VNFC 1) Ref: ETSI - NFV Terminology for Main Concepts in NFV 2) 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. 3) Concept of “Allotted Resource” is not discussed in MANO. The concept of “PNF” seems to be out of scope for an NFV-MANO implementation. 4) For example, the orchestration provided by Open. Stack HEAT 5) 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 – v. PE/VRF Example 4 An instantiation request for a L 3 VPN_Cust Service would result in a VRF being instantiated. That VRF would be “homed” to an existing v. PE_Infra Service instance (i. e. , the v. PE VNF instance on which this VRF will be configured). L 3 VPN_Cust Service: topology_template: node_templates: VRF “Higher Level” Service 1 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. 2 In this case, the v. PE VNF has been packaged as an Infrastructure Service. An instantiation request for this v. PE_Infra Service would result in a new v. PE VNF being instantiated. VRF Allotted Resource requirement: VRF_Capability “Lower Level” Service v. PE VNF 3 3 The v. PE_Infra Service exposes a capability to provide “VRFs” (a “VRF_Capability”). The L 3 VPN_Cust Service consumes this capability through its “VRF Allotted Resource” construct. v. PE_Infra Service: topology_template: node_templates: v. PE VNF v. PE_Network capability: VRF_Capability Network

Model-Driven Orchestration “Generic” model-driven Service flow (limited existing) Service Orchestration Resource Orchestration PNF Service X: topology_template: node_templates: PNF Network VNF Allotted Resource Cloud Resource Orchestration VF Module Network Note recursion VNF Allotted Resource requirement: A 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 2 nd level of Service Orchestration. Service Y is being treated as a “Resource” from the perspective of Service X. 4 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 PNF Service Y: topology_template: node_templates: PNF Network VNF Allotted Resource capability: A Network 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 5

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). 6

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

Backup Slides 8

Vo. LTE Use Case (Approved) 9

Release 1: Vo. LTE Allotted Resource Modeling Approach Resource (TOSCA) Service Level (TOSCA) Vo. LTE_Edge Service: topology_template: node_templates: v. EPC_Edge (Allotted Resource): v. IMS_Edge (Allotted Resource): “Run Time” Nesting v. IMS_Edge Service: topology_template: node_templates: v. SBC (VNF): v. PCSCF (VNF): “Run Time” Nesting Key: Service Level (TOSCA) VNF Level (TOSCA or HEAT) Allotted Resource Level (TOSCA) 10 v. SBC VNF: v. PCSCF VNF: v. SPGW VNF: v. EPC_Edge Service: topology_template: node_templates: v. SPGW (VNF): v. EPDG (VNF): v. PEDG VNF:

Alternative Possible Modeling Approach Vo. LTE Substitution Mapping Modeling Approach – Design Time View Service Level (TOSCA) Vo. LTE_Edge Service: topology_template: node_templates: v. EPC (Service): v. IMS (Service): Key: Service Level (TOSCA) VNF Level (TOSCA or HEAT) “Compile Time” Nesting (For Service Designer Reuse Purposes) v. IMS_Edge Service: topology_template: node_templates: v. SBC (VNF): v. PCSCF (VNF): v. PCSCF VNF: v. SPGW VNF: v. EPC_Edge Service: topology_template: node_templates: v. SPGW (VNF): v. EPDG (VNF): Allotted Resource Level (TOSCA) 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. 11 v. SBC VNF: v. PEDG VNF:

Alternative Possible Modeling Approach Vo. LTE Substitution Mapping Modeling Approach – Run Time View Service Level (TOSCA) v. IMS_Edge Service: topology_template: node_templates: v. SBC (VNF): v. PCSCF (VNF): Vo. LTE_Edge Service: topology_template: node_templates: v. SBC (VNF): v. PCSCF (VNF): v. SPGW (VNF): v. EPDG (VNF): groups: v. IMS [v. SBC, v. PCSCF] v. EPC [v. SPGW, v. PEDG] 12 VNF Level (TOSCA or HEAT) v. SBC VNF: v. PCSCF VNF: v. SPGW VNF: v. PEDG VNF: v. EPC_Edge Service: topology_template: node_templates: v. SPGW (VNF): v. EPDG (VNF): “Compile time nesting” results in a substitution mapping at the time of model distribution. At that point the Vo. LTE_Edge Service no longer has a modeling relationship with the v. IMS_Edge or v. EPC_Edge services, but is rather “flattened”. All appropriate model constructs of v. IMS and v. EPC are inherited by Vo. LTE. Note that the v. IMS and v. EPC VNF grouping does remain in the Vo. LTE Model.

ETSI MANO – Network Service Instantiation Flow Orchestration Framework Homing 13 SDN-C and g. VNF-C (APP-C) Multi-VIM

ETSI MANO – VNF Instantiation Flow Orchestration Framework 14 SDN-C and g. VNF-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 15

v. CPE Use Case Used in These Examples

Residential Broadband v. CPE Use Case Model: v. Cpe. Res. Cust & v. GMux. Infra Topology TOSCA v. Cpe. Res. Cust Service: topology_template: node_templates: Tunnel. XConn (Allot. Res): BRG (PNF): v. G (VNF): v. GMux. Infra Service: topology_template: node_templates: v. GMux_LAN (Ntw): v. GMux (VNF) Capabilities: Tunnel. XConn. Capability HEAT Tunnel. XConn Allotted. Resource: Requirement: Tunnel. XConn. Capability BRG PNF Resource: v. G VNF Resource: VFC (single) Ext_Conn_Pt (v. GMUX_LAN) HEAT indicates that the single v. G VM is to be connected to network “v. GMUX_LAN” for the v. GMux. Infra Service Instance referenced. v. G VF Module: Local network to the cloud zone. No need to touch the WAN. So Open. Stack only. v. GMUX_LAN Network Resource: v. GMUX VNF Resource: topology_template: node_templates: VFC (single) Ext_Conn_Pt (v. GMUX_LAN) Ext_Conn_Pt(v. BNG_WAN) HEAT indicates that the single v. GMUX VM is to be connected to network “v. GMUX_LAN” v. GMUX 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.

v. GMux. Infra Service Level Processing

v. GMux. Infra Resource Level Processing (Network)

v. GMux. Infra 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