Modular Orchestration and Homing of Complex Services and

Modular Orchestration and Homing of Complex Services and Allotted Resources Illustrated via Service Instantiation Examples Using a Separation of Concerns Approach which Lends Itself to N-Deep Recursive Orchestration as well as Future Potential Federation Architectures Gil Bullard – AT&T July 5 th, 2018

Orchestrator Functional Internal View Service Design & Creation OE-11 Dashboard OA&M Select Recipe Data Store Service Models OI-1 Map Request Data to Recipe & Invoke BPEL Execution Orch Service & Resource Catalog Models OI-4 OI-5 Orch Execution Engine BPMN DB Request Handler Track Requests OI-8 OI-3 OI-2 SDC Distribution Client Orchestrator Data Movement API Handler (BPMN/TOSCA) Service Level OI-15 OI-16 OI-13 Scale LCM Asgn Actv Select Adapter Template Map Data to Template Execute Transaction OI-14 OI-12 SDNC Common OI-11 Infrastructure/Network Adapter Controller functions specific only to SDNC. E. g. , “Assign Network Resources” for the VNFs in a L 4+ Service. OE-8 Multi-Cloud Controller Adapter OE-9 SDN Controller OE-10 a OE-10 b Generic NF Controller Data Movement OI-10 OI-7 Resource Level Orch OI-9 Resource/Controller Adapters OI-x SO Internal API Data Collection, Analytics, and Events Event Correlation Allotted Resources case OE-6 ONAP Optimization Framework Complex Services case / / OE-3 Micro Services Bus OE-5 External API OE-2 Store Request SO External API SO-SO communication within a single ONAP instance is via Micro Services Bus. OE-4 OE-1 OE-x DRAFT FOR DISCUSSION SO-SO communication across ONAP instances looks like an External API. Key APIs labeled on slide relative to SO for reference only. OE-7 Active & Available Inventory External Registry Controller functions common to both SDN -C and Generic NF Controller (OE-10 a for LCM, OE-10 b for App Configuration). Note that these may actually be separate APIs for SDNC and Gen. NFC 2

Orchestrator Functional Internal View – Potential Updates Use of the Façade Resource approach would eliminate OI-7 in lieu of using OI-8 for both Allotted Resources and Complex Services

Orchestration Micro-Services and Component Actors Orchestration: Generic Service Level Flow Generic VNF Resource Level Flow Generic PNF Resource Level Flow Generic Allotted Resource Level Flow Generic Façade Resource Level Flow (? ) OOF: Service Level Homing Allotted Resource Homing Façade Resource Homing (? ) Common: Decomposer Data Mapper (implicit) Other Component Actors: SDNC (Resource level): • • VNF PNF Allotted Façade (? ) App. C/GNFC (Resource level): • • • VNF PNF Allotted A&AI Multi. Cloud Service Capacity Manager (gap in Architecture? )

Major Findings from Analysis • SLOs – It seems useful to introduce the concept of “Service Level Objective” (SLO) that a lower-order Service can advertise to potential higher-order Service users. This would facilitate a method of capturing latency homing constraints/policies in such a way as to preserve separation of concerns between the Service layers. • Re: Allotted Resources – ONAP is in need of a capability/component which can answer the question “Does this (lower-order) Service instance have sufficient capacity to provide a Capability instance to this (higher-order) Service instance”? In this deck I refer to this capability/component as a “Service Capacity Manager”. • Re: Complex Services – We have to decide how to model the lower-order Service relative to the higher-order Service. Options include modeling it as a Service with a direct association, or modeling it as a Resource, a Façade Resource (the assumed modeling option). o o The Façade Resource object plays the role of the “Resource Face” of the lower-order Service to the higher -order Service. The main difference being that the Façade Resource would have an associated SDNC Controller which could make network assignments for the lower-level Service in the higher-order Service context. No clear example of the usefulness of this is known, though intuitively it seems that it is a potentially useful capability that should be allowed, all other things being equal.

Services (Instantiation Example) Network Function Services can be thought of as being comprised of Network Functions and Virtual Links ONAP management actions on service instantiation: • Decomposition (into component Network Functions and Virtual Links) • Homing • Thereafter spawn, in the proper sequence, a sub-flow per Network Function and Virtual Link

Network Functions Network Function OA&M Data Plane Network OA&M Network SLO X Data Flow From the outside, Network Functions look like: • A black box with external connection points • Some external connection points have associated SLOs (e. g. , response time assuming that internal constraints, such as HPA, have been met) From the inside, Network Functions can have: • Internal structures • Internal connection points

Service Modeling at the High Level SLO Access Point A Service Seen from the Outside Can Be Modeled to Look Like a Network Function, if we allow one to model in SDC an SLO for an overall Service • Services need to model “access points” at which Service-level latency can be measured • Services need to support a way to capture the response time (and other) SLO that the service offers • Service designers need a tool to help them calculate end to end latency for a Service

Types of Network Function and Management Thereof Types of network functions: • VNF Assuming “Modeling Approach • PNF B” described in Example 2 • Service • Allotment of a Service ONAP mgt actions on network functions: • Assign/release assignments • Create (or discover)/delete • Configure/deconfigure • Activate/deactivate The management actions applicable on network functions depend on the type of Network Function

Network Functions as a Service Versus Allotment Thereof Allotment of a Service Used as a Network Function Service_A VNF A 1 VNF A 2 Service_B Assuming “Modeling Approach B” described in Example 2 VNF B 1 Capability_Z Is Comprised Of ONAP Client Service_X Instantiation Capability_Z Instantiation Service_Z Service_X VNF X 1 ONAP Client VNF X 2 • • • VNF B 2 In this case, an instance of Service_A consumes an entire instance of Service_X. Instances of VNFs A 1, A 2, etc are chained with instances of VNFs X 1 and X 2 directly. Service_A instantiation results in instantiation of Service_X in the same manner as if Service_X were instantiated through VID • • Service_Z Instantiation VNF Z 1 VNF Z 2 In this case, an instance of Service_B consumes an instance of a particular Capability offered by Service_Z. Instances of VNFs B 1, B 2, etc are chained with instances of this Capability offered by VNFs Z 1 and Z 2. Service_B instantiation results in instantiation of this Service_Z Capability. This is different from instantiation of Service_Z itself, which would be requested through VID A single Service type (e. g. , Service_Z) can offer many Capability types

ONAP Component Views of Network Functions VNF: • SO view: comprised of VF Modules • OOF view: comprised of VF Modules, all of which are homed to the same cloud instance • Controller view: o Assign: comprised of VF Modules with connection points, which in turn are comprised if VNFCs which also have connection points. (The VNFC and its connection points are implemented on a virtual server. ) o Configure: no internal structure PNF: no internal structure Service Used as a Network Function (proposed): Assuming “Modeling Approach B” described in Example 2 • SO and OOF views: pointer to a service • Controller view: no internal structure Allotment of a Service Used as a Network Function (proposed): • SO and OOF views: pointer to a capability offered by a service • Controller view: no internal structure

