1. ONAP Dublin Architecture Requirements
Stephen Terrill, et al.

2. Input
Material input is the Dublin Architecture F2F meeting (Montreal) and subsequent discussions.
More information is available here: +Requirements

3. Service Mesh – Using K8s and ISTIO as infrastructure for ONAP
Leverage Kubernetes.
Dublin Scope:
Use native K8S facilities (IPVS) for service load balancing.
Use K8S Network policies for RBAC (At the service granularity, not at the HTTP protocol level)
Prove few application services  using ISTIO citadel using nodeagent and create guideline document
POCs with the ISTIO/Envoy community to reduce the memory footprint of Envoy proxy.
Secure communication (refer to ONAP security sub-committee)
Direction:
use of ISTIO, tightly integrated via ENVOY, as a “REFERENCE”.
PoC during Dublin timeframe, using in Dublin if ready
Back end integration to AAF.
AAF/CADI direction still supported

4. Model-driven Distributed Analytics (1)
Still architecture discussions on how to instantiate the edge placed analytics
Model-driven Distributed Analytics (1)
ONAP
Analytics App Repo & Mapping with VNF & Service management
APPC
Kafka Broker
Analytics instance registration management
Policy/CLAMP
Distributed Deployment Manager
Model Management
Kafka Across LAN/MAN/WAN
API (REST etc.)
ONAP Normalizer &
Dispatcher
Cloud Infra Event/Alert/Alarm/Fault Normalization (Multi Cloud Micro Services)
VNF/App Event/Alert/Alarm/Fault Normalization
Kafka Client based Dispatcher
Third party edge workload (Analytics etc.)
ONAP-Edge workload (Analytics etc.)
PNDA+
Analytics Application/Framework are packaged together
VMware
Kafka
Deployment Manager
Apps
Training at the regional sites and inference at the edges.
Both at the edges
Both at the regional sites
Apache Spark
HDFS
Kafka
Collection & transformation
Edge1
Edge2
Edge n
Edge1
Edge2
Edge m
Source:

5. Model-driven Distributed Analytics (2)
Ambition: Support distributed (Edge) analytics
Dublin Focus:
Support ONAP-based and 3rd Party Analytics Applications
Analytics applications are treated the same as ONAP VNF workloads
Use VNF deployment (VM/Container) workflow for analytics application deployment
Normalization at the edge for Cloud Infra Event/Alert/Alarm/Faults
Details:
Presentation:
End-to-end use cases:
vFW, vCPE (TBD), 5G (TBD)

6. Fine-grained Placement Service (F-GPS)
Ambition: Support fine-grained placement
Dublin Focus:
Support fine-grained placement in a specific Distributed DC/Availability zone proximal to a group of users for latency sensitive workloads
Details:
Presentation:
Leverage capacity alerts (significant change in capacity) from Model-driven Distributed Analytics work
End-to-end use cases: 5G

7. K8s Cloud region support (1/2)
Continue the journey of support for contain based VNFs.
SDC to support K8S Helm charts as artifacts in VNF CSAR
SDC to support multiple cloud technology artifacts in one VNF CSAR.
Note: This is the case where the same VNF executable can run in different cloud environments.
VNF SDK to support the validation of VFND based on Helm changes and also a VNFD supporting multiple cloud technologies
VNF Requirements to describe requirements on a VNFD CSAR
SO to be made independent of Cloud technology
SO to pass userParams of 'createVNF' NB API to Multi-Cloud.
CLI and VID to take userParams as input from the user
Testing SO ability to bypass assignment functionality in SDNC
Ensure (fix any gaps) needed to put information of containers in A&AI such as IP address assigned to it, VNF instance ID returned by Multi-Cloud.

8. K8s Cloud region support (122)
Multi-Cloud
SDC Client for artifact distribution.
Helm based implementation
Upgrade functionality (Change management) [Stretch]
Finish R3 functionality (OVF, Helm, VNF environments etc..)
Testing to Ensure that current closed loop (with vFirewall) works end- to-end.
Testing to Ensuring that change management functionality continues to work.

