Lead: Parviz Yegani
Mailing list: onap-arch-tiger-team (email Parviz or Chris)
ONAP target architecture (R2 and beyond):
ONAP Target Architecture
The target architecture is currently being developed by the tiger team using a set of design principles listed below. These principles were reviewed and agreed upon by the Architecture Subcommittee, See the link below for details:
- ONAP is a layered architecture – Orchestration, Multi-Cloud, Controller, etc.
- Functional role of each layer should be well defined per the aforementioned architecture principles.
- ONAP should support integrated design studio to capture full life-cycle management models (TOSCA models for NF, simple / nested services augmented with BPMN, Policy / Analytic design models, etc.).
- ONAP Should Support Cloud Agnostic Model and Multi-Cloud adaption layer while hiding infrastructure details.
- ONAP Target Goal is: Modular, Model-driven, Microservices-based architecture.
- Models drive interfaces between layers/components.
- ONAP should define well-described and consistent NB-APIs at all layers.
- Keep flexible capability for commercial solution (no vendor lock-in).
- Agree to unified modeling for integration across all modules: VES in DCAE, Logging & monitor inside ONAP and more.
Below is the latest R2+ architecture deck. It's also located at: https://wiki.onap.org/display/DW/Contributions
- py20180102 ONAP R2+ Architecture Proposal
Architecture Tiger Team Weekly Meeting
Meeting Information (Fridays):
| UTC 03:00 PM | China 11:00 PM | Eastern 10:00 AM | Pacific 07:00 AM |
IRC: TBA
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/947468849
US numbers:
+16699006833,or
+16465588656,
Meeting ID: 947 468 849
International numbers available: https://zoom.us/zoomconference?m=Cf5Ha4SNAxTeBbkwwbCfPmJhrz-mZrJ0
Agenda - Architecture Tiger Team Weekly (08-JAN-2018)
Note - All contributions on functional description of the ONAP components should be documented using the attached template:
I. Recommendations (from Architecture Tiger Team to Projects/PTLs) – Parviz (30 min)
Steps towards target architecture
In ONAP we need to take incremental steps toward a modular, microservices-based, model-driven architecture. More specifically, we should take necessary measures to migrate the functionality of the current monolithic legacy system to support cloud-native deployment models. To achieve this goal we may need to consider the following:
- Modular:
- Improve APIs between components. Document them using Swagger to improve alignment between components
- Align interfaces with industry standards, where available/appropriate (e.g., ETSI SOL-005, MEF SONATA, etc.)
- Microservices-based
- Use OOM for instantiation (support MSB natively)
- Register with MSB
- Use microservices best practices (e.g., separate data from the component, use common KV stores/databases, for KV stores – prefer Consul, etc.)
- Model-driven
- Align with data models from the Modeling Subcommittee (published last month)
- Explore ways to use model-driven principles inside each component
- S3P
- Use common libraries/SDKs/common services for S3P enhancements to improve overall system resiliency/reliability
- More focus on common services (where possible) also to help reduce testing
Some other considerations
- External APIs: Customers view ONAP as a black box. This should simplify the ONAP architecture/interfaces, leveraging the APIs developed by the Ext API project.
- Database migration: All databases of the ONAP platform (ie, MySQL relational database management system) should migrate to MariaDB in R2.
- API Improvements: Currently, ONAP internal interactions are mostly handled via REST-like APIs. We need to enhance the ONAP architecture to support RESTFUL APIs. We also need to ensure that the ONAP platform can handle cloud-native APIs and models.
- Versioning Support: Currently, the ONAP architecture doesn’t seem to support versioning (at least in a consistent manner).
- Support for Identity Management in SDC
- Support for Security Management in SDC – Kubernetes in OOM may provide this feature in R2. Needs clarification!
- Promote DevOps operations model
- Support for a full-blown containerization
- Support for Homing in R2
- Geo-redundancy – move from real-time (strong) consistency to eventual consistency model
- Multi-tenancy support
- Support for DB as a service
- Support for image management in R2 (requires SDC enhancements). This is to help with remote image management with virus/integrity check (via properly defined security tools).
II. Functional description of the target architecture components - Gil/Vimal (20 min)
ACTION: Update Orchestration, Generic NF Controller, and ONAP Design and Creation functions per input from Friday’s call. Work offline to sync-up with Seshu (SO PTL), Lingli/Yang/Jianguo (VF-C project team), Steve and Manoj to address any concerns/ comments they may have including the ones listed below.
Gil’s email:
Regarding the comment on today’s call that in the Beijing release we plan to take steps towards implementing (at least a subset of) SOL003 as the API between NFVO/VF-C…
I think our goal should be that all new code written in Beijing release is taking us closer to a common vision. And so before we get too far down the road implementing towards a specific interface we should have a discussion on the granularity of the operations appropriate across the Orchestration and Controller layers. In order to do that we need to first ensure we have agreement on the next level of detail on the functionality of Orchestration versus Controller layers.
To help start that conversation, I have created the attached where I use the “instantiate” and “scale” scenarios to make a comparison between the current ONAP implementation as manifested in the vCPE use case (for example) and what I see in the corresponding ETSI documentation. (I am no expert in ETSI, so please correct me if I have interpreted something wrongly.)
Note that this diagram assumes the following:
- VNF vendors should (will) provide “plug in play” scaling by adding VDUs, and so there is no need for ONAP to (re)configure the VNF as part of scale out/in orchestration (for example, to make the VNF application aware of the new VDU).
- A VNF by definition will execute in a single cloud instance. Specifically, there is no need for doing “homing” to find a VDU cloud provider/instance “home” that is being added to a VNF as part of a scaling event.
If the above are not true or are controversial, then the functionality in the “dashed box” (the per-VDU processing) will need to be supplemented to add the corresponding interactions.
My own preference would be to have a consistent approach across instantiation and scaling for mapping the functionality in the “dashed” box to ONAP components, but I would like to start a discussion on that.
II (a). Distinction between Service and Service Instance (Steve_comment)
ACTION: Resolve comment.
II(b). Some architecture comments/questions (Manoj_comment)
ACTION: Resolve comment.
III. ONAP External APIs (Orchestration Delegation/Federation) + Susana_comment (20 min)
ACTION: Andy to provide text description and figures (as needed) for external APIs (leveraging the stds specs including MEF, TM Forum, ..). This is for handling orchestration federation/delegation based on what we agreed and reflected in the target reference architecture. Please use the attached template for documenting the external APIs specifications. Also please work offline with Steve and Susana to review and resolve the following comments before submitting your update:
Parviz, attached is an updated slide deck to help address Steve’s comments on the ONAP External API deck.
I believe that Susana’s comments are referring to a different section in the larger deck, namely the “ONAP Orchestration Alignment” section, slides 9-14 of Mayer_py20171204 ONAP R2+ Architecture Proposal-Mayer
[Susana] Referring to Andrew slides, I have some questions/comments. According to some previous call, the current VF-C includes orchestration functionality as per ETSI MANO standards, i.e. including Network Service LCM and VNF(s) LCM; however, the slide 14 assumes that the SO is in charge of both VNF LCM and NS LCM, which is inconsistent with the current allocation of functionality. I assume the functionality of VF-C is not to be integrated into the SO, am I right?
Additionally, a Generic VNF controller includes some drivers for the external VNFM (which is also a VNF controller) and EM (which is the application controller). Shouldn’t the VNFM driver be part of the orchestration engine (of the VF-C, wherever it is now)?
IV. Catalog & VNFM (Maopeng) + Comment (Steve) – APPROVED
V. ACTION: Parviz to update the slide deck and incorporate any changes agreed so far.
ACTION: Maopeng to sync-up with Steve offline and submit an updated proposal for tomorrow’s call. The update should include any agreement reached with the SDC project team per Alex’s comment.
Hi Parviz, some ideas about the R2+ architecture. Hope we can discuss them in the tiger meeting, Thanks.
- P1 and P2 is about the RT-catalog and DT-catalog – Project approval pending!
- p3 about the orchestrator and VNFM
- About the model driven, suggest model in Arch subcommittee aligned with the modeling subcommittee. P4 is the modeling subcommittee reference.
[Steve] Hi Maopeng, regarding the removal of orchestrate network functions, I know what you mean, however still there can be orchestration of the configuration of the NFs that go across NFs at this level. Would it instead make sense to add a bullet under the first bullet on slide 10 along the lines of “note: LCM of a specific NFs is a controller function”?
[Maopeng] Hi Parviz, last meeting, I propose the confusion issues of orchestrator and controller and also we talk about the GVNFM Steve updated and get consensus about GVNFM.
Suggest 1: Page 10&11: request for clarification on the differentiation between orchestrator and VNFM on NF orchestration/LCM
remove “Orchestrate Network Functions (VNF/PNF)”and “LCM VNF/PNFs”
Suggest 2: Add G-VNFM as the input in the arch slide.
VI. Certificate Credential Management (Srini): CLOSED
Hi Parviz, ... Few comments :
Since we intend to have Certificate credential management and Secret Management Services in R2 and beyond, can we add them to “High-Level Functional view” slide in “Common Services” block? For the space reasons, you may want to put ‘cert, secret mgmt’.
Not verified, but this is understanding I am getting : Policy framework in R1 is a run time service for closed loop control only . In R2, my understanding is that policy framework is going to be used by OF and possibly others. If that is the case, it should be part of “Common Services”.
In all pictures: External Gateway, in my view, need to be below OSS/BSS and above ONAP External API. Alternatively, “External Gateway” in the same box as ONAP External API.
Hypervisor/OS Layer is not the right term to represent “Openstack”, “VMWare”, “Azure”, “AWS” and “Rackspace”. Suggestion is to use “VIM/Hyperscale layer”. AMZ term is not well known. Can we change this to “AWS”.
VII. NFVO functionality/API description in R1 (Yan) – APPROVED
VIII. GVNFV diagram update (Steve) – OPEN (5 min) - General agreement (SOL 002 to be removed from the diagram).
IX. API Specifications:
MEF/TMF APIs (Ext API), ETSI MANO Interfaces (based on SOL specs) and enhance existing interfaces in compliance with the architecture design guidelines, carrier-grade criteria/S3P, etc (10 min)
X. VDF proposed architecture (Susana) – OPEN (Deferred)
ATION: Susana to present the proposed architecture tomorrow (before the R2+ architecture deadline). Otherwise, it will be deferred to R3.
XI. Update the architecture figures with newly approved functional elements/projects (Parviz) – (5 min)
- MUSIC – as a shared service provides a unified platform for consistent state management across multiple sites (sharding startegy).
- ONAP Benchmark
XII. MSB Functional Description (10 min)
XIII. A&AI Functional Description (5 min)
------------------------------------
US numbers:
+1 646 558 8656, or +1 669 900 6833
Meeting ID: 761 325 550
International numbers available:
https://zoom.us/zoomconference?m=D_WZofsWmNr8ZvyR_5uMQv1i2yKSoUpS
-----
Agenda:
AGENDA (22-Dec-2017)
1.Functional description of the target architecture components (Vimal) - OPEN
2.Comments on the target architecture diagram (Manoj) - OPEN
Hi Parviz, following are some of the comments/queries in the slide.
- Slide 13: “Nesting may be domain-specific orchestrator (does not require SO clone)” : Does this mean Orchestration function is logically centralized but physically distributed – i.e accommodating the domain orchestrator integration proposal (submitted by Alex and Ramesh)? If this is the case, can A&AI (inventory) also be a hierarchical function? , because if orchestration functions are distributed across domain boundaries (physically from deployment point of view) , it may be logically more feasible to have local inventory than centralized inventory to avoid frequent reconciliation between domain and top orchestrators
- Slide 13: Referring to ETSI MANO NFVO scope – there are two modes for resource allocation for VNF – Direct and Indirect. In Direct mode NFVO delegates the resource allocation to VNFM (NFVO does not allocate resources by interacting with VIM) and Indirect mode where in NFVO allocates resources directly by communicating with VIM. Currently I guess ONAP follows the indirect mode (assuming one of the orchestration function layer act like NFVO). Is there any plan or is there any clear documentation required to indicate that direct mode is supported/not supported.
- Slide 26: Looking at the scope, Is it a right assumption that the interface between Orchestration functions in Orchestration hierarchy is proposed to be MEF Interlude ? If this is the case what kind of model alignment is expected here – i.e the models driven by SDC – I guess the alignment with SOL specifications (as depicted in slide 19) will make Orchestration functions aligned with ETSI models (customized for ONAP) and say Os-Ma interface.
- Slide 32: Assuming Generic VNF Controller fulfils (may be more than) the G-VNFM capabilities as per ETSI MANO, can it also support the SOL003 specifications (in similar lines to the documentation in slide 19) ?
3. Distinction between Service and Service Instance (Steve) - OPEN
4. Comments on the target architecture diagram (Yuan) APPROVED
Maopeng raised the same concern in previous mail about function definition of Service Orchestration in the slides where the service Orchestration looks covered LCM of VNF.
In Amsterdam voLTE usecase approach, SO was responsible for high level E2E Service LCM, NFVO in VFC was responsible for ETSI aligned Network Service LCM, specific VNFM from vendors was responsible for VNF LCM. There are code of G-VNFM in VFC but does not applied for VNF LCM in Amsterdam release.
For R2+, we have reached consensus on Service Orchestration function should be responsible for nested Service LCM which means NFVO function in VFC project should map to SO instead of Generic Controller function.
What is not clear is LCM(instantiate, start, stop, remove, scale-in/out, etc. ) of VNF. We regard LCM of VNF as functionality of G-VNFM or s-VNFM(from different vendors). In Maopeng's mail he proposed to modify context of service orchestration functionality definition as
“Orchestrate VNF via GVNFM or vendor’s VNFM, PNF and Network Services (NSes), and services provided by the managed environment”
“LCM (instantiate/modify/upgrade/configure/remove) VNFs via GVNFM or vendor’s VNFM, vPNFs, Nses, and services from the managed environment”
“Orchestrates network functions LCM via GVNFM or vendor’s VNFM and service LCM (Instantiations, ..) , including compound / nested services (parts already in R1)”
I also agree the text above might avoid confusion. More information please refer to Maopeng's mail.
5. ONAP External APIs (Orchestration Delegation/Federation) section are included in the attachment. (please see slides 22 through 27) (Andy, 2 sets of slides) + Steve (comment) + Susana (comment) - OPEN
Parviz and Tiger Team, attached for our discussion is a draft presentation that discusses the ONAP External APIs and how they relate to MEF LSO.
I also threw in some Model Driven Orchestration slides at the end to discuss when we have time.
Thanks to Alex for the ONAP as a Black Box and Information Domains diagrams.
[Comment/Susana] Referring to Andrew slides, I have some questions/comments. According to some previous call, the current VF-C includes orchestration functionality as per ETSI MANO standards, i.e. including Network Service LCM and VNF(s) LCM; however, the slide 14 assumes that the SO is in charge of both VNF LCM and NS LCM, which is inconsistent with the current allocation of functionality. I assume the functionality of VF-C is not to be integrated into the SO, am I right?
Additionally, a Generic VNF controller includes some drivers for the external VNFM (which is also a VNF controller) and EM (which is the application controller). Shouldn’t the VNFM driver be part of the orchestration engine (of the VF-C, wherever it is now)?
6. GVNFM diagram (Steve) – Discussed last time & deprecated. See comment #16 for an update. CLOSED
7. Catalog & VNFM (Maopeng) + Comment (Steve) – OPEN
Hi Parviz, some ideas about the R2+ architecture. Hope we can discuss them in the tiger meeting, Thanks.
- P1 and P2 is about the RT-catalog and DT-catalog – Project approval pending!
- p3 about the orchestrator and VNFM
- About the model driven, suggest model in Arch subcommittee aligned with the modeling subcommittee. P4 is the modeling subcommittee reference.
[Comment/Steve] Hi Maopeng, regarding the removal of orchestrate network functions, I know what you mean, however still there can be orchestration of the configuration of the NFs that go across NFs at this level. Would it instead make sense to add a bullet under the first bullet on slide 10 along the lines of “note: LCM of a specific NFs is a controller function”?
[Comment/Maopeng] Hi Parviz, last meeting, I propose the confusion issues of orchestrator and controller and also we talk about the GVNFM Steve updated and get consensus about GVNFM.
Suggest 1: Page 10&11: request for clarification on the differentiation between orchestrator and VNFM on NF orchestration/LCM
remove “Orchestrate Network Functions (VNF/PNF)”and “LCM VNF/PNFs”
Suggest 2: Add G-VNFM as the input in the arch slide.
8. API Enhancements, S3P Metrics, ETC – Awaiting new contributions!
9. CCSDK (John):
Parviz, I see that the updated slide 7 has CCSDK removed from Common Services box, since CCSDK is not a run time component. But it is no longer on the slide at all. I propose that we put CCSDK either inside SDN Controller and Generic NF Controller boxes as “persona based on CCSDK”. Alternatively, we can put CCSDK vertically underneath OOM. Placement of CCSDK can be discussed further. But it needs to be on the architecture slide.
RESOLUTION: See the updated architecture diagram with CCSDK:
10. VF-C R2 Feature Planning & Implementation (Gil): Discussed and CLOSED.
Parviz, at the “VF-C R2 Feature Planning & Implementation” session that just ended it seemed that the VF-C team has no plans in R2 to start taking steps towards positioning the NFVO layer functionality for eventual migration into SO. I proposed at the SO weekly meeting last week that Seshu should extend an invitation to the appropriate NFVO/VF-C SMEs to perhaps join our SO weekly meetings to start the dialog on what steps we should take to begin the integration of NFVO into SO. Seshu thought that was premature, thinking it better to wait until you have had a chance to socialize the target architecture direction with the various PTLs. I’m not at the F2F meeting; have you had a chance to discuss yet with the PTLs?
11. Ext GW (Andy):
Both Andy and Huabing agreed to remove EXT GW from the architecture figures. CLOSED
12. Certificate Credential Management (Srini): OPEN
Hi Parviz, ... Few comments :
- Since we intend to have Certificate credential management and Secret Management Services in R2 and beyond, can we add them to “High-Level Functional view” slide in “Common Services” block? For the space reasons, you may want to put ‘cert, secret mgmt’.
- Not verified, but this is understanding I am getting : Policy framework in R1 is a run time service for closed loop control only . In R2, my understanding is that policy framework is going to be used by OF and possibly others. If that is the case, it should be part of “Common Services”.
- In all pictures: External Gateway, in my view, need to be below OSS/BSS and above ONAP External API. Alternatively, “External Gateway” in the same box as ONAP External API.
- Hypervisor/OS Layer is not the right term to represent “Openstack”, “VMWare”, “Azure”, “AWS” and “Rackspace”. Suggestion is to use “VIM/Hyperscale layer”. AMZ term is not well known. Can we change this to “AWS”.
13. Microservice Design Considerations (Manoj): For Information Only. Closed
Hi Parviz, Please find attached the document I was referring to and discussed when we met during ONAP F2F. Please note that, there was a review planned with Alex and we could not complete it due to schedule during F2F. I also had a brief discussion with Huabing (copied) in this regard. The document is focused on Microservice design and I tried to consolidate ideas shared by many people in the Architecture committee. I can post it to ONAP wiki if you think this has to be discussed and reviewed by community. Alex wanted to align this with his thoughts on DMS and modular micro service driven ONAP concept. Alex can comment what his views are so that we can improve and arrive at consensus. Alex views might be relevant at a component level with API layers and adaptors . But at MS level I am not sure if it make sense without harming the freedom of choice of MS developer and burdening developer with fixed structure.
14. Proposed Changes on Multi-Cloud (Ramki): APPROVED
Slide 10, the current text below:
- “Coordinating Activities Across Various ONAP Controllers
? Coordinates activities across Multi-Cloud (infrastructure) / SDN-C / APPC / VF-C controllers
? Manage recording of service configurations”
Suggest to remove Multi-Cloud from Controller since Multi-Cloud does not manage element configuration. With that, proposed text:
- “Coordinating Activities Across Various ONAP Controllers (SDN-C/APPC/VF-C)
? Manage recording of service configurations
- Coordinating Activities across vendor-specific clouds using the Multi-Cloud adaption layer which supports a Cloud Agnostic Model while hiding infrastructure details
? Multi Cloud Adaptation Layer is flexible to support Cloud vendor-specific capabilities if needed”
15. Example sequence diagrams for interactions between SO, VF-C and sVNFM in R1 (Denes) - OPEN
We have looked though the different architecture diagrams, but they are not fully synchronous. The biggest confusion for us is the GVNFM alignment (Steven) with the main R2 architecture diagrams and SO VF-C alignment. I have included the actual interaction between SO, VF-C and sVNFM in R1 (these diagrams are based on the actual code. If someone knows if it is not accurate please help us to fix it). I think it very clearly explains what are the individual components are doing. I hope it helps everyone in the understanding. I will try to include a detailed sequence diagram for the APP-C based workflows in R1 for the next week (If someone know how this is done in R1 please help). It would be good to know what is expected to change in R2 and what is the target (with roles and APIs between components).
16. NFVO functionality/API description in R1 (Yan) - OPEN
17. GVNFV diagram update (Steve) - OPEN
18. API Specifications (slide 14, deck/py20171218) - to achieve alignment with MANO for common functionality, SO should expose APIs for basic resource onboarding/LCM (VNF) . This is SOL-001, SOL-004 and SOL-005. Need a detailed description of each interface.
Minutes:
TBA