Terminology Used in this Deck: Resource (with a Capital “R”) Resource Network Function Virtual Network Function (VNF) Physical Network Function (PNF) Virtual Link Service Used as a Network Function Allotment of a Service Used as a Network Function Assuming “Modeling Approach B” described in Example 2

Example 1: Introduction Via a Simple Example Service_W is comprised of two dedicated VNFs Service_W VNF_W 1 VNF_W 2

Example 1: “VNF Chaining” Data Flow for Service_W VNF_W 1 VNF_W 2 Assume that Service_W is sensitive to network latency between VNF_W 1 and the VNF_W 2. In this case, the homing algorithm will need to select cloud instances that would allow for meeting these network latency constraints.

Example 1: Service_W Modeling (Simple) Service_W Svc Instance “ 1” VNF_W 1 VNF Instance “ 1” VNF_W 2 VNF Instance “ 1” SDC Model View A&AI Instance Representation Service_W Service: topology_template: node_templates: VNF_W 1 (VNF): VNF_W 2 (VNF): VNF_W 1 VNF Resource: VNFC_W 1 (VNFC) VNF_W 2 VNF Resource: VNFC_W 2 (VNFC)

Example 1: SDC Modeling Tool for Service Designer SDC tool would allow the Service_W designer to model latency homing constraints. Service_W SLO Access Point Service_W SLO W 1 Rsp. Time<35 ms from VNF_W 1 Service_W Constraint: Network Latency<20 ms Service_W Service: topology_template: node_templates: VNF_W 1 (VNF): VNF_W 2 (VNF): VNF_W 1 VNF Resource: VNFC_W 1 (VNFC) Application Latency 5 ms Service_W Constraint: Network Latency<30 ms VNF_W 2 VNF Resource: VNFC_W 2 (VNFC) In addition, it would allow the Service_W designer to model an SLO that Service_W would offer to any “higher order services” that might want to incorporate Service_W in its service definition in a “nested” manner. The Service_W designer would need to capture in the Service_W model the point from which such an SLO is measured (in this case, from VNF_W 1). (Described more fully in subsequent slides)

Example 1 (and 2 and 3): Service Level Actors Service Level Building Blocks know the component Resources (opaque), their relationship to each other, and the measurement points for SLOs. There are two such BBs represented in the following sequence diagrams: • • Service Level E 2 E Flow: Orchestrates the Service high level operations of a Service. Displays following operations in this deck: o Incoming Requests: § Instantiate – Request a new instance of the Service in question o Orchestrates calls to: § Decompose & Home § Create Service Instance object in A&AI § Spawn Resource Level E 2 E flows in the proper sequence Service Level Homing: Service-level functionality that calls the Decomposition and Homing operations. Displays following operations in this deck: o Incoming Requests: § Decompose & Home: Knows how to decompose an instance of itself and find a home for each new resource o Orchestrates calls to: § Decompose – Calling “Decomposer Building Block” to Decompose itself into its component “Demand Types” (VNFs in this case) § A&AI – Searching for Cloud Instances that can host a VNF “Demand Type” § Packaging the Results of A&AI queries into Service Level Homing Solution

Example 1 (and 2 and 3): Resource Level Actors Resource Level Building Blocks know the details of the component Resources, such as connection points, configuration data requirements and mappings, endpoints to call for instantiation of such a Resource, etc. There is a single BB in this pattern represented in the following slides: • VNF Level E 2 E Flow: Orchestrates the high level operations of a VNF. Displays following operations in this deck: o Incoming Requests: § Instantiate – Request a new instance of the VNF in question o Orchestrates calls to: § Obtain Network Assignments – Knows the endpoint (e. g. , SDNC instance) to call to obtain such assignments. Knows how to map data from Service-level context to the inputs required in the API call. § Create VNF Instance object in A&AI § Instantiate VNF in VIM – Knows the endpoint (i. e. , Multi. VIM) to call to instantiate the VNF. Knows how to map data from Service-level context and the assignments output to the inputs required in the API call. § Configure VNF - Knows the endpoint (e. g. , GNFC instance) to call to perform the application configuration. Knows how to map data from Service-level context and the assignments output to the inputs required in the API call.

Example 1 - Simple Service Decomposition and Homing

Example 1 - Simple Service Instantiation

Example 2: Complex/Nested Service Example Service_W is comprised of a dedicated VNF and a dedicated instance of another Service (X). Service_W Service_X VNF_W VNF_X 1 VNF_X 2 Functionality of VNF_W 2 in prior example is now provided by a dedicated Service instance

Example 2: “VNF Chaining” Data Flow for Service_W VNF_W Service_X VNF_X 2 VNF_X 1

Best Viewed in Slideshow Mode Example 2: A Need for Service Level Assignments? • Would a Service_W that creates an instance of Service_X need to make any “network assignments”, in the context of Service_W, that it would expect to be used in the Service_X instantiation? • If so: o o Service_W Would Service_W consider such “assignments” to be just data mappings from a Service_W to a Service_X context? Or as true “assignments” that would be made as if Service_X were a “Resource” or Service_W? • See Modeling Approaches “A” and “B” for a study.

Example 2: Example of a Need for Service-Level Assignments? VNF_W VNF_X 2 WAN_W Subnet Assume that Service_W has a policy that each of its dedicated VNF instances must have their IP Address assigned from the same subnetwork. In such a case we would consider this subnetwork to be “owned” by the Service_W service instance, and would thus model the subnet as another Resource of Service_W. VNF_X 1 As part of VNF_X 1 and VNF_X 2 instantiation processing, the ONAP SDNC would need to know to assign their IP Addresses from this subnet. Thus, the Service_W context must be aware to pass this subnet value to the Service_X context as input to its instantiation processing. In Modeling Approach “A” this passing is done as a data mapping between contexts. In Modeling Approach “B” this “assignment” is made by a Controller.

Service_W Model Showing the Network_W 1. Make Network_W assignments, which includes assigning the subnet from which all VNF IP Addresses will be assigned. Service_W Network_W 3. SO needs to request instantiation of Service_X. To maintain separation of concerns between Service_W and Service_X, SO needs to pass in to Service_X as input parameters the previouslyassigned subnet value, in effect requesting Service_X to make its VNF_X 1 and VNF_X 2 assignments from this subnet. Subsequent slides illustrate two approaches for handling this Service_X VNF_W 2. SO calls SDNC to make VNF_W assignments. SDNC knows (working in the Service_W context) to use the Network_W subnet for the VNF_W IP assignment. VNF_X 1 VNF_X 2