9. Modularity (1/2) Definitions
Module: Implements a business capability accessed through a defined set of APIs
E.g. A DCAE Data Collector microservice, A&AI data repository
Component: A collection of modules that are related in some form
E.g. SO, Controllers, A&AI, etc
ONAP: A collection of ONAP Components
Microservice: Small, single-capability focused, standalone services E.g. IP address assignment, Tosca parser
Cloud-Native: Container-packaged, dynamically managed, microservicesoriented applications
E.g. Containerized microservices managed by Kubernetes
Service Mesh: Connective tissue between microservices
E.g. traffic control, resiliency, security, observability Control plane (Istio, linked) and Data plane (Envoy, linkerd) Note: This is different from service chaining

10. Modularity (2/2) Start small. Start with SO and Controllers. SO:
API handler
Request DB
BPMN Infra
SDC controller
Catalog Adapter
Adapters for the controllers (SDNC/VFC/…) and
Cloud Adapter
Controllers:
IP assignment
Tosca Parser
Proposal: Discussion with projects

11. ETSI Alignment VNFM plug-in to SO:
SO, SOL003 plug-in
SDC, indicate of whether to use VNFM
A&AI: VNF/VF Instance <-> VNFM instance
Other scenarios proposed, more work to do. (not sufficient arch discussions yet)
SOL005 between SO and ETSI defined NFVO
Exposing SOL005 NBI from ONAP
ONAP connection of VNF through SOL002
ETSI Stds i/f
ETSI defined VNFM
SOL003 SO
SOL005
ETSI defined NFVO
SOL005
ONAP
ONAP
SOL002
VNF

12. Joint Arch // Modelling issues
Modelling a Allotted network function
An allotted network function is a network function where part of its capability is allocated to a service.
A number of steps are defined over a few release, starting with the VNFs.
NSD modelling
Does the NSD have to be explicitly modelled or can it use the ONAP defined services.
Note: There is agreement that we need a way to represent a NSD somehow.
Support of SOL001 v2.5.1
Orchestration Scenarios
What are the driving network scenarios for ETSI-ONAP alignment. Ongoing.

13. Architectural Support for 5G use cases
Covered in 5G Use Case work.
Retained as a placeholder for deepdives if required.

14. General Increase / Evolve the Architecture documentation
Architecture evolution roadmap

15. TOSCA Task Force Priority Requirement 1
There is a Tosca Task Force with the following objectives:
Establish TOSCA as the "normative", supplier/operator neutral way to package and describe (model) network service and functions in ONAP.
Enable template reuse and orchestration outcome consistency across ONAP related on-boarding, design, instantiation and operation activities.
Identify TOSCA adoption barriers/gaps and recommend closure actions.
Priority
Requirement 1
Support for ETSI NFV SOL001 specification v2.5.1 templates
Support for for TOSCA Simple YAML Profile v1.2 and v1.3 2
Support for multiple flavors/versions of TOSCA VNFD templates
Support for multiple versions of TOSCA language/grammar 3
A "registry" approach for configurable and modifiable properties
Preservation of original on-boarded template semantics and content

16. Reviewed usecases and projects
Reviewed and OK:
Broadband Service (BBS)
5G use cases (at Arch F2F)
Still requires further re-review
ONAP data lake
OSAM
CDI (composible desagretated infrasrtructure)

17. Contacts Topic Contact Service Mesh Mike Elliot, Srini Addepali
Model driven (or distributed at edge) Analytics
Srini Addepali, ramki krishnan
Fine-Graned Placement Service
ramki Krishnan
K8s cloud region support
Srini Addepali
Modularity
Vmial Begwani, John Ng, Seshu Kumar
ETSI Alignment (SO plug-in)
Ciaran Murphy, byung.woo Jun, Fred Oliverira (overall orchestration scenarios)
VFC team for VFC enhancements
Tosca Task force
Alex Vul
Alloted Network Function
Gill Bullard

19. Distributed Data Analytics
Ambition: Support distributed (Edge) analytics
Dublin timeframe: Focus on instantiate of edge DCAE
Still under discussion: How to instantiate the edge DCAE, what is instantiated and the trigger.
Stretch goal:
Send signature from Edge DCAE to central DCAE
Central DCAE
Edge DCAE
connectivity
Central site
Edge site