Overview
Edge clouds are located at close proximity to end users. Typical deployment locations are within the access networks or at the boundary of access networks. In some deployments, they can be within the customer premises (e.g., home; enterprise; factory floor; vehicles including trains, planes, private cars). The core thrusts of edge clouds for applications are low latency, high bandwidth, and trusted computing and storage. Various edge cloud architectures have already emerged from different communities and potentially can be plugged into the ONAP architecture for service orchestration. The group analyzes the orchestration requirements of services over various edge clouds and how these requirements impact ONAP components in terms of data collection, processing, policy management, resource management, control loop models, security, as well as application & network function deployment and control.
ONAPARC-63 - Getting issue details... STATUS
Problem Statement : Edge Architecture & Work Items
- Edge Cloud Domain = collection of Edge Cloud Nodes in a Domain
- Where/What is Edge
- See Figure 3 in ATT-Edge_Compute_White_Paper FINAL2.pdf
- Edge = vCPE at customer Premises
- Edge = Cell Tower
Edge = Small Central Office (eg., CU for vRAN)
Key Presentations:
- Overview, Relationship to Akraino/Other open source projects and Preliminary Dublin Planning:
- ONAP Internal
- Presentation to use case sub committee: (10/22/2018)
- Presentation to arch sub committee: (10/23/2018)
- ONAP External
- Presentation to Akraino Technical Community: (10/25/2018)
- Link: https://wiki.onap.org/download/attachments/8225716/ONAP-edge-automation-update-arch-use-case-10-23-2018.pdf?api=v2
- ONAP Internal
- Presentation in Arch subcommittee meeting at Montreal:
- Presentation in Arch subcommittee (03/26/2019)
- Presentation in Arch Face to Face at ONS
- Presentation in Arch subcommittee (04/16/2019)
- Presentation in TSC (10/24/19)
Key ONAP Project Impact:
Dublin Plan:
- Functional Requirements
- Architecture Task Force
Frankfurt Plan:
Architecture Task Force - Edge Automation through ONAP Arch. Task Force - Distributed Management (ONAP etc.) components
Call Schedule:
Time: 8:00am PT - 9:00am PT
- Day: Every Wednesday
- Zoom: vmware.zoom.us/j/3055973130
List Subscription/Meeting Notification:
WG Coordinators: Ramki Krishnan
all Notes
| Date | Agenda | Notes | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Apr 06, 2018 |
| ZOOM Recording: GMT20180406-170638_Ramki-Kris_1920x1080.mp4 Meeting Notes:
Agenda to be finalized 24 hrs. before each meeting. Folks are requested to review the contributions and come prepared with questions. | ||||||||||||
| Apr 09, 2018 |
| ZOOM Recording: zoom_0.mp4 Meeting Notes:
| ||||||||||||
| Apr 16, 2018 |
| Zoom Recording: zoom_0.mp4 Meeting Notes: What diagram to add in Edge Architecture & Work Items wiki? - item 2.C.I from last session - see gliffy diagram in Edge Architecture & Work Items page 1 and 2: Vimal provided review of table in Edge Architecture & Work Items page for application classification. 3: updated gliffy diagram to reflect input from Vimal's diagram 4: Clarified demarcation between Cloud Provider and ONAP offload in slides. Also, suggested we use gliffy in wiki as one diagram to work on. | ||||||||||||
| Apr 23, 2018 | Review updated Gliffy Arch diagram and Notes below gliffy (also, need to update gliffy with apps locations) Review Infrastructure Profile descriptions from Srinivasa Addepalli and Vimal Begwani TBD - Review of MEC_Apps_ONS2018_Rev1.1.pdf by Prakash Ramchandran | 1) Reviewed gliffy, notes below gliffy, and, applications table
Yoav Kluger: why limit to 500ms/use case 1?
Yoav Kluger - for e2e requirements, need to consider using policies vs service design Parviz Yegani - for RT vs NRT: need tight coordination between domains?
2) Srinivasa Addepalli reviewed Infrastructure Profiles in Edge Architecture & Work Items page
3) Cagatay Buyukkoc briefly reviewed Edge Automationissues.pptx - need to discuss more | ||||||||||||
| April 30th, 2018 | Review updated Gliffy Arch diagram and Notes below gliffy (also, need to update gliffy with apps locations) Review Infrastructure Profile descriptions summarized Vimal Begwani Review of MEC_Apps_ONS2018_Rev1.1.pdf by Prakash Ramchandran / Prem Sankar Gopannan | Review of MEC_Apps_ONS2018_Rev1.1.pdf by Prakash Ramchandran / Prem Sankar Gopannan
Reviewed Infrastructure Profile summary and Gliffy Diagram in Edge Architecture & Work Items
| ||||||||||||
| May 7th, 2018 | Hierarchical DCAE - Lusheng Ji, Vijay Venkatesh Kumar High level review of Multi-Cloud use cases - Edge Cloud Infrastructure Enablement in ONAP |
| ||||||||||||
| May 14th, 2018 | 1) Evgeniy Zhukov et al., Netcracker – AR/VR Use Case:
2) Complete architecture discussion on single vs multiple ONAP instances, i.e. ONAP central vs ONAP edge. | 1) Evgeniy Zhukov et al., Netcracker – AR/VR Use Case - Edge cloud as ‘black box’ with interfaces (UNI/NNI in DP, NBI in mgmt plane), with control plane having slice manager/controller/MEC-manager/etc.. - raghu/ clarified that CP’s internal ‘control/mgmt’ plane is not discussed….although there are onap components which are not relevant for edge cloud provider - Tom Tofigh - functional arch has useful distinction between pack/app processing so can consider specifying acceleration in edge for compute-intensive/storage-intensive/memory-intensive….but, capture in ONAP’s IaaS/PaaS API? object vs packet switching? Analytics on bigger address space? - animation to change network topology in order to support AR/VR meeting requirements, etc. - problem statement need clarity, ie., AR/VR app will make sure or Edge-domain provider or ONAP-provider? So, upcoming telecom model shown with 3 entities: Bus App / Slice Provider / Infra Provider - Parviz: who is responsible for AR SLA? ONAP needs to coordinate with Edge Provider? need to clarify relationship in context of our ONAP-SP <> Edge Cloud Provider - Tom: Slice app provider will manage the slice to meet SLA, etc. - Raghu: maybe good to bring it to 5G-use case calls? Ramki suggests this could be about ‘application slice’. Parviz asks if ONAP arch needs to change even with MEC manager? maybe the key point is SLA for e2e and how onap is going to split between multiple domains like edge clouds, etc. 2) Complete architecture discussion on single vs multiple ONAP instances, i.e. ONAP central vs ONAP edge. - triggered arch discussions on separate ONAP instance - Srini: need to generalize term to ‘automation offload platform’? - yoav: need to understand whether ‘separate onap instance’, ie., may not want SO, etc.? may not want it to be ‘MVP’ since onap-central is MVP+. - Gil Hellmann: minimum services/functionality at edge needed…vs using a term like MVP. maybe limited by power/space, etc. Also, even without onap functions, those edge nodes need connectivity. - shankar Narayanan: MVP - similar classification of workflows needed? sequence diagram started…but, need to work on. map the workflows that are part of the functional deliverables in R1/R2 and mapping to the edge. Also, scope of edge to meet S3P, eg., violating/meeting? - chaker: more than one central onap? eg., VF OpCos - given service context, there is one ONAP-central SP, with rest are ‘cloud providers’, etc. Need to add such an example diagram. - Yoav: ONAP-edge need to talk to multiple onap-cental….but, we need to start small. so, we don’t restrict to 1:1 for onap-edge to onap-central. within same SP, there can be inventory-sync, etc. For casablanca, we may start with 1:1 - shankar N: sharing of inventory - depends on what workflow is partitioned between central/edge. This might drive how we scope MVP. 3) Finalize minimum viable needed ONAP edge for Casablanca - ramki showed bullets in ‘edge scoping’ page - raghu suggested using shankar’s suggestion on workflows to decide additional components, eg., if needing state change, will be a request back to Cloud Provider or use a SDN-C for the ‘slice’ to change networking state, etc. - Parviz: need closed loop? so, clamp, policy, etc.? - need top down steps such as (a) what state changes, (b) what workflows, and, (c) what onap components. - VNF —> VES Collector —> sub-function of DCAE, ie., look up policy and which topic, action on which topic, pre-configured rules. - Parviz: IoT Hub? yes, architecture allows this. Also, app profiles includes cases when onap-managed or non-managed | ||||||||||||
| May 21st, 2018 | 1) Preparation for Chris Donley's OpenStack key note which includes few slides on ONAP Edge Cloud – plan to list participant company logos. Chris may use some slides from the latest TSC update deck - ONAP-edge-automation-wg-tsc-update-05-10-2018.pptx 2) Finalize minimum viable needed ONAP edge for Casablanca | 1) Ramki: Announced Preparation for Chris Donley's OpenStack key note which includes few slides on ONAP Edge Cloud; Interested Participants to send their company logos by tomorrow morning PST. 2) review MVP - Sekar: what is an ‘instance’? confusion as to why call instance when subset of onap components
- Pasi: time sensitive events then you have to place close enough, etc. As fyi, Akraino discussions had at least 4 presentations mentioning need for some components to be based on time sensitive event management. Now, we don’t have VNFM, for example, to do LCM of VNFs. For example, failover management might need a closed loop.
- Pasi: closed loop requires VNFM/controller in edge domain (?) - Pasi: app profile table is missing even smaller timescales such as RAN fronthaul - Raghu: clarified that most of SLS for infra would be part of IaaS request, eg., link, server failure, etc. - Pasi: to put together slides for discussion be app profile and closed loop to decide on additional onap-edge components | ||||||||||||
| May 23 | Arch Committee Discussion - Casablanca Architecture Planning Meeting
| Chris Donley used Edge Architecture & Work Items page to briefly update folks on state of work - app profiles, infra profiles, onap hierarchy, edge domain, etc.. Following were some discussion points:
Chris Donley noted the plan for review during March 29th arch call. Related discussion during VNF onboarding slot when discussing 'external VNFM'
Related discussion during OOM slot - federated vs distributed K8s cluster for geo redudancy
( | ||||||||||||
May 29 (vs May 28 since Memorial Day Holiday in USA) |
Related Discussions - Reviewed updated gliffy for arch to ensure folks had consistent view of the problem statement, i.e., onap-central vs onap-edge for 'blue SP'. Also, edge CP domain is a black box from blue SP perspective. | |||||||||||||
| June 4 |
Note: M1 deadline is June 28 - so 4 more calls in June
| Ramki reviewed option A/B/C for MVP - chaker: option A - no onap? context? used arch gliffy to clarify ‘green CP’ to do stuff without any ‘blue onap’ stuff - dominic: what about other components needed by DCAE? depends on collecting/reporting state vs changing state - vijay: helm vs blueprint (cloudily) approach to OOM deployment of edge dcae? - chaker: edge cloud is where DCAE can run - chaker: is this work about (a) automation of edge, or (b) using onap-edge in an edge domain? - chaker: brainstorm in beijing a bit more on the problem - chaker: onap today - 100 VMs. / yoav: with OOM, it is much leaner. / yoav: DCAE - “good number of VMs’….other element, can put in “1 VM”. - chaker: are we going to have onap in the edge, or use the edge as part of VIM / ramki: leverage edge CP functionality…but, also bring some onap components if value - yoav: overloading this work with multiple problem statements, eg., distributing onap vs edge computing, etc.. In edge computing, micro services running in edge for which we want to use ONAP. But, distributing ONAP is a different problem. - raghu: reset with background info - context >> multiple problem statements >> etc.. - raghu: use of ‘multi-cloud adapter’ is the plan / reviewed gliffy arch diagram / but, API will be ‘intent’ rather than internal CLI like imperative. However, we can go next step with having some onap-edge as in option B of MVP - Bin Yang: are DMaaP and VES components in edge? yes…depends on app context….and, shown in sequence diagram where “edge CP’ does analysis and provides summary info to onap-central when no onap-edge. - ramki: reviewed different steps in sequence diagram…focusing on ‘red text’. - jack: which onap-central component is responsible for subscribing to topics? ramki gave example of correlation micro service using data and supplying to policy. micro service in onap do not talk to multi-cloud. Need to detail out interactions within ONAP-central. also, format translations between green and blue. - Arash: are we using DMaaP? / raghu: option A - no edge onap, but with option B - dcae with dmaap/ves - Arash: if no onap-edge, Control Loop in onap-central will run as today. No multi-cloud adapter involvement. /ramki: infra analytics example then multi-cloud comes to play. - Arash: if onap-edge, what does onap-central see? external orch or analytics or controller, etc.? if external analytics then not discussed about rules and operations. if ‘external controller’ then current arch committee discussions currently is via sdn-c (if non onap) or via DMaaP (if onap-like)…but, not via multi-cloud adapter (action item: to discuss in arch calls) - Arash: OOM - no runtime at this time. So, this will be huge expansion. - Borislav: OOM is not designed to trigger upon service request. / raghu clarified that OOM is used when new edge domain. Also, sequence diagram for casablanca assumes that infra is set up for OOM to instantiate onap-edge - Arash: need to capture interactions in more detail between edge DCAE and onap-central, eg., plugging in to central DMaaP or multi-cloud or sdn-c/app-c (also discussion with arch committee). / ramki clarified that any closed loop (critical stuff) is done by edge CP without ONAP. - ramki: extend DMaaP across WAN? / arash: may not make sense. So, how do those events make to onap-central. / Borisalv: http/rest interface. - chaker: each edge cloud has a ‘collector’ in onap-central? / Bin Yang: VES in onap-central is similar to current Release A and B. So, better to consider an edge VES/DMaaP? - chaker: extending onap to many edge cloud might be difficult. would be better to let edge cloud to provide summary events to onap-central. / (aside: raghu pointed out term issue - edge cloud vs edge domain) - Dominic: DmaaP has existing capability to either have edge processing or sent to central. / need to discuss. / Chaker: may not be possible to install DMaaP components in edge. / Dominic: consider when possible to have in edge - chaker: if extending DMaaP interface - so, deploy DMaaP client to collect triggers/events, then DMaaP adapter is certified in every cloud like AWS/Azure. / Jack: anything that uses API has to run in any cloud since http-based API. | ||||||||||||
| June 11 |
| |||||||||||||
| June 18 | Beijing
| |||||||||||||
| June 25 | Requesting the PTLs and/or key folks from Infrastructure Modelling, OOF, SO, A&AI, Multi-Cloud, DCAE to join the Edge Automation MVP for Casablanca discussion. Edge Automation MVP Link: https://wiki.onap.org/display/DW/Edge+Scoping+MVP+for+Casablanca+-+ONAP+Enhancements | Cloud Region vs Physical DC location info granularity for homing
Terms:
| ||||||||||||
| July 2 | Casablanca MVP Deep Dive
Anything else? | (draft notes - to be cleaned up) Ramki reviewed policy example. Some Qs discussed
| ||||||||||||
| July 9 | Casablanca MVP deep dive | |||||||||||||
| July 16th and July 23rd | Meetings Cancelled – Casablanca MVP Deep Dive Discussion with Relevant PTLs for R2 planning | |||||||||||||
| July 30th |
| |||||||||||||
| August 6th | Casablanca MVP discussion contd. | |||||||||||||
| August 13th | Casablanca MVP discussion contd. | |||||||||||||
| August 20 |
|
(additional notes to be updated later) | ||||||||||||
| Aug 27 | ||||||||||||||
| Sept 5 | 1. K8s based Cloud Regions 2. MEC arch ...and overlap with ONAP functional components | |||||||||||||
| Sept 12 | O-RAN update - ONAP-Edge-ORANupdate-Sept2018.pptx Edge Automation Potential Strategies for Deploying ONAP_v1.8.pdf | |||||||||||||
| Sept 19 | Dublin release planning Edge - focus? End User Group call? | MEC APIs?
Focus?
End User Group?
| ||||||||||||
| Sept 26 | MEC orchestration and ONAP role for Dublin & Beyond - Srinivasa Addepalli Edge_ONAP_WG_v4.pdf (v7 used in call - to be posted soon) | Discussed APP Provider > ONAP > Edge
Arash - need to ask TSC and End User Advisory Group (EUAG) about expanding ONAP scope
| ||||||||||||
| Oct 3 | Discuss items for Dublin Release Used Sequence diagram in Edge Architecture & Work Items | Edge Cloud Domain/Provider
Reviewed and Updated Sequence Diagram in Edge Architecture & Work Items
Continue discussion for the next few weeks to finalize input for Dublin Release (Target November?) | ||||||||||||
| Oct. 10 | Dublin discussion | |||||||||||||
| Oct. 17 | Dublin discussion | |||||||||||||
| Oct. 24 | Dublin discussion | |||||||||||||
| Future Calls | Potential Topics
| |||||||||||||
| Fri. 02/08/2019 |
|
| ||||||||||||
| Wed. 02/13/2019 & 02/14/2019 |
| Presentation by Dominic | ||||||||||||
| Wed. 02/20/2019 & Fri. 02/22/2019 |
| AT&T EOM Slides - https://wiki.onap.org/download/attachments/28379482/EOM%20overview%20for%20ONAP%20community.pdf?api=v2 Meeting Recordings: 1) 02/20 - https://wiki.onap.org/download/attachments/28379482/zoom_1.mp4?api=v2 2) 02/22 - https://wiki.onap.org/download/attachments/28379482/zoom_0.mp4?api=v2 | ||||||||||||
| Wed. 02/27/2019 |
| Next Steps:
| ||||||||||||
| Wed. 03/06/2019 |
| Feedback on option 3
| ||||||||||||
| 03/13/2019 | Agenda for Wednesday (03/13) meeting:
| Cloudify presentation notes
Other discussion - EOM (option 2)
| ||||||||||||
| 05/08/2019 | Agenda for Wednesday (05/08) meeting:
| Recording: Meeting Summary:
| ||||||||||||
| 05/16/2019 | Agenda for Wednesday (05/16) meeting:
| Meeting Summary:
| ||||||||||||
| 05/23/2019 |
| Meeting Summary:
| ||||||||||||
| 06/21/2019 |
| Zoom Recording Link: https://VMware.zoom.us/recording/share/3vJpWdU9rSsaAx6IKENP29JVJNMCieYtMaYrfxbyLtE
| ||||||||||||
| 07/31/2019 | Agenda for Wednesday (07/29) meeting:
| Presentation Link: Zoom Recording Link: https://VMware.zoom.us/recording/share/3ny37ELByFlRmuVEOmAqev-YIJ-deWQ17-XxJEm4vjuwIumekTziMw | ||||||||||||
| 08/15/2019 | Agenda for Wednesday (08/14) meeting:
| Slides & recording of the session |
hopefully not missing any key comment - if anyone else remembers please comment)
56 Comments
ravi rao
OSAM project has also an Edge cloud. How is this Edge cloud automation different from the one defined in OSAM ? Can anyone please clarify this for me.
Regards,
Ravi
Ulas Kozat
OSAM as far as I understand addresses the use case of adding/activating edge clouds located in access networks. Each edge cloud (called access network peripheral POD) autonomously manages the VNFs/PNFs in its POD.
This group does not focus on how we add or manage edge clouds. Instead, my take on the discussions happening in this sub-team is that our focus will be on the optimization for edge applications with ONAP as the mediation layer for such optimization. E.g., we can take a use case such as an ultra low latency application hosted in the edge cloud and layout how ONAP can be used to collect real-time (or near real-time) data from network, users, and edge application; perform root-cause analysis for any SLA violations; and send feedback to the application and network functions for coherent application and network adaptation.
Srinivasa Addepalli
This group intends to figure out the gaps in ONAP in realizing thousands of edge-clouds and their automation And then propose solutions to fix the gaps. OSAM, in my view, is one scenario that can leverage edge-computing/automation. 5G and related use cases are the focus areas we are starting with, but many we would be working here would be in my view generic.
Prakash R.
Ulas,
Glad you brought to Notice. Ignorance is Bliss!!!
I went through same process and spoke to BHOJAN, SUMITHRA at ATT along with Vaishali CCI.
https://wiki.onap.org/plugins/servlet/mobile#content/view/25441429
Here is the link to VNF VPE on Onap use case page I was trying to position, where edge can be provider edge. The issue is OSAM has use cases for Fixed Network via MEF E-line/E-Lan using Optical/Ethernet access. Application as per MEC is hosted on Edge Cloud neither on Fronthaul nor on Backhaul but Midhaul. So intresting part is, we still need Application Client, Edge Application Server/Service and support for both statefull and staeless application. Thus I proposed Statelet besides the CMU Cloudlet at ONS-2018 to attach/detach Persistant Volume(PV) for state. May be this is optimization to go with that but functionally we must agree to some API's before we can optimize that based on common APIs/Microservices. May be this a good place to merage form all fronts to debate and get the right APIs and then the acceleartions that will make Data Plane meet the QoS needed to deliver edge services.MEC_Apps_ONS2018_Rev1.1.pdf
You certainly have the capability to go deep and help us resolve this.
Lets see how we get a common concensus on this to bring Baseline for Edge Application to be managed stateless as well stateful.
Thanks
Prakash
Srinivasa Addepalli
Added a presentation on the pre-work that was done as part of ONAP Edge-Computing adhoc group,.
ramki krishnan
Great timing Srini, I was about to add your presentation.
ravi rao
We at Fujitsu are really interested in this project. Can one of you please let me know how I can be more involved with this. We are currently working on R-CORD use case and would like to use similar architecture for other edge access and this looks like a good fit.
Regards,
Ravi
Ulas Kozat
Just start joining the meetings and bring your specific use case. The meeting info is posted on the wiki, but it will change soon to a new day/time agreed during the meeting.
Ulas Kozat
the meeting info is updated.
ramki krishnan
Thanks Ulas.
Ravi - please drop your contribution to the wiki and add your contribution as an agenda item for one of our weekly meetings. Looking forward to your participation.
Ulas Kozat
I did split the overview from scope and added high level material for overview.
Srinivasa Addepalli
Makes sense. Thank Ulas.
ramki krishnan
Srinivasa Addepalli - Raghu and I have moved the scope text suggested by you to the child page Edge Architecture & Work Items.
Cagatay Buyukkoc
There is a need of a broad category of APIs for applications and 3rd party applications to use to enhance the quality of service or experience. Rather than specifying individual APIs, the intent is to create an environment where any API can be "composed" or put together and delivered within the framework described.....
Raghu Ranganathan
>> for applications and 3rd party applications to use
This would be what ONAP exposes as Gil Bullard mentioned during last call. "Service(s)" can be composed from a set of attributes/functions in a service model.
Raghu Ranganathan
ramki krishnan - seems like Cagatay Buyukkoc is not available today. Also, since we just had a call this last friday, we can wait till next monday to give folks time to review/edit Edge Architecture & Work Items page. wdyt?
ramki krishnan
Let us go ahead with the call, since there are several topics to discuss and review.
Anh Le
Hi Ramki,
Could you explain what "ONAP offload" in your presentation is? A mini ONAP with reduced functionalities (like, just VNFM, etc) for the edge?
What APIs it use to talk with ONAP at Central orchestration level?
Thank you.
Srinivasa Addepalli
ONAP Offload consists of following : ONAP-Offload API and ONAP-Child
ONAP-Child consists of
I would not use term VNFM (as many view this as VNF vendor supplied) but some concepts from this can be leveraged here.
ONAP Offload APIs need to be clearly defined so that not only ONAP-Child, but also other open source/management-vendors can provide this functionality.
We will be adding more details here: Scaling using Offloads
Srini
Manoj Nair
Hi Srini,
I think there may be one more model in which VIM is federated instead of federated orchestration. i.e VIM and SDN controller managing distributed edge sites federate among themselves transparently. I guess this is a much more efficient mechanism than distributing the higher layers in the stack.
One more point is regarding Edge NFVI . Is it part of scope of Orchestration to bring up the NFVI for edge ? I guess edge sites are brought up on demand and VNFs are instantiated on those edge sites. If not orchestration solution, which component is responsible for bringing up edge sites ?
Additionally what is the right abstraction of edge site - i.e as an infrastructure service or as a VNF ? Assuming abstracted VNF LCM may take care of bringing up NFVI along with VNF.
Manoj
Srinivasa Addepalli
Hi Manoj,
Each edge is independent of each other and hence VIM level federation is not applicable here.
On Edge NFVI : No, it is not in the scope of ONAP. Zero touch provisioning work in Akraino will take care of bringing up Edge infrastructure. ONAP is mainly used for service orchestration, VNF LCM, Fabric control etc...
Role of Edge site: Yes, operators can bring up the VNFs at Edges and eventually operators, in my view, will provide IaaS functionality for instantiating third party edge applications.
Srini
ramki krishnan
Hi Anh,
It is being precisely defined as we speak. Looking forward to participation to help us shape it. Minimally, we see some components needed for real-time closed loop operation such as DCAE.
Thanks,
Ramki
Arash Hekmat
Regarding Apr. 23 comments. In the diagram above all arrows terminate in Multi-Cloud. But once we talk about distributed ONAP instances, it means all ONAP components (DCAE, Policy, SDN-R, OOF, ...), as well as Multi-Cloud itself, need to figure out and design how they would run in a distributed system. This could involve extending internal messaging systems: MSB and DMAAP. For example, DCAE project needs to design how a Central DCAE instance would communicate with many Edge DCAE instances. This is in the scope of those ONAP projects.
Then there is a separate issue of how a Central ONAP would communicate with External Edge Controllers. In that case, there are two possible options: (1) Every ONAP project (DCAE, Policy, SDN-R, OOF, ...) could also decide and design on its own how it would communicate with External Edge Controllers; OR (2) One central ONAP project could terminate all External Edge Controllers APIs and this central project could be Multi-Cloud and/or SDN-R or a new project.
Srinivasa Addepalli
Scaling using external controllers and how ONAP and Akraino can work together is being captured here: Scaling using Offloads
Arash Hekmat
I find that there is a lot of confusion in Edge Cloud discussions as to what is meant by Edge instance versus Central instance and how they interact. This group needs to define what is exactly meant by Edge and Central instances.
My assumption, based on the discussions and the diagrams so far, is that most people have the Hierarchical Control in mind.
Raghu Ranganathan
Arash Hekmat -
Until last week, the 'option 1' assumption had been 'single ONAP instance' ..but, with hierarchy for some components, eg., DCAE. But, based on OOM feedback, the new 'option 2' assumption is to consider separate ONAP instances. We need to finalize between these two as to what makes sense.
(Aside: per Srinivasa Addepalli, replace onap-edge with 'AOP' to neutralize...but, we want to allow for AOP=onap-edge as one example.
In the case of option 2 (separate instances),
About your point: "the communications between the instances would be mostly at the application or service levels",
Arash Hekmat
Thanks Raghu.
So loos like there is an agreement that we are talking about Hierarchical Control with separate ONAP instances at the Central and the Edges where some Edge instances could be non-ONAP platforms (AOP).
So, what remains is your last two points, which is whether Edge to Central data communication is at the network level or at application/service level, I think for Casablanca we need to pick one for clarity (probably one that is simpler, more realistic, to implement). However, since I am not a SON/Slicing expert, I wonder that if in the long run E2E network SON/Slicing is required for 5G, then doesn't that necessitate that Edges and Central communicate at the network level? Specially since in the vast majority of cases the E2E network is managed by one SP.
Raghu Ranganathan
>> Edges and Central communicate at the network level?
yes....hence, we have "2 activities" - see ONAP Activity GOAL #1 and #2 in Edge Architecture & Work Items .....as related narrowly to only ONAP enhancements.
These should drive what we need to specify as R2+ requirements for ONAP work.
In C+ releases, we can focus on app profiles that can be onap-managed apps, for example. So, additional 'app APIs' can become relevant at that time.
>> vast majority of cases the E2E network is managed by one SP.
E2E is a dicey term...but we will stick with it
. For a given Service instance, one ONAP-central would be responsible for the e2e SLS of that service. However, Slice components can be in any 'edge cloud domain' ...and, these domains are made to look/feel the same for many of the attributes as far as a ONAP-central is concerned, for example. Then, we have the 'easy button'.
Shekar Sundaramurthy
Continuing on the "ONAP instance" discussion from the meeting earlier today and requests for alternate naming suggestions: How about if we qualify the name to 'ONAP cloud instance' - example usage could be: "An Operator implementation of ONAP to manage its networks and services may be deployed across many cloud instances distributed across the regions where the operator provides services; in such an implementation a central ONAP cloud instance may communicate and coordinate its management across many edge ONAP cloud instances ". This still leaves open the phased evolution of what makes up an ONAP cloud instance.
This can disambiguate from the more common usage of instance (in my mind) - e.g. of usage "Operators A & B have agreed on a business application-level interface between their ONAP instances for purposes of interworking their services"
Raghu Ranganathan
yes, "an operator implementation" is what we are focused on. The edge cloud provider (internal BU or external entity) may use onap for their internal use...but, we are ignoring for now. The "operators A&B" interactions view is currently for the IaaS/PaaS API....where we don't worry what platform edge CP uses.
Raghu Ranganathan
>> "onap cloud instance"
Desire is to distinguish between (a) components of one onap, vs. (b) separate onap instances......for "an operator". Not sure what the community's consensus is for an instance, ie., without SO is not considered an instance?
Michael Hwang
I want to point out that the Edge Compute white paper mentions the following:
How does this requirement for developers influence the architecture between hierarchical and federated? Is this requirement achievable in "either or" architecture or is there some trade off here?
Raghu Ranganathan
>> for system designers to dis-aggregate computing functionality across platforms and across geographies
hierarchical-vs-federated might not be relevant for this b'coz ONAP-central (blue SP) decides which edge domain to use, etc. See the steps 1/2a/2b captured in the gliffy in Edge Architecture & Work Items.
Srinivasa Addepalli
Edge-Automation group is only concentrating on the Offloads (Hierarchical control in your comment).
With hierarchical control, edges may be running some variations of ONAP or something else. To make it generic, today too, we discussed the keep the offload entity in the edge generic and hence we want to refer to it with generic term (example: Automation Offload Platform).
Srini
Rebecca Lantz
Is there a plan for PNF registration at ONAP-Edge? (Specifically considering 5G PNP use case authored by Benjamin Cheung) My assumption is that 5G DU PNFs would register with ONAP-Edge and that corresponding 5G CU VNFs would need to be created in the same ONAP-Edge. Its unclear to me how this would happen, and how the correct set of microservices would be deployed at the ONAP-Edge. If there is information on this please direct me.
Benjamin Cheung
Rebecca Lantz - This is definitely something that is still missing in ONAP. I have discussed this very topic with Marge Hillis, and it deserves further study. In R3/Casablanca the ability for ONAP to manage a PNF is still very rudimentary. It leaves a lot to the operator to orchestrate their network elements properly. From the point of view of a PNF registering with ONAP though, it will use the Plug and Play flow as described on the Plug and Play Wiki Page: https://wiki.onap.org/display/DW/5G+-+PNF+Plug+and+Play , the complexity lies in the modeling of a service on the PNF at the edge and coordinating it with a service representing the CU at the edge and orchestrating that together to represent a gNB (5G RAN NodeB Base Station). -Ben
Raghu Ranganathan
Given the separation of concerns approach - edge Cloud Provider vs inter-galactic SP -, the infrastructure elements, eg. 5g pnf/vnf/servers/storage/etc., would register with whatever is the edge CP's systems. We have not discussed this bcoz edge CP has been a "black box". Whether the edge CP has to use a particular xNF (from vendor X) is TBD....and more likely when VNF ...vs PNF (no?).
What might be registered with:
1) onap-central: some lower level service(s) in a higher level service - see Gil's preso in arch tiger team discussion.
2) onap-edge: some hooks to collect telemetry..but also hooks to request new state if and when we do closed loop, etc.
...more to discuss after Ramki is done finalizing Casablanca work.
Srinivasa Addepalli
ONAP-Edge is set of services to offload some functionality of ONAP-Central.
ONAP-Edge is expected to have following as shown various presentations including this one : https://wiki.onap.org/download/attachments/28379482/Edge_ONAP_WG_v4.pdf?api=v2 and Scaling using Offloads.
As Raghu mentioned, initial goal is to offload infrastructure statistics collection and aggregation of same at the ONAP-edge (regional controller). This work item can be found here: Edge Scoping MVP for Casablanca - ONAP Enhancements#ONAPEnhancements-AggregatedInfrastructureTelemetryStreams(AlignswithHPArequirements,CombiningeffortswithHPA)
Srini
Rebecca Lantz
Thanks Srinivasa Addepalli, Raghu Ranganathan and Benjamin Cheung. So my take on this at present is that for Casablanca release we should not anticipate ONAP-Edge to support PNFs yet. I do agree with Ben about the inherent complexities and also that this is something we should start studying and considering for Dublin release. I'm not sure that ONAP-Edge would be useful for RAN automation if PNF support is not included and must interface with ONAP-Central.
Srinivasa Addepalli
@Rebecca Lantz
I agree with you. As mentioned in Scaling using Offloads pictures, intention is to PNF LCM in ONAP-Edge (Regional level), mainly for same reasons as others - Large number of PNFs such as RAN/eNBs and hence distribution of some operations at the regional level and regulatory reasons where some information can't be shared with ONAP sitting in different regulatory domain. Yes, this is something we need to seriously think about doing in Dublin release.
Raghu Ranganathan
>> not sure that ONAP-Edge would be useful for RAN automation if PNF support is not included
Seems like there is confusion. ONAP-edge is *not* responsible for RAN Automation in the edge cloud domain. We have assumed that the cloud domain Orchestration toolset to onboard and set up the cloud nodes and any PNFs (eg.DU for RAN, etc) is independent of onap-edge instance.
How can we clarify this more clearly in the Edge Scoping wiki page? We have gliffy diagrams and also text. But, we seem to fall back to the same conversation of edge cloud domain being managed by onap-edge....when that is not the case.
Rebecca Lantz
Indeed, I guess I am confused. My understanding is that ONAP-edge would be used to set up closed loop automation for a set of gNodeBs, taking corrective actions, reconfiguring neighbours, etc. and potentially feeding data results into ONAP-central. This would mean ONAP-central isn't overloaded with collecting more data than it could handle. If there is a different purpose could you update the wiki page here? Edge Automation through ONAP
Raghu Ranganathan
That closed loop is relevant...but not the infrastructure.
From the intro paragraph at top of page, we have inlast sentence: "group analyzes the orchestration requirements of services over various edge clouds".
Also, we have Edge Scoping child page hoping to focus the effort. Please read that and let us know what needs clarity. Looking forward to your feedback.
Rebecca Lantz
Thanks Raghu. I've looked through the Edge Scoping page but do not see PNFs referenced at all. If there is a place that indicates the intention of how gNB and eNB PNFs would work with ONAP-edge architecture please let me know. Thanks very much.
Raghu Ranganathan
>> Edge Scoping page but do not see PNFs referenced
1) sequence diagram gives a high level workflow, e.g., request IaaS. One such request would be need DU (PNF), etc. We have not discussed this IaaS in detail as yet.
2) onap edge mvp (below sequence diagram) has 'oof enhancements' for deployment of pnf/vnf. we have not discussed this in detail as yet....and tied to the 'IaaS' request.
(edit) Ramki has been driving discussion on Multi-Cloud related to VNF....but not PNF as part of IaaS.
What is important to note - we have assumed that edge domain infra is the responsibility of the edge domain provider. There can be deployment variations like (a) edge domain provider is responsible only for cloud nodes, ie., server rack, (b) onap-central is still responsible for rest of edge infrastructure like cell site gear, DU/PNFs, transport, etc..
>> how gNB and eNB PNFs would work with ONAP-edge architecture
see column for 'edge cloud functionality' in onap edge mvp. The onap-edge just sees 'functions'/'services' that it can monitor/collect/change state.
Evgeniy Zhukov
I have re-upload todays contribution about MEC, as Ramki ask: Edge Automation Potential Strategies for Deploying ONAP_v1.1.pdf
Please let me know, if it is also not downloadable.
Raghu Ranganathan
Folks, 2 useful and possibly relevant openstack 2018 Vancouver videos. Hopefully, we could get those presenters to share their insights in our Edge calls:
1) Akraino Edge Stack: see around 20min in the video for latest view on the stack
2) Network API Exposure and Context Management at the Edge
Margaret Chiosi
Can we agree that we will treat the edges like black box and Not work as first priority creating a 'mini-ONAP' running on the edge?
If we agree then we should just focus on the interface/API to the edges. Then we can evolve as the industry evolves
Arash Hekmat
Agreed. There are already projects (e.g. https://www.akraino.org/) that specifically address the Edge and MEC.
Srinivasa Addepalli
On Akraino: As we speak, there is an active discussion going on the scope of Akraino. I would not depend on Akraino yet on this edge orchestration. This is something we need to think about to do as part of Edge-automation group.
Srini
Raghu Ranganathan
Note there are 2 different aspects:
1) edge domain's orchestration stack
vs
2) onap component, eg. Dcae, as an edge workload for local analytics
Item (2) is with edge domain as "black box" and what we have been discussing mostly. Item (1) and (2) are orthogonal, of course
ramki krishnan
Inline with Raghu & Srini.
In fact, we have done good analysis on various edge deployment options
1) Part of operational components e.g. Analytics
2) All of the operational components, e.g. Analytics, Closed Loop
3) All of the deployment and operational components, e.g. Analytics, Closed Loop, Orchestration
One of the realizations of these deployment options could be through some of the ONAP building blocks.
Arash Hekmat
I think clarity is the key in achieving real results for Dublin. The 2 aspects: (1) running ONAP components as workloads on the Edge; and (2) positioning ONAP as an Edge framework; are very different; (2) is much bigger than (1).
These 2 aspects should be clearly presented to the Arch and TSC for approval. As far as I know, (1) is partly approved but not (2) but I could be wrong.
From ONAP Central's perspective, the most important issues in both cases are:
For NF Creation/LCM the role of Multi-Cloud is clear as a cloud mediation. But NF Configuration/OAM/Analytics roles need to be defined. e.g. Which ONAP Central components would interact with a DCAE instance running on the Edge?
i.e. Which Event Protocols: DMaaP (Kafka), ProtoBuf, VES, DDS, ...; Configuration Protocols: REST, NETCONF, ...; Configuration APIs: ETSI, MEF, TMF, Internal ONAP Defined, ... would be used between ONAP central and the Edge? Where: Standard APIs: ETSI, MEF, TMF are only applicable for aspect (2) "positioning ONAP as an Edge framework" in the context of ONAP External API.
Manoj Nair
I think if we try to generalize the above discussion there are views like - 1) Do we need to standardize/modularize the components and their interfaces (i.e ONAP internal functional APIs) based on different deployment options or 2) Do we need to standardize the APIs of ONAP as a black box interacting with any other domain ?. In my view both are important
If I understand correctly Margaret is suggesting the second approach - where ONAP as a black box interacts with any other domain orchestration solution (ONAP or non-ONAP) through standard APIs - This will be a domain to domain interaction. In this case, assuming there is an edge orchestration domain (separate administrative domain) with which Central ONAP interacts, this may be potentially driven through a delegation model. In the delegation model, the associated domain is expected to be self-reliant with minimal monitoring of the delegating entity. So NF configuration/OAM/Analytics is expected to be handled by respective domains - be it ONAP or not. Assuming Edge is realized using a non-ONAP solution, there should be a well-defined policy/contract (I guess this is the SLO what Parviz referred from Gil's presentation) to ensure the delegation model works fine. This may vary across deployments and very difficult to standardize unless we bring in the options to define the policies/contracts. Additionally, there are two aspects of orchestration - NF and Application. If we separate these two as two separate domains, then coordination becomes another challenge.
There can also be a case where edge orchestration can be visualized as an extension of central orchestration - i.e distributed model. In this case, it may be mostly the component to component interaction (without strictly limiting through a contract or policy across administrative domains) and this may be a case for #1 listed in Arash's comment. This again has implications for ONAP component capability of modularity, distributed deployment support, consistency of states etc.
In the first scenario - standardize/modularize the components and their interfaces based on different deployment options - this may serve many use cases not limiting to edge alone. I don't think #2 from Arash's comment is the real intention. But reusing as much capability inbuilt in ONAP for supporting edge use cases is what is intended (as used in Akraino). So, in this case, ONAP is not positioned as Edge framework but enabling a lightweight deployment of ONAP for supporting Edge use case. I guess "modularity to enable edge operational need" is the key here.
Regarding - Which ONAP central components would interact with components - I think this is the MVP table in the Edge scoping page attempted to do.
Regarding - How ONAP central components would interact with components running on the Edge - I think this is a question with a wider scope which includes interaction between domains and also the interaction between components in a distributed deployment.
Arash Hekmat
Excellent summary Manoj, I broadly agree. Just a few points that I think need to be raised:
I feel that in the confusion created by the complexity of distributed networks, such as 5G and Edge clouds, the role of ONAP is becoming hazy for some which I think is a slippery slope for ONAP.
ONAP is primarily an End-to-End Network Service management framework (i.e. Central ONAP). This means that ONAP is the Top Network OSS system that network service providers would use to Create, Configure, Monitor and Optimize their network services End-to-End throughout the life cycle of the service.
This means that, at network creation time, ONAP is the top Orchestrator that would delegate Orchestration, if needed, to lower Domain Orchestrators. So ONAP should primarily work on how to fulfill its role as the E2E Network Service Orchestrator.
At configuration time, ONAP is the holder of the E2E Network Service Configuration that is pushed down to all Network Functions that reside in lower Orchestration Domains. So ONAP should primarily work on its role as the E2E Network Service Commissioner.
After network creation and configuration, although the monitoring and optimization, i.e. OAM/Analytics, can be partially offloaded to the lower Network Domains but the catch is that the lower domains must keep Central ONAP informed, at all times, of the results (i.e. the summary) of any and all actions that are taken in the Domains. Because ONAP is the holder of the End-to-End Service SLA and should always be aware of the overall status of the service. So ONAP should primarily work on its role as the owner of the E2E Network Service SLA as an aggregator of lower Domains' states and providing the necessary optimization instructions to the lower Domains in a way to guarantee the Global E2E Network Service SLA.
Michael O'Brien
Working through edge automation here and there https://wiki.opnfv.org/display/EC/Edge+cloud