...
Mailing list: onap-arch-tiger-team (email Parviz or Chris)
ONAP target architecture (R2 R4 and beyond):
Architecture Principles
Were Reviewed Earlier and Agreed Upon by the Architecture Team:
ONAP End-to-End Architecture
The end-to-end architecture of the ONAP platform is currently being developed by the tiger team using a set of design principles listed below: https://wiki.onap.org/display/DW/Contributions?preview=/8225716/8232492/Architectural%20principles_v3.docx
- ONAP is a layered architecture – Orchestration, Multi-Cloud, Controller, etc.
- Functional role of each layer should be well defined per the aforementioned architecture principles agreed by the architecture team (see the above link).
- 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.
These principles were reviewed and agreed upon by the Architecture Subcommittee. You can find the details here.
Below slide deck provides the latest ONAP architecture for R2 and beyond. This is work in progress. These slides are also available at the Architecture (ARC) Subcommittee contributions page: https://wiki.onap.org/display/DW/Contributions
- py20181011 ONAP Modularization Considerations.pptx (Parviz Yegani)
- py20180828 ONAP R4+ Architecture Tiger Team Report (to ARC).pptx (Parviz Yegani)
- py20180828 ONAP R4+ Architecture Tiger Team Report (to ARC).pptx
- py20180523 ONAP R3+Architecture Update_F2F Vancouver_ARC_F2F.pptx
- py20180515 ONAP R3+Architecture Update_v01 (to ARC).pptx
- py20180514 ONAP R3+Architecture Update (to TT).pptx
- py20180507 ONAP Microservices Architecture (ARC preso)-short.pptx
- py20180501 Service Mesh for ONAP (ARC preso) deferred.pptx
- py20180424 RESP project proposal (ARC preso) deferred.pptx
- py20180417 ONAP Architecture Update (ARC preso)_fnl.pptx
- py20180417 ONAP Architecture Update (ARC preso updated).pptx
- py20180417 ONAP Architecture Update (ARC preso).pptx
- py20180313 ONAP Architecture Update (ARC preso).pptxpy20181011 ONAP Modularization Considerations.pptx
- py20180305 ONAP is model driven.pptx
- py20180227 ONAP R2+ Architecture Proposal.pptx
- py20180126 ONAP R2+ Architecture Proposal_v01.pptx
- py20180125 ONAP R2+ Architecture Proposal_v00.pptx
- ONAP Beijing Architecture TT Readout 20180220.pptx
- ONAP Beijing Architecture TT Readout 20180130_v02.pptx
- ONAP Beijing Architecture TT Readout 20180130_v01.pptx
- ONAP Beijing Architecture TT Readout 20180130.pptx
- ONAP Beijing Architecture TT Readout 20180126.pptx
- py20180124 ONAP R2+ Architecture Proposal.pptx
- py20180123 ONAP R2+ Architecture Proposal.pptx
- py20180122 ONAP R2+ Architecture Proposal.pptx
- py20180119 ONAP R2+ Architecture Proposal.pptx
- py20180116 ONAP R2+ Architecture Proposal.pptx
- py20180112 ONAP R2+ Architecture Proposal.pptx
- py20180109 ONAP R2+ Architecture Proposal.pptx
- py20180102 ONAP R2+ Architecture Proposal.pptx
- py20171218 ONAP R2+ Architecture Proposal (updated) (003)_contributors added.pptx
- py20171214 ONAP R2+ Architecture Proposal (updated).pptx
- py20171208 ONAP R2+ Architecture Proposal ajm.pptx
- py20171208 ONAP R2+ Architecture Proposal (updated).pptx
- py20171207 ONAP R2+ Architecture Proposal.pptx
- py20171128 ONAP R2+ Architecture Proposal.pptx
- py20171114 ONAP R2+ Architecture Proposal.pptx
- py20171114 ONAP R2+ Architecture Proposal-steve2.pptx
- py20171109 ONAP R2+ Architecture Proposal.pptx
- py20171102 ONAP R2+ Architecture Proposal (Tiger Team preso).pptx
- py20171024 ONAP R2+ Architecture Proposal (ARC preso).pptx
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
...
...
- 112544167
- US numbers:
...
+16699006833,or
...
- +1 646 558 8656 or +1 669 900 6833
- Meeting ID:
...
- 112 544 167
- International numbers available:
- https://zoom.us/zoomconference?m=
...
Meeting Agenda + Notes:
- Agenda+Notes ONAP Architecture Tiger Team Call (04-23-2018).docx
- Agenda+Notes ONAP Architecture Tiger Team Call (04-16-2018).docx
- Agenda+Notes ONAP Architecture Tiger Team Call (04-06-2018).docx
- Agenda+Notes ONAP Architecture Tiger Team Call (03-28-2018).docx
- Agenda+Notes ONAP Architecture Tiger Team Call (03-19-2018).docx
- Agenda+Notes ONAP Architecture Tiger Team Call (02-02-2018).docx
- Agenda ONAP Architecture Tiger Team Call (01-26-2018).docx.docx
- Agenda - ONAP Architecture Tiger Team Call (01-26-2018).docx.
- Agenda - ONAP Architecture Tiger Team Call (01-19-2018).docx
- Agenda - ONAP Architecture Tiger Team Call (01-16-2018).docx 2hrs
- Agenda - ONAP Architecture Tiger Team Call (15-JAN-2018) 2hrs
- Agenda - ONAP Architecture Tiger Team Call (12-JAN-2018) 2hrs
- Agenda - ONAP Architecture Tiger Team Call (12-JAN-2018)_with_attachments.docx
- Notes - ONAP Architecture Tiger Team Call (12-JAN-2018)
- Agenda - ONAP Architecture Tiger Team Call (08-JAN-2018) 2hrs
- Agenda - architecture tiger team(08-JAN-2018).msg
- Notes - ONAP Architecture Tiger Team Call (08-JAN-2018)
- Agenda - ONAP Architecture Tiger Team Call (05-JAN-2018) 2hrs
- Notes - ONAP Architecture Tiger Team Call (05-JAN-2018)
- Notes2 - ONAP Architecture Tiger Team Call (05-JAN-2018)
- Agenda ONAP Architecture Tiger Team Call (04-JAN-2018) 2hrs
- Notes - ONAP Architecture Tiger Team Call (04-JAN-2018)
- Agenda ONAP Architecture Tiger Team Call (03-JAN-2018) 2hrs
- Agenda ONAP Architecture Tiger Team Call (03-JAN-2018) with attachments.docx
- Notes - ONAP Architecture Tiger Team Call (03-JAN-2018)
- Agenda - ONAP Architecture Tiger Team Call (22-DEC-2017)
- Agenda - ONAP Architecture Tiger Team Call (18-DEC-2017)
- Notes - ONAP Architecture Tiger Team Call (18-DEC-2017)
- Agenda - ONAP Architecture Tiger Team Call (08-DEC-2017)
- Notes - ONAP Architecture Tiger Team Call (08-DEC-2017)
- Notes2 ONAP Architecture Tiger Team Call (08-DEC-2017)
- Agenda - ONAP Architecture Tiger Team Call (22-NOV-2017)
- Agenda - ONAP Architecture Tiger Team Call (17-NOV-2017)
- Agenda - ONAP Architecture Tiger Team Call (16-NOV-2017)
- Agenda - ONAP Architecture Tiger Team Call (10-NOV-2017)
- Notes - ONAP Architecture Tiger Team Call (10-NOV-2017)
- Notes1 - ONAP Architecture Tiger Team Call (09-NOV-2017)
- Notes2 - ONAP Architecture Tiger Team Call (09-NOV-2017)
- Agenda - ONAP Architecture Tiger Team Call (02-NOV-2017)
- Notes - ONAP Architecture Tiger Team Call (02-NOV-2017)
Tiger Team Contributions:
- ONAP_Modularization_10_21_2018_ATT.pdf
- ONAP_Modularization_10_12_2018_ATT.pdf (John Jensen, AT&T)
- Proposed ONAP Runtime Support for Network Service Onboarding v3.pptx (Updated based on 8/20 Tiger Team comments) (Gil Bullard - AT&T)
- ONAP Orchestration function ESO-DO and Alignment to Standard API V0.1.pdf (Abinash Vishwakarma - Netcracker)
- Proposed ONAP Runtime Support for Network Service Onboarding.pptx (Gil Bullard - AT&T)
- Modular Orchestration and Homing of Complex Services and Allotted Resources (Gil Bullard - AT&T)
- ONAP Casablanca Architecture recommendations att.pptx (John Ng - AT&T)
- ONAP_Controllers_tiger_team_180612.pptx (John Ng - AT&T)
- ONAP_Controllers_tiger_team_180608.pptx (John Ng - AT&T)
- Recursive Orchestration Illustration - Decomposition and Homing.pptx (Gil)
- Recursive Orchestration Illustration - 180326.pdf (Gil)
- ONAP Microservices Architecture for Casablanca and beyond.pptx(Huabing)
- Plug an ETSI VNF Manager into the ONAP architecture (Gil) VNFM Plug-In.pptx
- ONAP Beijing Architecture TT Readout 20180130_v02-sdn.pptx
- E2E ONAP Target Architecture Proposal 01152018 (AT&T).pptx
- jn180206_E2E ONAP Target Arch Proposal_Controllers.pptx
- jn180201_E2E ONAP Target Arch Proposal_Controllers.pptx
- VNFSDK functional description.pptx
- ONAP architecture functional description_MSB_updated with Swagger SDK.pptx
- ONAP architecture functional description_MSB.pptx
- ONAP architecture functional description.pptx
- Service and Resource Orchestration - 180105.pdf
- AAF and DMaap functional description.pptx
- ETSI MANO vs ONAP Instantiation v4.pdf
- Generic VNFM update-pa2.pptx
- ONAP architecture functional description - AAI Slide Updated.pptx
- ONAP architecture functional description - CLI.pptx
- ONAP architecture functional description (2).pptx
- ONAP architecture functional description -APPC-v3.pptx
- ONAP architecture functional description -CLAMP-v1.pptx
- ONAP architecture functional description(UUI).pptx
- ONAP architecture functional description.pptx
- ONAP architecture functional description_MSB.pptx
- ONAP architecture functional description-dcae-edits.pptx
- ONAP Beijing Architecture Jan 9b.pptx
- ONAP R2+ catalog&VNFM-Maopeng.pptx
- ONAP Target Architecture_with_CCSDK.pptx
- ONAP Target Architecture_with_orch_details-V3.pptx
- ONAP_E2E_Arch_Drawing.pptx
- ONAP-VFC.pptx
- 20180124_Multi VIM-Cloud functional description.pptx
- 20180124_ONAP Operations Manager functional description.pptx
- 20180124_Policy functional description.pptx
- 20180115_E2E ONAP Target Architecture Proposal_ATT.pptx
- 20180116_E2E ONAP Target Architecture Proposal_ATT.pptx
- 20180118_E2E ONAP Target Architecture Proposal_ATT.pptx
- 20180115_ONAP APIs_ATT.pptx
- 20180116_ONAP APIs_ATT.pptx
- 20180124_Orchestration functional description (Seshu).pptx
- 20180115_ UUI functional description.pptx
- 20180115_A&AI functional description.pptx
- 20180115_AAF and DMaap functional description.pptx
- 20180115_APPC functional description.pptx
- 20180115_CLAMP functional description.pptx
- 20180115_DCAE functional description.pptx
- 20180115_Gil's comments on service and resource orchestration.docx
- 20180115_Lusheng comments on DCAE functional description.docx
- 20180115_Manoj's comments - suggestions on Casablanca.docx
- 20180115_MSB functional description_ZTE.pptx
- 20180115_MSB_updated with Swagger SDK_Huawei.pptx
- 20180115_ONAP Beijing Architecture Jan 9b_Manoj comments.pptx
- 20180115_OOF-architecture-functional-description-R2-and-R3plus.pptx
- 20180115_Service and Resource Orchestration.pdf
- 20180115_VDF - proposed Target Architecture_with_orch_details-V3.pptx
- 20180115_VNFSDK functional description.pptx
- 20180115_CLI functional description.pptx
- 20180115_Logging-analytics functional description.pptx
- ONAP Beijing Architecture TT Readout 20180130_v02-sdn(Ramki_added_slides 55-58).pptx
- ONAP Microservices Architecture Approaches (Manoj)
- ONAP Modularity - Functional Decomposition Proposal (Manoj)
- Functional Decomposition (Initial View)
Zoom Recording:
20180214_tiger-team-call zoom_0.mp4
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:
...