Versions Compared

Old Version 14

changes.mady.by.user Parviz Yegani

Saved on

compared with

New Version Current

changes.mady.by.user Parviz Yegani

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Mailing list: onap-arch-tiger-team (email Parviz or Chris)

ONAP target architecture (R2 R4 and beyond): 

ONAP

...

End-to-End Architecture 

The target architecture end-to-end architecture of the ONAP platform 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: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.
  • 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 pageThe latest architecture diagrams and functional description of individual components can be found at: https://wiki.onap.org/display/DW/Contributions

Architecture Tiger Team Weekly Meeting

Meeting Information (Fridays):

UTC 03:00 PMChina 11:00 PMEastern 10:00 AMPacific 07:00 AM
  • IRC: TBA

...

...

...

+16699006833,or

...

  • +1 646 558 8656 or +1 669 900 6833
  • Meeting ID:

...

...

Meeting Agenda + Notes:

Tiger Team Contributions:

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.

  1. P1 and P2 is about the RT-catalog and DT-catalog – Project approval pending!
  2. p3 about the orchestrator and VNFM
  3. 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:

...