Example 2: Assume that Service_W is Sensitive to Network Latency Given Service_W is sensitive to network latency between VNF_W and VNF_X 2, then the homing algorithm will need to select only cloud instances that meet such homing constraints. However, as stated before, we don’t want to write any homing (or any other) policies for Service_W in terms of the internal structure of the underlying “lower order” Service type. Instead, we will write the network latency constraint in terms of two policies, one a Service_W policy and one a Service_X policy, where the Service_X policy is written in terms of an “SLO” that it will advertise. Only the Service_X internal model (not visible from the outside) will capture from which VNF (in this case VNF_X 1) the SLO is measured (mirroring the data path).

Example 2: Defining Service Level SLOs: Service X Example Service_X Seen from perspective of a “Higher Order Service”, Service X is a “black box” that offers a (set of) SLO(s). The Service_X SLO is written relative to an “Access Point” as seen from outside of the Service X model. VNF_X 2 SLO X VNF_X 1

Example 2: Two Approaches to Modeling Approach A – Direct Reference from Higher-Order Service to Lower-Order Service. No opportunity for a Controller to make “network assignments” for the Lower-Order Service in the Context of the Higher-Order Service. Modeling Approach B – Indirect Reference from Higher-Order Service to Lower-Order Service Through a “Façade” Object, Which Makes Service_X Appear as a Resource to the Higher-Order Service. This includes the presence of an SDNC to perform assignments for the Façade Resource.

Example 2: Modeling Approach A “Services Have Services” Direct Reference from Higher-Order Service to Lower-Order Service_W Service_X VNF_W VNF_X 1 29 VNF_X 2

Example 2, Modeling Approach A: Service_W Modeling (Nested) Service_W Svc Instance “ 1” SDC Model View Service_W Service: topology_template: node_templates: VNF_W (VNF): Network_W (Ntw): Facade_W (Facade): y ar nd ou tio Se ra pa f no s. B rn VNF_W VNF Instance “ 1” Network_W Network Instance “ 1” VNF_X 1 VNF Instance “ 1” Service_X Svc Instance “ 1” VNF_X 2 VNF Instance “ 1” VNF_W VNF Resource: VNFC_W (VNFC) Network_W Network Resource: Service_X Service: topology_template: node_templates: VNF_X 1 (VNF): VNF_X 2 (VNF): A&AI Instance Representation VNF_X 1 VNF Resource: VNFC_X 1 (VNFC) Co e nc VNF_X 2 VNF Resource: VNFC_X 2 (VNFC)

General Modeling Approach Services are comprised of one or more Resources and/or (Lower-Order) Services Service Resource I. e. , Decomposition of a given Service will yield one or more Resources and/or one or more (Lower-Order) Services Network Function Virtual Network Function (VNF) Physical Network Function (PNF) Service Used as a Network Function Virtual Link Allotted Network Function (ANF) A. k. a. , “Allotted Resource”. I. e. , an Allotment of a Service Used as a Network Function Provided By

Example 2, Modeling Approach A : SDC Latency Modeling Tool for Service Designer SLO W Rsp. Time<50 ms from VNF_W Service_W Constraint: Network Latency<20 ms Service_W Service: topology_template: node_templates: VNF_W (VNF): Service_X (Service): In a more realistic example there would likely be a second Resource, a Network Resource, as part of Service_W, to provide the connectivity between VNF_W and VNF_X 1. However this has been left out of the example for simplicity. VNF_W VNF Resource: VNFC_W (VNFC) Application Latency 5 ms SLO X Rsp. Time<15 ms from VNF_X 1 Service_X Service: topology_template: node_templates: VNF_X 1 (VNF): VNF_X 2 (VNF): Service_W Constraint: Network Latency<30 ms VNF_X 1 VNF Resource: VNFC_X 1 (VNFC) Application Latency 2 ms Service_X Constraint: Network Latency<10 ms VNF_X 2 VNF Resource: VNFC_X 2 (VNFC) Application Latency 3 ms SDC tool would allow the Service_X designer to model these homing constraints. In addition, it would allow the Service_X designer to model an SLO that Service_X would offer to any “higher order services” that might want to incorporate Service_X in its service definition in a “nested” manner. The Service_X designer would need to capture in the Service_X model the point from which such an SLO is measured (in this case, from VNF_X 1).

Example 2, Modeling Approach A : SDC Latency Modeling Tool for Service Designer VNF_X 2 VNF_X 1 <-> VNF_X 2 Svc_X VNF_W<->Svc_X Svc_W Application Latency 3 2 Network Latency Cumulative Advertised Latency SLO 10 15 5 30 50 50

Example 2, Modeling Approach A : SDC Homing Policy Calculator Homing only cares about network latency, not application latency VNF_X 2 VNF_X 1 <-> VNF_X 2 Svc_X VNF_W Service_W Constraint: Network Latency<20 ms VNF_W<->Svc_X Svc_W Service_W Constraint: Network Latency<30 ms Network Latency VNF_X 1 Cumulative Advertised Latency SLO 10 15 5 VNF_X 2 Network Latency=10 ms Service_W Policy: Require SLO X from the nested Service_X Application Latency 3 2 Service_X Policy: SLO X is provided from entry point VNF_X 1 30 50 50

Example 2, Modeling Approach A : Decomposition and Homing Approach Note that, from a Service_W perspective, homing involves finding a cloud instance suitable for a new VNF_W instance such that the constraint: Latency: [geographic point on map] <-> VNF_W < 20 ms (where the geographic point is the location of the residence), and such that the “Network Latency” constraint of: “VNF_W <-> Svc_X < 30 ms” is met. This involves knowing how to measure latency between VNF_W and an instance of Service_X. However, we don’t want to violate separation of concerns between the Service_W and the Service_X processing, so we will have the Service_W homing thread pass to the Service_X homing thread a constraint that is written in terms that Service_X can understand: Latency: [geographic point on map] <-> Service_X < 30 ms (where the geographic point is a “proposed” location of the VNF_W yet to be created).

Best Viewed in Slide Show Mode Example 2, Modeling Approach A : Homing Example Illustrated For the option whereby VNF_W is located in cloud instance B, look for cloud instances within the 30 ms latency radius that meet HPA requirements for VNF_X 1. This yields A, B, C, or F. 30 ms D A 20 ms C E 30 ms B 30 ms For the option whereby VNF_W is located in cloud instance A, look for cloud instances within the 30 ms latency radius that meet HPA requirements for VNF_X 1. This yields A, B, C, and D. F For the option whereby VNF_W is located in cloud instance C, look for cloud instances within the 30 ms latency radius that meet HPA requirements for VNF_X 1. This yields A, B, C, E, and F.

Example 2, Modeling Approach A : Homing Example Illustrated Service_W context homing: • Find the set of potential cloud locations within 20 ms of the provided geographic location (the house), and which meet HPA requirements for VNF_W. This yields {A, B, C}. • Start looping through the potential cloud locations (take “A” as an example), and send a homing request to Service_X context homing to create a Service_X instance with the following constraints: – Within 30 ms of the geographic location of “A”. G 30 ms D A 20 ms C B Service_X context homing: • Find the set of potential cloud locations within 30 ms of the provided geographic location (cloud instance “A”), and which meet HPA requirements for VNF_X 1. This yields {A, B, C, D} • Start looping through the potential cloud locations for VNF_X 1 (take “D” as an example). • Find the set of potential cloud locations within 10 ms of the potential cloud location for VNF_X 1 and which meet HPA requirements for VNF_X 2 (take “G” as an example).

Example 2, Modeling Approach A : Homing Solution Example for Service_W Example 2 Resource Type Service_W VNF_W Service_W Svc_X Homing Structure Service Type Allotted Resource Provider Service Struct Homing Solution Cloud_ Instance_A OOF_Key_1 Allotted Resource Provider Service Instantiation_Needed Provider Service Struct ed bedd It m e e lly. n th retur them loca O must t ’ n s t. S ps doe OOF rather kee Key_x) tha oming : n o i t th F_ Opt res bu to SO (OO ubsequen of the u t c u n r s st a key OF in the stantiatio OOF s n r retu ain. rt in to O back would sta oming” ag oming s s a p h d H st. So woul call “ nced reque low, and he refere not, OOF f s tt Svc_X verify tha s. If it doe k d woul n still wor o i solut error. n retur Service Type Resource Type Homing Solution Service_X VNF_X 1 Cloud_Instance_D Service_X VNF_X 2 Cloud_Instance_G

Example 2, Modeling Approach A: Approach A Service-level Flow Vis a Vis Typical Service Flow Decompose (-> Decomposer) Home (-> OOF) Create Svc Inst Object (-> A&AI) Determine Sub-Flow Input Attributes Call Instantiate Sub-Flow Spawn Resource-Level Sub-Flows in Proper Sequence (-> SO) Decompose and Home component Resources and/or Services Approach A Service Flow Decompose (-> Decomposer) Home (-> OOF) Create Svc Inst Object (-> A&AI) All Service_X attributes are derived from the Service_W context. There is no opportunity to separately make “network assignments” for Service_X in the context of Service_W Determine Sub-Flow Input Attributes Call Instantiate Sub-Flow Spawn Service and/or Resource-Level Sub-Flows in Proper Sequence (-> SO)

Example 2, Modeling Approach A: Service Level Actors (Delta) Service Level Building Blocks know the component Resources (opaque), their relationship to each other, and the measurement points for SLOs. There are two such BBs represented in the following sequence diagrams: • Service Level E 2 E Flow: Orchestrates the Service high level operations of a Service. Displays following operations in this deck: o Incoming Requests: All Service_X attributes are derived from the Service_W § Instantiate – Request a new instance of the Service in question context. There is no opportunity to separately make “network o Orchestrates calls to: assignments” for Service_X in the context of Service_W § Decompose & Home § Create Service Instance object in A&AI § • Spawn Resource and Service Level E 2 E flows in the proper sequence Service Level Homing Flow: Service-level sub-flow that orchestrates the Decomposition and Homing operations. Displays following operations in this deck: o Incoming Requests: § Decompose & Home: Knows how to decompose an instance of itself and find a home for each new resource o Orchestrates calls to: § § § Decompose – Calling “Decomposer Building Block” to Decompose itself into its component “Demand Types” (VNFs and Services in this case) A&AI – Searching for Cloud Instances that can host a VNF “Demand Type” Generating “Decompose & Home” requests to a “Service Level Homing Flow” for a nested Service Packaging the Results of A&AI queries into Service Level Homing Solution Packaging the Results of “Decompose & Home” requests as an embedded structure in a Service Level Homing Solution

Example 2, Modeling Approach A: Decomposition & Homing

Example 2, Modeling Approach A: Instantiation – Page 1

Example 2, Modeling Approach A: Instantiation – Page 2

Example 2: Modeling Approach B “Services Have Resources” (Only) Indirect Reference from Higher-Order Service to Lower-Order Service Through a “Façade” Object, Which Makes Service_X Appear as a Resource to the Higher-Order Service. This includes the presence of an SDNC to perform assignments for the Façade Resource. Service_W Service_X VNF_W VNF_X 1 44 VNF_X 2

Example 2, Modeling Approach B: Service_W Modeling (Nested) Service_W Svc Instance “ 1” SDC Model View VNF_W VNF Instance “ 1” Network_W Network Instance “ 1” Façade_W Façade Instance “ 1” Service_W Service: topology_template: node_templates: VNF_W (VNF): Network_W (Ntw): Facade_W (Facade): VNF_W VNF Resource: VNFC_W (VNFC) Service_X Svc Instance “ 1” Network_W Network Resource: ns r ce S n Co Service_X Service: topology_template: node_templates: VNF_X 1 (VNF): VNF_X 2 (VNF): VNF_X 1 VNF Resource: VNFC_X 1 (VNFC) tio ra a ep f no B ry da VNF_X 1 VNF Instance “ 1” VNF_X 2 VNF Instance “ 1” Façade_W Resource: n ou A&AI Instance Representation VNF_X 2 VNF Resource: VNFC_X 2 (VNFC)

General Modeling Approach Services are comprised of Resources I. e. , Decomposition of a given Service will yield one or more Resources. Period. Resource Network Function Virtual Network Function (VNF) Physical Network Function (PNF) Façade Network Function (FNF) I. e. , a Service Used as a Network Function Virtual Link Allotted Network Function (ANF) A. k. a. , “Allotted Resource”. I. e. , an Allotment of a Service Used as a Network Function Provided By

Example 2, Modeling Approach B: Façade vs Other Resource-Level Instantiation Workflows VNF Assign (-> Controller) Create (-> Multi. VIM) Configure (-> Controller) PNF Wait for Discovery (<-Policy) Configure (-> Controller) Assign (-> Controller) Allotted Make Service_X assignments in the Service_W context, as if Service_X were a Resource. Assign (-> Controller) Create (-> Svc Level “Mgr”) Assign (-> Controller) Create (-> Svc Level BPMN Flow) Configure (-> Controller) Façade Spawn the Service_X instantiation subflow. We could also add a “Configure” step here if we were to separate the “create” from the “configure” at the Service Instantiation API.

Example 2, Modeling Approach B: Façade vs Other Resource-Level Instantiation Workflows Façade Assign (-> Controller) The “Assign” operation gives the higherorder Service the opportunity to derive any “network assignments related data” that should be provided to the lower-level Service as instantiation input parameters. Create (-> Svc Level BPMN Flow) The “Create” operation is the means through which the higher-order Service sends the instantiation request for the lowel-order Service. As part of this operation the higher-order Service can map and send any instantiation input parameters to customize the lower-order Service instance to the higher-order Service instance’s needs.

Example 2, Modeling Approach B: Creating a Façade Resource Façade_W Resource: When the service designer for a “higher order” Service wants to consume a “lower level” Service as a Resource, that Service designer would create an actual “Façade Resource” object through which to make such an association. Service_X Service: topology_template: node_templates: VNF_X 1 (VNF): VNF_X 2 (VNF): From an ONAP orchestration and control perspective, this Façade Resource cares for “assignment” and “instantiate” calls to the appropriate endpoints, but no “configure” call. Rather, any configuration parameters would be included in the “instantiate” call. VNF_X 1 VNF Resource: VNFC_X 1 (VNFC) VNF_X 2 VNF Resource: VNFC_X 2 (VNFC)

Key Example 2, Modeling Approach B: SDC Modeling Tool for Service Designer SLO W Rsp. Time<50 ms from VNF_W Service: topology_template: node_templates: VNF_W (VNF): Façade_W (Façade): Service_W Constraint: Network Latency<30 ms VNF_W VNF Resource: VFC_W (VFC) Application Latency 5 ms Façade_W Façade Resource: Providing_Service: Service_X “Lower Level Service Type” that can be instantiated in real time on an “on demand” basis Network_W not shown for simplicity Use SLO X 1 Service_W Constraint: Network Latency<20 ms SLO X Rsp. Time<15 ms from VNF_X 1 Service_X Service: topology_template: node_templates: VNF_X 1 (VNF): VNF_X 2 (VNF): Service_X Constraint: Network Latancy<10 ms VNF_X 1 VNF Resource: VNFC_X 1 (VNFC) Application Latency 2 ms VNF_X 2 VNF Resource: VNFC_X 2 (VNFC) Application Latency 3 ms

Example 2, Modeling Approach B: SDC Modeling Tool for Service Designer SLO W Rsp. Time<50 ms from VNF_W Service_W Constraint: Network Latency<20 ms Service_W Service: topology_template: node_templates: VNF_W (VNF): Façade_W (Facade): Network_W not shown for simplicity VNF_W VNF Resource: VNFC_W (VNFC) Service_W Constraint: Network Latency<30 ms Application Latency 5 ms Façade_W Façade Resource: Providing_Service: Service_X SLO X Rsp. Time<15 ms from VNF_X 1 VNF Resource: VNFC_X 1 (VNFC) Service_X Service: topology_template: node_templates: VNF_X 1 (VNF): VNF_X 2 (VNF): Application Latency 2 ms Service_X Constraint: Network Latancy<10 ms VNF_X 2 VNF Resource: VNFC_X 2 (VNFC) Application Latency 3 ms SDC tool would allow the Service_X designer to model these homing constraints. In addition, it would allow the Service_X designer to model an SLO that Service_X would offer to any “higher order services” that might want to incorporate Service_X in its service definition in a “nested” manner. The Service_X designer would need to capture in the Service_X model the point from which such an SLO is measured (in this case, from VNF_X 1).

Example 2, Modeling Approach B: SDC Modeling Tool for Service Designer VNF_X 2 VNF_X 1 <-> VNF_X 2 Svc_X VNF_W<->Svc_X Svc_W Application Latency 3 2 Network Latency Cumulative Advertised Latency SLO 10 15 5 30 50 50 Network_W not shown for simplicity

Example 2, Modeling Approach B: SDC Homing Policy Calculator Homing only cares about network latency, not application latency VNF_X 2 VNF_X 1 <-> VNF_X 2 Svc_X VNF_W<->Svc_X Svc_W VNF_W Service_W Constraint: Network Latency<20 ms Service_W Constraint: Network Latency<30 ms Network Latency Cumulative Advertised Latency SLO 10 15 5 30 50 50 VNF_X 2 Network Latency=10 ms Service_W Policy: Require SLO X from the nested Service_X Application Latency 3 2 Service_X Policy: SLO X is provided from entry point VNF_X 1 Network_W not shown for simplicity

Example 2, Modeling Approach B: Decomposition and Homing Approach Note that, from a Service_W perspective, homing involves finding a cloud instance suitable for a new VNF_W instance such that the constraint: Latency: [geographic point on map] <-> VNF_W < 20 ms (where the geographic point is the location of the residence), and such that the “Network Latency” constraint of: “VNF_W <-> Façade_W < 30 ms” is met. This involves knowing how to measure latency between the potential location of VNF_W and the potential location of Façade_W is not a real Resource that can be homed, but rather a placeholder for Service_X. We don’t want to violate separation of concerns between the Service_W and the Service_X processing, so we will have the Service_W homing thread pass to the Service_X homing thread a constraint that is written in terms that Service_X can understand: Latency: [geographic point on map] <-> Service_X < 30 ms (where the geographic point is a “proposed” location of the VNF_W yet to be created).

Best Viewed in Slide Show Mode Example 2, Modeling Approach B: Homing Example Illustrated For the option whereby VNF_W is located in cloud instance B, look for cloud instances within the 30 ms latency radius that meet HPA requirements for VNF_X 1. This yields A, B, C, or F. 30 ms D A 20 ms C E 30 ms B 30 ms For the option whereby VNF_W is located in cloud instance A, look for cloud instances within the 30 ms latency radius that meet HPA requirements for VNF_X 1. This yields A, B, C, and D. F For the option whereby VNF_W is located in cloud instance C, look for cloud instances within the 30 ms latency radius that meet HPA requirements for VNF_X 1. This yields A, B, C, E, and F. Network_W not shown for simplicity

Example 2, Modeling Approach B: Homing Example Illustrated Service_W context homing: • Find the set of potential cloud locations within 20 ms of the provided geographic location (the house), and which meet HPA requirements for VNF_W. This yields {A, B, C}. • Start looping through the potential cloud locations (take “A” as an example), and send a homing request to Service_X context homing to create a Service_X instance with the following constraints: – Within 30 ms of the geographic location of “A”. G 30 ms D A 20 ms C Service_X context homing: • Find the set of potential cloud locations within 30 ms of the provided geographic location (cloud instance “A”), and which meet HPA requirements for VNF_X 1. This yields {A, B, C, D} • Start looping through the potential cloud locations for VNF_X 1 (take “D” as an example). • Find the set of potential cloud locations within 10 ms of the potential cloud location for VNF_X 1 and which meet HPA requirements for VNF_X 2 (take “G” as an example). B Network_W not shown for simplicity

Example 2, Modeling Approach B: Homing Solution Example for Service_W Example 2 Resource Type Service_W VNF_W Service_W Façade_W Svc_X Homing Structure Service Type Provider Service Struct Homing Solution Cloud_ Instance_A Service_X OOF_Key_1 Allotted Resource Provider Service Instantiation_Needed Provider Service Struct res tructu key s d e a dd embe It returns k to e h t urn lly. bac ’t ret hem loca ust pass So n s e o t. m d OOF her keeps ) that SO g request w, t x n i lo a _ f r y but F_Ke quent hom the Svc_X erify O O ( to SO the subse tiation of F would v works n O ll in OOF start insta again. O olution sti ” s d woul ll “Homing d homing rn error. e a tu and c e referenc would re F h that t es not, OO o If it d Service Type Resource Type Homing Solution Service_X VNF_X 1 Cloud_Instance_D Service_X VNF_X 2 Cloud_Instance_G Network_W not shown for simplicity

Example 2, Modeling Approach B: Decomposition & Homing

Example 2, Modeling Approach B: Instantiation – Page 1

Example 2, Modeling Approach B: Instantiation – Page 1

Example 3: A Recursive Example Using Allotted Resources Service_W is comprised of a dedicated VNF and an allotted portion of another Service instance (i. e. , an Allotted Resource) Functionality of dedicated service instance in prior example is now provided by an “allotment” of an underlying infrastructure Service instance Service_W VNF_W AR_W Service_X 61

Example 3: “VNF Chaining” Data Flow for Service_W Example 3 VNF_W Service_X’s Allotted Resource provided by Service_Z AR_W Service_W’s Allotted Resource provided by Service_X VNF_X AR_X VNF_Zk AR_X VNF_Zj

Example 3: Assume that Service_W is Sensitive to Network Latency Given Service_W is sensitive to network latency beween VNF_W and the VNF_X that hosts AR_W, then the homing algorithm will need to select only VNF_X instances that meet the Service_W constraint. However, as stated before, we don’t want to write any homing (or any other) policies for Service_W in terms of the internal structure of the underlying “lower order” Service type. Instead, we will write the network latency constraint in terms of two policies, one a Service_W policy and one a Service_X policy, where the Service_X policy is written in terms of an “SLO” that it will advertise for the “Capability_X” that it provides. Only the Service_X internal model (not visible from the outside) will capture from which VNF (in this case VNF_X) the SLO for this Capability is measured (mirroring the data path).

Example 3: Service_W Modeling 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 Provided by: Service_X Se o ion t a un Sepa ry nda ou rns B nce f Co no ratio e c on f. C o s. B rn ry da Provided by: Service_Z r pa Service Z: topology_template: node_templates: VNF_Zj VNF_Zk capability: Z VNF_Zj VNF_Zk

Example 3: A&AI Instance Representation of Service_W Example 3 VNF_W VNF Instance “ 1” Service_W Svc Instance “ 1” Allotted. Resource_W AR Instance “ 1” Service_W’s Allotted Resource provided by Service_X Svc Instance “ 2” Service_X’s Allotted Resource provided by Service_Z VNF_X VNF Instance “ 2” Allotted. Resource_X AR Instance “ 2” Service_Z Svc Instance “ 3” VNF_Zj VNF Instance “ 3” VNF_Zk VNF Instance “ 3” In this example, the entirety of VNF_W is dedicated to the Service_W Service Instance, but only a portion (represented in A&AI as Allotted. Resource_W) of the “lower level” Service_X Service Instance is dedicated to the Service_W Service Instance. This pattern repeats itself for the other Service Instances shown. Provided by: Service_X Provided by: Service_Z

Example 3: SDC Model View Service_W Service: topology_template: node_templates: VNF_W (VNF): Allotted_Resource_W (Allot. Res): VNF_W VNF Resource: VFC_W (VFC) Allotted_Resource_W Allotted. Resource: Providing_Service: Service_X AR_W Service_X Service: topology_template: node_templates: VNF_X (VNF): Allotted_Resource_X (Allot. Res): VNF_X VNF Resource: VFC_X (VFC) Allotted_Resource_X Allotted. Resource: Providing_Service: Service_Z AR_X Service_Z Service: topology_template: node_templates: VNF_Zj (VNF): VNF_Zk (VNF): VNF_Zj VNF Resource: VFC_Zj (VFC) VNF_Zk VNF Resource: VFC_Zk (VFC) AR_X

Example 3: Defining Capability Level SLOs: Service Z Example Seen from perspective of a “Consuming Service”, Service Z is a “black box” that provides a Capability Z that offers a (set of) SLO(s). Capability Z Offers: Capability Z “Capability Access Point” as seen from outside of the Service Z model. SLO Z 1 When configuration “P” is applied to its Capability Z, Service Z will offer a Response. Time<30 ms, measured from its Capability Access Point (i. e. , not counting network latency) SLO Z 2 When configuration “Q” is applied to its Capability Z, Service Z will offer a Response. Time<20 ms, measured from its Capability Access Point (i. e. , not counting network latency) AR VNF_Zk SLO Z 1 SLO Z 2 AR VNF_Zj Inside the Service Z model is the definition as to how the Capability Z “Capability Access Point” maps to actual VNF external connection points.

Key Example 3: SDC Modeling Tool for Service Designer SLO W 1 Rsp. Time<65 ms from VNF_W Service: topology_template: node_templates: VNF_W (VNF): Allotted_Resource_W (AR): SLO X 1 Rsp. Time<30 ms from VNF_X Service_W Constraint: Network Latency<20 ms VNF_W VNF Resource: VFC_W (VFC) Application Latency 5 ms “Lower Level Service Type” that can be instantiated in real time on an “on demand” basis Service_W Constraint: Network Latency<30 ms Allotted_Resource_W AR: Providing_Service: Service_X Use SLO X 1 Service_Z Constraint: Affinity: Co-Located SLO X 1 Service_X Service: topology_template: node_templates: VNF_X (VNF): Allotted_Resource_X (AR): VNF_X VNF Resource: VFC_X (VFC) Application Latency 5 ms Service_X Constraint: Affinity: Co-Located Allotted_Resource_X AR: Providing_Service: Service_Z Use SLO Z 2 SLO Z 1 Response. Time<30 ms at VNF_Zj, if Svc. Instance created with configuration “P” (not counting network latency) SLO Z 2 Response. Time<20 ms at VNF_Zj, if Svc. Instance created with configuration “Q” (not counting network latency) SLO Z 1 SLO Z 2 Service_Z Service: topology_template: node_templates: VNF_Zj (VNF): VNF_Zk (VNF): Capabilities: Capability_Z VNF_Zj VNF Resource: VFC_Zj (VFC) Application Latency 16 ms VNF_Zk VNF Resource: VFC_Zk (VFC) Application Latency 4 ms

Example 3: SDC Modeling Tool for Service Designer VNF_Zk VNF_Zj VNF_Zk <-> VNF_Zj Svc_Z Application Latency 4 16 Network Latency Cumulative Advertised Latency SLO 0 20 VNF_X<->Svc_Z Svc_X 5 VNF_W<->Svc_X Svc_W 5 0 25 30 65 65 30

Example 3: SDC Homing Policy Calculator VNF_W Service_W Constraint: Network Latency<20 ms Service_W Constraint: Network Latency<30 ms Service_W Policy: Require SLO X 1 from the hosted Service_X instance AR_W VNF_X Instance AR_X VNF_Zk Instance Network Latency=0 ms Affinity: Collocated AR_X VNF_Zj Instance Service_X Policy: SLO X 1 is provided from entry point VNF_X Service Y Policy: Require SLO Z 1 from the hosted Service_Z instance Service_Z Policy: SLO Z 1 is provided from entry point VNF_Zj

Example 3: Decomposition and Homing Approach Note that, from a Service_W perspective, homing involves finding a cloud instance suitable for a new VNF_W instance such that the constraint: Latency: [geographic point on map] <-> VNF_W < 20 ms (where the geographic point is the location of the residence), and such that the “Network Latency” constraint of “VNF_W <-> AR_W < 30 ms” is met. This involves knowing that the Providing Service for AR_W is Service_X. It also involves knowing how to measure latency between VNF_W and an instance of Service_X. However, we don’t want to violate separation of concerns between the Service_W and the Service_X processing, so we will have the Service_W homing thread pass to the Service_X homing thread a constraint that is written in terms that Service_X can understand: Latency: [geographic point on map] <-> Service_X < 30 ms (where the geographic point is a “proposed” location of the VNF_W yet to be created). If an appropriate cloud instance and Service_X service instance is found, then homing is complete. However, if no such Service_X instance exists (i. e. , OOF Service_X homing thread returns an exception), homing can determine that a new one should be created “on demand. ” In such a case, we want to take a separation of concerns approach whereby the Service_W homing thread can delegate down to a Service_X homing thread for further solutioning based on the input constraint (< 30 ms).

Example 3: For the option whereby VNF_W is located in cloud instance A, look for a suitable Service_X instance in cloud instances A, B, C, or D. If none are found, then perhaps a Service X instance could be created in one of these. Homing Example Illustrated For the option whereby VNF_W is located in cloud instance B, look for a suitable Service_X instance in cloud instances A, B, C, or F. If none are found, then perhaps a Service X instance could be created in one of these. 30 ms D A 20 ms C E 30 ms B 30 ms F For the option whereby VNF_W is located in cloud instance C, look for a suitable Service_X instance in cloud instances A, B, C, E, or F. If none are found, then perhaps a Service X instance could be created in one of these.

Example 3: Homing Example Illustrated Service_W context homing: • Find the set of potential cloud locations for VNF_W as {A, B, C}. • Start looping through the potential cloud locations (take “A” as an example), send a homing request to Service_X context homing to find a Service_X instance with the following constraints: – Able to provide Capability “X” with SLO X 1 – Within 30 ms of the geographic location of “A”. Service_Z context homing: • Look for a Service_Z instance in location “D” able to provide the desired Capability and SLO. 30 ms D A 20 ms C B Service_X context homing: • Find the set of potential cloud locations within 30 ms of the provided geographic location “A”: {A, B, C, D} • Service_X context knows that its SLO is measured from VNF_X. Look for VNF_X instances in those cloud locations. • If no such instance is found, then determine whether it is admissible to create an instance on demand. In this case it is, so: – Find the set of potential cloud locations for VNF_X as {A, B, C, D} – Start looping through the potential cloud locations (take “D” as an example), send a homing request to Service_Z context homing to find a Service_Z instance with the following constraints: § Able to provide Capability “Z” to with SLO Z 2 § Located within geographic location “D”.

Example 3: Homing Example Flow Maybe the Separation of Concerns should be preserved through the “Abstract” node and not through the Allotted Resource. Perhaps an Allotted Resource, being a real “Resource”, does know its own implementation. SO sends OOF a Service_W homing request, providing as an input constraint the geographic location of the residence. OOF Service_W homing will comprise homing for VNF_W and AR_W. OOF homing for VNF_W will find eligible VNF_W cloud instances that meet the 20 ms latency constraint with the residence. OOF homing for AR_W will, looping through the potential VNF_W cloud instances, look for the set of Service_X instances to provide that AR_W functionality that meet the 30 ms latency constraint with that cloud instance. Measuring latency between a VNF instance and a Service instance requires understanding of the implementation of that Service instance. I. e. , what is the point from which the measurement is made?

Example 3: Homing Example Flow (Cont’d) However, we want to maintain a separate of concerns approach, and the Service_W processing thread shouldn’t know the implementation of Service_X such that it can measure latency to it. (This can be best seen in the Service_Z example to the right. ) Thus, we will have the Service_W OOF homing request thread delegate selection of the optimal Service_X instance to a subtending Service_X OOF thread. Thus, OOF can be seen as (logically, in a depth-first manner) calling itself with a Service_X homing request. This request must be fed the appropriate input constraints, such as the geographic location of the associated eligible VNF_W cloud instance and the SLO needed, in this case SLO X 1.

Example 3: Homing Example Flow (Cont’d) Service_X homing knows that SLO X 1 is measured from an access point on VNF_X. Thus Service_X homing is comprised of looking for the set of viable Service_X instances whose VNF_X instance is within 30 ms of the input geographic location. If at least one such Service_X instance is found, homing is done (except for optimization). then If no such Service_X instance can be found, an error is returned to the Service_W context which will determine whether to request dynamic instantiation of a new Service_X instance. The remaining slides assume that such dynamic instantiation is possible and desired.

Example 3: Homing Example Flow (Cont’d) OOF Service_X homing will comprise homing for VNF_X and AR_X. OOF homing for VNF_X will find eligible VNF_X cloud instances that meet the 30 ms latency constraint with the input geographic location. OOF homing for AR_X will, looping through the potential VNF_X cloud instances, look for the set of Service_Z instances to provide that AR_X functionality that meet the 0 ms latency constraint with that cloud instance. The pattern recurs, however, that Service_X has no business understanding whether the 0 ms latency constraint should be measured from VNF_Zj or VNF_Zk, or even in fact that there exists a VNF_Zj or VNF_Zk. In order to maintain separation of concerns, homing of AR_X will be delegated to a subtending request thread delegate selection of the optimal Service_Z instance to a subtending Service_Z OOF thread.

Example 3: Homing Example Flow (Cont’d) Service_Z homing will thus search for eligible Service_Z instances such that the 0 ms constraint is measured from the input geographical location (in this case the potential cloud instance location for VNF_X) to an available VNF_Zj instance (the point from which the Service_Z SLO is measured). If no such Service_Z instance can be found, then homing will determine whether the Service_Z service definition allows for dynamic instantiation of new Service_Z instances. In this case we will assume “no”, so the OOF Service_Z homing thread would return an exception to the calling Service_X homing thread. Such an exception would likely not result in failure of the entire Service_W or even Service_X homing, but rather simply progressing to the next potential solution in the appropriate loop.

Example 3: Homing Solution Example for Service_W Example 3 Resource Type Service_W VNF_W Service_W Allotted_Resource_W Allotted Resource Provider Service Struct Homing Solution Cloud_Region_1 Service_X Service Type Resource Type Service_X VNF_X Service_X Allotted_Resource_X AR_X Homing Structure AR_W Homing Structure Service Type Instantiation_Needed OOF_Key_1 Allotted Resource Provider Service Struct ed bedd It m e e lly. n th retur them loca O must t ’ n s t. S ps doe OOF rather kee Key_x) tha oming : n o i t th F_ Opt res bu to SO (OO ubsequen u t c u r s st ey he ns a k F in t retur ck to OO ba pass t. s reque Homing Solution Cloud_Region_2 Service_Z Service Z Instance Id OOF_Key_2 Service Type Resource Type Reservation Id Svc_Z Capability_Z Res#

Svc Level Homing MS : Knows the component Resources (opaque), their relationship to each other, and the measurement points for SLOs. Supports 2 APIs: - Inquiry: Knows how to find an instance of itself given homing constraints. Includes knowing from which point to measure latency. Service Level Building Blocks know the component Resources (opaque), their relationship- to each other, measurement points Decompose & Home: and Knowsthe how to decompose an instance of itself and find a home for each new resource. for SLOs. There are two such BBs represented in the following sequence diagrams: AR Level Homing MS : Knows the implementation “factory” of • Service Level E 2 E Flow: Orchestrates the Service high level operations of a Service. Displays following operations itself. in this deck: Supports an API: o Incoming Requests: - Home: Knows how to reach out to the factory and ask to § Instantiate – Request a new instance of the Service in question reserve resources for a new instance implementation of itself. Svc Level Capacity Mgr: § Inquiry – (Not shown) - Inquiry: Knows whether it has sufficient resources among its o Orchestrates calls to: own “Capability Resources” to provide a new Capability § Decompose & Home instance. Example 3: Service Level Actors (Delta) • § Create Service Instance object in A&AI § Spawn Resource Level E 2 E flows in the proper sequence Service Level Homing : Service-level functionality that calls the Decomposition and Homing operations. Displays following operations in this deck: o Incoming Requests: § § o Inquiry – Knows how to find an instance of itself given homing constraints. Includes knowing from which point to measure latency. Decompose & Home: Knows how to decompose an instance of itself and find a home for each new resource Orchestrates calls to: § Decompose – Calling “Decomposer Building Block” to Decompose itself into its component “Demand Types” (VNFs and Allotted Resources and Services in this case) § § § A&AI – Searching for Cloud Instances that can host a VNF “Demand Type” Generating “Home” requests to an “Allotted Resource Homing Flow” for a nested Service Generating Service-level “Decompose & Home” requests to a “Service Level Homing Flow” for a nested Service Packaging the Results of A&AI queries into Service Level Homing Solution Packaging the Results of Allotted Resource “Home” requests as an embedded structure in a Service Level Homing Solution Packaging the Results of Service-level “Decompose & Home” requests as an embedded structure in a Service Level Homing Solution

Example 3: Service Capacity Manager The Service Capacity Manager knows the implementation of a particular Capability type provided by a Service instance, and manages the capacity of that Service instance relative to that Capability. : • Service Level Capacity Manager o Incoming Requests: § § o Inquiry – Knows whether it has sufficient resources among its own “Capability Resources” (e. g. , VNFs that cooperatively produce the Capability) to provide a new Capability instance. Can make reservations for future (short term) instantiation of such a Capability for a higher-order Service’s Allotted Resource. Create Allotted Resource – Knows how to create a new Capability instance in the resources that comprise the Service instance Orchestrates calls to: § The Network Functions (e. g. , Net. Conf APIs) to create the new Capability instance

Example 3: Resource Level Actors (Delta) Resource Level Building Blocks know the details of the component Resources, such as connection points, configuration data requirements and mappings, endpoints to call for instantiation of such a Resource, etc. In addition to those introduced in prior examples, there is an additional BB in this pattern represented in the following slides: • • Allotted Resource Level Homing Flow: Resource-level sub-flow that orchestrates the Decomposition and Homing operations for an Allotted Resource. Displays following operations in this deck: o Incoming Requests: § Home – Knows how to call decomposition to determine the providing Service type and Capability. o Orchestrates calls to: § Decompose – Calling “Decomposer Building Block” § Inquiry – Calling the appropriate Service Capacity Manager for the providing Service to determine ability to produce a Capability instance. § Packages the inquiry response as a “Homing Solution” response to the calling (consuming) Service. § Model Interactions – In the event of a failed Inquiry response, can determine from the model whether Allotted Resource policies allow for dynamic instantiation of underlying Capability instance. § Decompose & Home – Calling providing Service requesting Decomposition/Homing for a new providing Service instance. Allotted Resource Level E 2 E Flow: Orchestrates the high level operations of an Allotted Resource. Displays following operations in this deck: o Incoming Requests: § Instantiate – Request a new instance of the Allotted Resource in question o Orchestrates calls to: § Obtain Network Assignments – Knows the endpoint (e. g. , SDNC instance) to call to obtain such assignments. Knows how to map data from Service-level context to the inputs required in the API call. § Create Allotted Resource Instance object in A&AI § Instantiate Allotted Resource – Knows the endpoint (i. e. , providing Service Capacity Manager) to call to instantiate the Allotted Resource. Knows how to map data from Service-level context and the assignments output to the inputs required in the API call. § Configure Allotted Resource - Knows the endpoint (e. g. , GNFC instance) to call to perform the application configuration. Knows how to map data from Service-level context and the assignments output to the inputs required in the API call.

Example 3: Sequence Diagram Examples Decomposition and Homing Instantiation

Example 3: Decomposition and Homing – Page 1

Example 3: Decomposition and Homing – Page 2

Example 3: Decomposition and Homing – Page 3

Example 3: Decomposition and Homing – Page 4

Example 3: Instantiation – Page 1

Example 3: Instantiation – Page 2

Example 3: Instantiation – Page 3

Example 3: Instantiation – Page 4

Example 3: Instantiation – Page 5