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

Key Presentations:

Key ONAP Project Impact:

Dublin Plan:

Frankfurt Plan:

Architecture Task Force - Edge Automation through ONAP Arch. Task Force - Distributed Management (ONAP etc.) components

Call Schedule:

List Subscription/Meeting Notification:

WG Coordinators:  Ramki Krishnan


  File Modified
PDF File MEC_Apps_ONS2018_Rev1.1.pdf Apr 02, 2018 by Prakash R.
Microsoft Word Document Edge Scoping-r3.docx Apr 05, 2018 by Cagatay Buyukkoc
Multimedia File GMT20180406-170638_Ramki-Kris_1920x1080.mp4 Apr 06, 2018 by ramki krishnan
Microsoft Powerpoint Presentation Edge Automationissues.pptx Apr 23, 2018 by Cagatay Buyukkoc
Microsoft Powerpoint Presentation ONAP-edge-automation-wg-usecase-update-04-30-2018.pptx Apr 29, 2018 by ramki krishnan
Microsoft Powerpoint Presentation ONAP-edge-automation-wg-tsc-update-05-10-2018.pptx May 09, 2018 by ramki krishnan
Microsoft Powerpoint Presentation ONAP_Edge_Automation 5G AR_VR Use Case v05.pptx May 14, 2018 by Evgeniy Zhukov
PDF File Edge-ONAP_Pva_10.pdf May 29, 2018 by Pasi Vaananen
Microsoft Powerpoint Presentation ONAP-edge-automation-wg-arch-update-06-05-2018.pptx Jun 04, 2018 by ramki krishnan
Microsoft Powerpoint Presentation DMaaP Edge.pptx Jun 11, 2018 by sunil unnava
Microsoft Powerpoint Presentation ONAP-Edge-management-network-connectivity_v2.pptx Jun 13, 2018 by Srinivasa Addepalli
Microsoft Powerpoint Presentation ONAP-mc-sdn-v3.pptx Jul 17, 2018 by ramki krishnan
PDF File Edge Automation Potential Strategies for Deploying ONAP_v1.1.pdf Aug 13, 2018 by Evgeniy Zhukov
PDF File Edge Automation Potential Strategies for Deploying ONAP_v1.7.pdf Aug 27, 2018 by Evgeniy Zhukov
PDF File Edge Automation Potential Strategies for Deploying ONAP_v1.8.pdf Sep 03, 2018 by Evgeniy Zhukov
Microsoft Powerpoint Presentation ONAP-Edge-ORANupdate-Sept2018.pptx Sep 12, 2018 by Raghu Ranganathan
PDF File Edge_ONAP_WG_v7.pdf Sep 26, 2018 by Srinivasa Addepalli
Microsoft Powerpoint Presentation ONAP-edge-proposal.pptx Oct 10, 2018 by ramki krishnan
Microsoft Powerpoint Presentation ONAP-edge-proposal-v1.pptx Oct 10, 2018 by ramki krishnan
Microsoft Powerpoint Presentation Edge_ONAP_WG_v7.pptx Oct 21, 2018 by Srinivasa Addepalli
Microsoft Powerpoint Presentation ONAP-edge-proposal-v2.pptx Oct 24, 2018 by ramki krishnan
PDF File ONAP-edge-automation-OSM-discussion-10-31-2018.pdf Nov 07, 2018 by ramki krishnan
Microsoft Powerpoint Presentation ONAP-edge-automation-update-arch-10-29-2018-followup-11-07-2018.pptx Nov 07, 2018 by ramki krishnan
Microsoft Powerpoint Presentation Distributed_analytics_v3.pptx Nov 20, 2018 by ramki krishnan
Microsoft Powerpoint Presentation ONAP-Valet_edge_usecase.pptx Nov 20, 2018 by ramki krishnan
Microsoft Powerpoint Presentation edge-cloud-info-model-notes.pptx Dec 05, 2018 by Arun Gupta
Microsoft Powerpoint Presentation DCAE Platform Requirements.pptx Jan 14, 2019 by ramki krishnan
Microsoft Powerpoint Presentation ONAP-DDF-Distributed-Analytics-framework-v1.pptx Feb 08, 2019 by ramki krishnan
PDF File EOM overview for ONAP community.pdf Feb 23, 2019 by ramki krishnan
Multimedia File zoom_1.mp4 Feb 23, 2019 by ramki krishnan
PDF File ONAP review - Cloudify Cloud Native approach.pdf Mar 14, 2019 by ramki krishnan
Microsoft Powerpoint Presentation Management Orchestration_v8-arch-update-04-02-2019.pptx Apr 02, 2019 by ramki krishnan
Microsoft Powerpoint Presentation Management Orchestration_v9-arch-update-04-16-09.pptx Apr 17, 2019 by ramki krishnan
PDF File cloud-native-edge-mgmt.pdf May 09, 2019 by ramki krishnan
PDF File CloudNativeNFVONAPOPNFVSDWAN.pdf May 09, 2019 by Srinivasa Addepalli
Microsoft Powerpoint Presentation ONAP Orchestration - part1.pptx May 17, 2019 by ramki krishnan
Multimedia File zoom_0.mp4 May 28, 2019 by ramki krishnan
Microsoft Powerpoint Presentation Management Orchestration-DCAE-Platform Extension.pptx Jun 21, 2019 by Vijay Venkatesh Kumar
Microsoft Powerpoint Presentation ONAP Orchestration.pptx Jun 25, 2019 by ramki krishnan
Microsoft Powerpoint Presentation Management Orchestration_v5-arch-update-06-25-09.pptx Jun 25, 2019 by ramki krishnan
Microsoft Powerpoint Presentation Edge-automation-TSC-update-08-29-2019.pptx Aug 28, 2019 by ramki krishnan
Microsoft Powerpoint Presentation Edge-Coordinator-TSC-update-10-24-09.pptx Oct 22, 2019 by ramki krishnan
Microsoft Powerpoint Presentation ONAP Cloud Registry.pptx Oct 22, 2019 by ramki krishnan

Child Pages

Links to Other ONAP work related to "Edge"

OpenSource Access Manager (OSAM) Use Case - context of "Edge Orchestration" for Fixed Access

Use case proposal: 5G- RAN deployment, Slicing, SON - context of "Edge Compute" for hosting CU function

Links to other Community Work

OPNFVhttps://wiki.opnfv.org/display/AUTO/Auto+Use+Cases - "Service Provider's Management of Edge Cloud"

AKRAINOhttps://www.akraino.org/ – "Open source software stack to improve the state of edge cloud infrastructure"

AKRAINO TECH DOChttps://docs.google.com/document/d/1NDZWFpMUVe0BPwcsOYecNrwwNDnlFmkdP4jur5pE4oo/edit#

OSF EDGE COMPUTING GROUPhttps://www.openstack.org/edge-computing/ - "Open source initiative to explore cloud edge computing related use cases and scenarios and work on addressing the requirements the group identifies."

"NGMN 5G RAN  Whitepaper" https://www.ngmn.org/fileadmin/ngmn/content/downloads/Technical/2018/180226_NGMN_RANFSX_D1_V20_Final.pdf


WG Coordinators: Ramki Krishnan

Cagatay BuyukkocAT&T
Gil HellmannWind RiverYes
Lyndon OngCiena


 Parviz Yegani Huawei
Pasi VaananenRed Hatyes
Remus TanCiena
Ramesh NagarajanAccenture
Jasmin AudetGenicom
Sergio SlobodrianCienayes
Anh LeNetcracker
Shekar Sundaramurthy  AT&T yes

Simone Mangiante <simone.mangiante@vodafone.com>



Yoav KlugerAmdocsyes
Borislav GlozmanAmdocsyes
Ning SoReliance Jioyes
Mathieu DuperreEdgegap
Xin Miao Huawei
Ravi ChunduruVerizon

all Notes

Apr 06, 2018
  1. Permanent time for meetings: Mondays 9am est is proposed by multi parties
  2. Review the Edge scoping doc/updates
  3. Review the list of docs submitted
  4. Open discussion for follow up topics with priorities
  5. Clarify where/what is Edge (tentatively, a gold star has been awarded to one :-)..but, could be awarded to more!)
  6. ONAP specific aspects/scoping doc addressed this?

ZOOM Recording: GMT20180406-170638_Ramki-Kris_1920x1080.mp4

Meeting Notes:

  1. Meeting time consensus - 8:00am PT. Ramki to reach out to OOF team to change the time of OOF meetings.
  2. Cagatay reviewed Edge Scoping-r3.docx.
    • Discuss where is "Edge" and relevant applications for with a app response time context
    • Gil Bullard brought up relevance to ONAP context, i.e. ONAP services to external party vs ONAP Multi-VIM driven management/optimization. Federated ONAP operations may be relevant here.
      • The consensus is to discuss this after we agree on the use case scope.
    • Alexander Vul brought up the distinctions between user equipment vs customer premise equipment in mobile node like a car in the context where "Edge" might be.
      • The demarcation between network provider and end user is left up to service provider. In the case of a car example, the demarc is the Mobile SIM (4G/5G etc.).
    • ramki krishnan brought up architecture vs use case distinction in the Applications and time scales section.
      • The consensus was to move architecture details to a separate section.
    • ramki krishnan brought up need for additional examples other than RAN for item 2) "Near-real-time Apps" in the Applications and time scales section.
      • The consensus for the team to provide input.
    • Created child page Edge Architecture & Work Items with some updated text.
      • Team to review and provide comments.

Agenda to be finalized 24 hrs. before each meeting.

Folks are requested to review the contributions and come prepared with questions.

Apr 09, 2018
  1. Housekeeping:
    1. use case sub committee list subscription for addressing email distribution issues –

      use case sub committee link (https://lists.onap.org/mailman/listinfo/onap-usecasesub)

    2. target dates for input to use case/architecture sub-committee from a Casablanca perspective
  2. Any additional contributions to discuss from the contributions section?
    1. Make progress on Edge Scope - child page.

ZOOM Recording: zoom_0.mp4

Meeting Notes:

  1. Housekeeping
    1. Informed the team through email
    2. Target Dates:
      1. April 30th for Use Case sub committee update about functional requirements for Casablanca and beyond
      2. May 15th for Architecture sub committee update about any changes to the functional/reference architecture for Casablanca and beyond
  2. Contributions:
    1. Distinction between Akraino and this work - question from Margaret Chiosi
      1. Akraino is an integration project using an opinionated edge stack based on certain open source components.
      2. This effort in ONAP would treat Akraino as another type of edge cloud and managed though ONAP Multi Cloud and other ONAP relevant components.
    2. Edge Architecture & Work Items discussion
      1. Priorities for Casablanca – initial thoughts captured in the Edge Architecture & Work Items wiki
      2. Need to differentiate between 3rd party and operator provided applications – differentiate along real-time and non-real-time and application characteristics – input from Vimal 
      3. MEC_Apps_ONS2018_Rev1.1.pdf was briefly mentioned by Vimal Begwani as an example of a 3rd party edge app (e.g. pothole fixer app) including relevant MEC APIs; Follow up action: Request Prakash Ramchandran to present work in one of the call.
    3. Edge_ONAP_WG_v4.pdf (updated deck) from Srinivasa Addepalli
      1. Edge Deployment/Functional Architecture diagram (slide nos. 7,8, 9) provide initial context for this work. (what diagram to add in Edge Architecture & Work Items wiki?)
      2. For scalability, there was a discussion about child ONAP with a subset of ONAP components.
      3. Edge Requirements - initial thoughts in slides 4, 5 - Vimal Begwani, Cagatay Buyukkoc to review and expand.
Apr 16, 2018
  1. Differentiate between 3rd party and operator provided applications  – input from Vimal Begwani
  2. Differentiate along real-time and non-real-time and application characteristics – input from Vimal Begwani
  3. Edge Requirements - input from Vimal Begwani & Cagatay Buyukkoc
  4. Complete discussion Edge_ONAP_WG_v4.pdf for Edge Architecture - Srinivasa Addepalli

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

  • Shekar Sundaramurthy: for minimum viable - could let it be decided at run time via OOF
  • Yoav Kluger: 2 dimensions - (1) apps location based on requirements, and (2) onap functions closer to edge
    • Vimal Begwani: apps = think as VNFC
    • So, VNFC → IaaS requirements from cloud provider Business Unit
    • hence, one output of this work is to define additional IaaS from Cloud Provider for Edge deployment
      • Alexander Vul - need to model Service Components in a way to allow for internal and external domain resources for IaaS
      • Parviz Yegani - need to consider work as part of external api work...when API to external partners.
    • Also, second output: onap-edge workload functions needed

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?

  • Vimal Begwani- SP determines choice of domain based on meeting various requirements

Arash Hekmat

  • APIs imply going thru multi-cloud? (raghu clarified that the current multi-cloud work is to be the 'adapter' interface between onap components and rest of the world)
  • Edge-to-Edge? (raghu clarified that currently the thinking is it is sufficient via central onap)
  • DCAE hierarchy? (as vimal clarified, any cloud provider can be used to host onap components,...but, we didn't want to corrupt the diagram with too many repetitive details)

2) Srinivasa Addepalli reviewed Infrastructure Profiles in Edge Architecture & Work Items page

  • reviewed "large" profile as example
  • ramki krishnan
    • OVS-dpdk? (srini clarified that profile example is specific to akraino.)
    • DVR for VM<>container networking? for same VNF? (srini clarified that either can be relevant)
  • Parviz Yegani - networking by onap? (raghu clarified - yes, sdn-c is responsible for endpoints within domain for underlay, but openstack/k8 responsible for sr-iov/ovs aspects. Also, ramki clarified need for intra- vs inter- cloud configuration)
  • Tom Tofigh - UPF (5G) for forwarding pipeline. But, we don't have SSD or memory fabric to support certain services for UE. Tom gave example of 1 RU of ssd, 1RU of GPU, 1 RU of RAM, etc...and, the edge node is composed for use by UE. So, as example, ephemeral vs long lived storage, etc. offered as part of service using the edge compute node.
  • Vimal Begwani - need to keep requirements general (vs akraino specific?)...so, different implementations can support it.

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

  • The presentation explained different types of APIs - Admin and User APIs - from the perspective of cloud provider's internal operations. It remains to be seen if these would be used by a ONAP service provider
  • Also, it did not consider separation of a cloud provider from a ONAP service provider

Reviewed Infrastructure Profile summary and Gliffy Diagram in Edge Architecture & Work Items

  • After the call, two "ONAP activity goals" were captured in the edge infrastructure profile summary and ONAP edge automation sections
May 7th, 2018

Hierarchical DCAE - Lusheng Ji, Vijay Venkatesh Kumar

High level review of Multi-Cloud use cases - Edge Cloud Infrastructure Enablement in ONAP

  1. Reviewed status of work done - used Edge Architecture & Work Items to briefly review sections/content

  2. Hierarchical DCAE - (link to ppt to be updated later)
    • Subset of components needed in an edge was discussed
    • Control agent (Consul) is used to tie parent/child instances
    • DMaaP bus allowed exchange of events/notifications/etc to parent
    • Shekar Sundaramurthy - one ONAP instance? yes, assumed for this discussion
    • Srinivasa Addepalli - additional "apps" could be non-onap, eg., Prometheus? yes, possible
  3. Reviewed gliffy/arch
    • Explained ONAP-central <> ONAP-edge, ie., onap-edge instance shown in figure aligned with 'edge cloud' used in figure. Clarified that other edge domains can be with onap-edge as well if needed
    • Yoav Kluger - would be useful to clarify with a simpler/higher level view showing additional onap-edge instances, etc. Also, maybe multiple views for different aspects. (To be followed up with Yoav for what is needed)
  4. (Post call notes) ramki krishnan attended OOM call on May 9th. Recommendation from OOM team is to consider separate ONAP-edge instances. So, included a new 'panel' with the feedback from OOM call in Edge Architecture & Work Items wiki page.
May 14th, 2018

1) Evgeniy Zhukov et al., Netcracker – AR/VR Use Case:

  • Inter edge cloud interface;
  • Exposure concept; and
  • Clear separation of Packet and Application processing on the same compute edge cloud resources.

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
Please review the section on MVP Edge Architecture & Work Items#ONAPEdgeMVPforCasablanca

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

  • Sekar to make suggestions on alternative names

- 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.

  • ramki clarified using app profile table about RT case avoiding onap component in the path.
  • raghu clarified that option c in mvp includes policy/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

  • edge cloud slot

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:

  • Gil Bullard: Should an edge cloud provider expose gory fabric details to ONAP-edge or ONAP-central? In other words, would ONAP's A&AI need to have an inventory...and why?
    • raghu suggested that this depends on business relationship/trust as well as need. More likely if internal BU vs external Partner
    • One need might be an IaaS slice(s) for 'onap SP' to manage infrastructure slice(s) as if they owned it
    • Alternatively, simpler to request edge provider to handle details via a 'service' definition for the Service Component needed from the edge domain which will include Service Level Specification/Agreement (SLS/SLA) would be easier and consistent across both trusted/untrusted edge domains.
    • Impact to ONAP work would be how detailed an object model for IaaS
  • Parviz Yegani: Gliffy needs to be updated to clarify use of 'external api' to partners
    • raghu: yes, action item from prior calls
  • Prakash Ramchandran: highlighted the interactions with other work such as in openstack (eg., Pooling) and suggested that ONAP's IaaS/PaaS API work could take advantage of such work.
  • Frank Zdarsky: suggested that IaaS/PaaS API is already available with many Cloud Providers. So, ONAP could just use them rather than try to create new.

Chris Donley noted the plan for review during March 29th arch call.

Related discussion during VNF onboarding slot when discussing 'external VNFM'

  • Srinivasa Addepalli understood that an 'external VNFM' in an edge cloud provider could interface with onap-central if an 'external VNFM' supported ETSI SOL003.
  • raghu suggested that the edge cloud provider might not allow exposure of their VNFM.

Related discussion during OOM slot - federated vs distributed K8s cluster for geo redudancy

  • federated view showed MEF 17 PoC example, ie., ONAP instances in different admin domains att/orange. Use of MEF reference point (eg., Interlude) for relevant APIs was mentioned.
  • raghu clarified that edge automation effort is about onap instances owned by same admin ...albeit instances are hosted in different domains, ie., onap-central in SP domain vs onap-edge in edge CP domain.
  • ramki clarified that onap-edge instance is dependent on onap-central in a hierarchy.

((warning) hopefully not missing any key comment - if anyone else remembers please comment)

May 29

(vs May 28 since Memorial Day Holiday in USA)

  1. Pasi presented on relevant ONAP Edge Components. Provided insight on closed loop Fault Management as a key example of needing more ONAP services at the Edge
  2. MVP options A/B/C captured some of Pasi's insights, eg., DCAE, closed loop/policy, resiliency, etc. But, the debate is what is appropriate Casablanca goal vs longer term goals. So, "key changes needed for Option B" had the enhancements to various ONAP services including aggregation of events/faults/metrics.

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
  1. ramki krishnan: Finalize MVP: Edge Architecture & Work Items#ONAPEdgeMVPforCasablanca
    1. Key Changes needed for Option B - minimal needed?
    2. for Casablanca? relevant steps in sequence diagram?
  2. Capture/Resolve any outstanding questions on architecture and sequence gliffy diagrams
  3. Tom Tofigh - may present on functional components for edge/CORD

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
  1. Communication options across ONAP Central <-> ONAP Edge and/or Edge Cloud - Srinivasa Addepalli to present
  2. DMaaP role in Edge Deployments - sunil unnava to present

June 18


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

  • Shankaranarayanan Puzhavakath Narayanan discussed HAS in Edge Orchestration and for OOF to know PDC info for homing
    • terminology alert: ONAP used 'cloud region' for a openstack instance (or a given control plane), ie., should be PDC in figure. But, figure has cloud region = 1 or more PDCs. Need to refine terms
      • slide shows 3 cloud regions for 3 different like openstack/vmware/other.
      • If we want to align terms to Public cloud, then region as a geographic location such as US East (Northern Virginia)....with Availability Zones within regions, etc.
      • A&AI impacts? maybe keep current terms. But, either look to tweak or MC will do mapping as needed.
    • homing choice
      • depends on information available such as utilization in a PDC so as to optimize selection across Cloud Regions.
      • So, casablanca plan for internal-private cloud is to have detailed view of Cloud Region (type) / PDC / (Utilization + capabilities + etc.). But, model can be pruned to hide details when we transition to having edge cloud orchestrator


  • as fyi, public cloud provider resources can be a <Region, AZ/Interconnect location>
    • eg., AWS: <US east (N. Virginia), us-east-1a>
    • eg., GCP: <europe-west2 (UK), lhr-zone1-4>
TermONAP - current modeltuple of form
Cloud Regioncloud region = Openstack region, ie., a PDC.

<Cloud Controller, (list of 1 or more PDCs)>


<Cloud Domain name, (list of 1 or more PDCs)>

Note: list of 1 or more PDCs optional for internal vs public?

Availability Zonenone?

<Cloud Controller, AZ, (list of 1 or more PDCs)>


<Cloud Domain name, AZ, (list of 1 or more PDCs)

Note: list of 1 or more PDCs optional for internal vs public?

July 2

Casablanca MVP Deep Dive

Anything else?

(draft notes - to be cleaned up)

Ramki reviewed policy example. Some Qs discussed

  • MC interpreting policy for private vs public ..or, OOF?
  • cost info? via API for public...but, via policy for private. MC to fetch cost policy
  • cloud vendor? not needed since 'cloud agnostic'. for example, a certain parameter like 'min guarantee' can be true/false and the MC can decide choice of cloud region that can support, etc. So, depending on hard vs soft constraint, the choice can be met. But, need both HW capabilities, eg., SR-IOV flavor, and also capacity details before deciding.
  • reservation? present in OOF, e.g., SDN-C reserved network, etc....but, not used in ONAP
  • OOF to use returned cost values? R2 didn't have a need. Need to enhance algorithm to factor in cost
July 9

Casablanca MVP deep dive

Edge Scoping MVP for Casablanca - ONAP Enhancements#ONAPEnhancements-Cloud-agnosticPlacement/Networking&HomingPolicies(Phase1-CasablancaMVP,Phase2-StretchGoal)

July 16th and July 23rdMeetings Cancelled – Casablanca MVP Deep Dive Discussion with Relevant PTLs for R2 planning
July 30th

August 6thCasablanca MVP discussion contd.
August 13thCasablanca MVP discussion contd.
August 20
  • MEC discussion
  • MEC -as application aware
    • view as a management workload, eg., part of ONAP. In other words, not part of connectivity service chain
    • view as a function for collecting/analyzing/etc. One such example is DCAE for implementation to do collecting/analyzing/etc...and expose context APIs to analytics apps
    • analytics apps - as consumers - can be either internal or external (from 3rd party)
    • can be per edge domain for real-time cases. But, could be regional for non-real time
  • MEC services defined so far (ETSI): Location API, Radio info API, Bandwidth API
    • 'platform' = having access to info, e.g., data plane object of radio link
  • MEC infra mgr? this will be no different from any controller

(additional notes to be updated later)

Aug 27

Sept 5
  1. Support for K8S (Kubernetes) based Cloud regions (Srini)
  2. Edge Automation Potential Strategies for Deploying ONAP_v1.8.pdf (Evegeny/Manoj)

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?


  • focus on exposing network and end point state (eg., location) to MEC platforms
  • not worry about applications themselves since can be proprietary


  • Margaret suggested intent based approach and letting edge domain doing most detailed work
    • we have not focused on how the edge domain is realized
  • used sequence diagram in Edge Architecture & Work Items to clarify the alignment with margaret's opinions
    • grey boxed region: intent request to edge domain and edge domain decides placement, etc.
    • closed loop at infra level is done by edge domain....but, closed loop at service level can be done by onap-central/edge components
  • 3rd party apps? onap managed or onap un-managed
    • maybe focus on what onap is responsible whether network app or mec app
    • (fyi - mec app = 3rd party apps like AR/VR/video cdn, etc. per ETSI definition)
  • today, onap focuses on 'connectivity' services. but, future, can be any service, eg., cdn or video or super-disco
    • edge domain can receive requests from multiple 'client systems'
    • so, not require that all requests to edge domain go through onap-central when not onap-managed
  • arash - cautioned about the depth of service model design, eg., video delivery service, which onap is not currently focused on
    • Hosting end user MEC Apps in ONAP should be clearly presented to EUAG for a decision. This is not ONAP's business today.
  • manoj: exposing network state/context API to MEC Apps
    • sequence diagram includes 'context API' that onap-central exposes
    • but, there are multiple aspects, eg., network workload <to> MEC App, network workload <to> onap-central, etc.

End User Group?

  • need to prepare slides to explain what Dublin release can include and get feedback
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

  • Context is when ONAP is doing LCM of apps on behalf of the APP Provider
  • ONAP sets up both network, eg., UPF in edge, and the association with MEC Apps per policies...but, not participating in the LCM of the MEC App
  • Possible Gaps in various ONAP Projects
    • Manoj to provide a presentation on ongoing external API work to see what is useful in this discussion
    • ONAP <> NEF Manager?
    • AF interaction in onap slicing controller
    • ONAP <> MEC Platform Manager?

Arash - need to ask TSC and End User Advisory Group (EUAG) about expanding ONAP scope

  • VNF is about 'network' function...and, not 'app function'
  • purpose of app-c was for L4-L7. so, can include 'apps' that are not necessarily limited to network related.
  • need more clarity on what is the set of 'apps' that an app-c is limited to

Oct 3

Discuss items for Dublin Release

Used Sequence diagram in Edge Architecture & Work Items

Edge Cloud Domain/Provider

  • typically, ONAP > EP-ID > Region-AZ
  • for eg. ONAP > EP-ID = AWS > Region-AZ/Availability Sets = USeast-1 vs USeast-2
  • Assume Edge Provider = 1 or more Control Plane (eg., Openstack, K8s) Instances. Note that we already have distinction between Edge Provider's Orchestration/Control vs Infrastructure Control Plane like openstack or k8s in the gliffy diagrams

Reviewed and Updated Sequence Diagram in Edge Architecture & Work Items

  • App Provider > onap-managed vs onap-unmanaged
  • Tweaked terms, eg., ONAP-edge Workloads
  • Steps for (1) getting infrastructure, (2) deploying workloads, and (3) getting context info were reviewed for gaps/missing steps.
    • Few items being addressed in casablanca....and, JIRA links included
  • Need to decide for Dublin release
    • IaaS/PaaS APIs and Context APIs?
    • Edge Cloud Provider Orchestrator in Dublin?
    • onap-managed cases only?
    • etc...

Continue discussion for the next few weeks to finalize input for Dublin Release (Target November?)

Oct. 10Dublin discussion
Oct. 17Dublin discussion
Oct. 24Dublin discussion
Future Calls

Potential Topics

  1. Casablanca Stretch Goal Discussion
  2. Dublin Release Discussion

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:

  • Fix onboarding aspects in option 3 - Mike Elliott
  • Existing App Instantiation/Configuration options captured in requirements

    • Option 1:
      • Instantiation with all config in place for Apps
      • Corresponding VNF instances are also known
    • Option 2:
      • Create the Apps initially
      • Configuration is done later based on VNF association
    • Option 3:
      • Instantiate/Configure the apps on demand along with VNFs
  • Add, if any, additional requirements for App Instantiation/Configuration - Chaker Al-Hakim

Wed. 03/06/2019

Feedback on option 3

  • No. 13
    • Do we need Policy?
    • Or simplify workflow using Configmap? –
    • Platform components are UP
  • Per edge cloud region K8S config information
    • A&AI? -
    • Deployment is central to edge … spinning
    • Edge monitoring from central (global visibility) – K8S custom metrics
  • No. 8 approach 2
    • K8S operators CRDs – example needed
  • No. 13
    • Do we need Policy?
    • Or simplify workflow using Configmap? –
    • Central Components
  • Sequence of options needed – SDC/SO before …

Agenda for Wednesday (03/13) meeting:

Cloudify presentation notes

  • inter site HA new capability
  • Advanced capability exposure in cloudify
    • similar to open source such as MongoDB
    • hardened version of HA available in premium addition and not community edition

Other discussion - EOM (option 2)

  • Typically Onboard mgmt. applications using EOM dashboard
  • Some applications such as DCAE, have dependency


Agenda for Wednesday (05/08) meeting:


Meeting Summary:


Agenda for Wednesday (05/16) meeting:

Recording: https://VMware.zoom.us/recording/share/vJFWlbfnqdW_yM6dFxtA2_vCYp7yoW6K_uCc8SokgCqwIumekTziMw?startTime=1557932931000

Meeting Summary:

  • Presentation by Mike "ONAP and ONAP Edge Orchestration
    Cloud Native Proposal for Management Workloads" - Meeting 1
  • Similarity with Cloud Native Managed Applications and opportunity for synergizing with "K8S Cloud Region Support" for managed workloads appreciated
  • Geo-redundancy best practices with Cloud Native - use geo distributed databases such as Cassandra (follow up in Architecture sub committee)
  •  Questions to be addressed in follow up meetings:
    • How will this proposal address backward compatibility?


Meeting Summary:

  • Convergence on using K8s ETCD (part of Central K8s cloud) for storing per Cloud Region access information
    • This will be managed through K8s CRDs as part of OOM project
    • This can be easily consumed by other ONAP microservices in the Central K8s cloud or other K8s clouds through a watch mechanism
    • This is a good step towards a central consolidated view of all resources which is a key requirement

Zoom Recording Link: 



Agenda for Wednesday (07/29) meeting:

  • Presentation on ONAP <-> Akraino collaboration - @Addepalli, Srinivasa R
    • ONAP orchestration for K8s managed workloads
    • Istio Security value additions for ONAP Central/Edge management workloads (can be potentially useful for managed workloads also)

Presentation Link:

Zoom Recording Link:



Agenda for Wednesday (08/14) meeting:

Slides & recording of the session

  • No labels


  1. 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.



    1. 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.

    2. 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. 

  2. 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.


    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.



  3. Added a presentation on the pre-work that was done as part of ONAP Edge-Computing adhoc group,.

    1. Great timing Srini, I was about to add your presentation.

  4. 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.



    1. 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.

    2. the meeting info is updated.

  5. 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.

  6. I did split the overview from scope and added high level material for overview.

    1. Makes sense. Thank Ulas.

  7. Srinivasa Addepalli - Raghu and I have moved the scope text suggested by you to the child page Edge Architecture & Work Items.

  8. 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.....

  9. >> 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. 

  10. 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?

  11. Let us go ahead with the call, since there are several topics to discuss and review.

  12. 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.

    1. ONAP Offload consists of following :  ONAP-Offload API and ONAP-Child

      ONAP-Child consists of

      • VNF Life Cycle management offload - Including NF configuration
      • Fabric Control Offload (L2/L3 Switch configuration)
      • WAN Configuration Offload (WMS)
      • Analytics Offload

      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


      1. 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. 


        1. 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.


  13. 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. 



  14. 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.

  15. Scaling using external controllers and how ONAP and Akraino can work together is being captured here:  Scaling using Offloads

  16. 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.

    1. If we are talking about a Hierarchical Control, it would mean one Central ONAP instance running as Master with many Edge ONAP/Other instances running as Slaves. This would mean the Central ONAP offloads work to the Edge instances but the Central ONAP is always in full control of everything that an Edge instance does and the Edge instance must always report all the results to the Central ONAP. The Edge instances could communicate horizontally with each other but they should always report all the results to the Central ONAP and take their commands only from the Central ONAP. This architecture would imply fast real-time data movement requirements between Edge instances and, to a lesser extent, with the Central ONAP.
    2. If we are talking about a Federated Control, it would mean the Edge instances and the Central instance(s) are all running as independent controllers. This would mean that there is no single Central command and control and each Edge or Central instance is running under a different administrative (service provider) control. This architecture would imply that data communications between the Edge instances and Central instances would be defined by binding SLAs. This means each instance would only be obliged to respond to other instances within the bounds of the defined mutual SLAs and outside of the binding SLAs each instance is free to operate completely independently. This setup would require a lesser degree of real-time data movement between the instances as most decisions would be made locally and the communications between the instances would be mostly at the application or service levels (as opposed to network levels).

    My assumption, based on the discussions and the diagrams so far, is that most people have the Hierarchical Control in mind.

    1. 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),

      • "..talking about a Federated Control" : one could say, 'hierarchy' in the sense that (a) onap-cental has e2e view, vs. (b) onap-edge has local edge domain view....albeit, somewhat independent instances. Need to decide how independent, e.g., onap-edge responsible for SLS of service component(s) of an e2e, etc..
      • "..running under a different administrative (service provider) control": we have two distinct cases here
        1. onap-edge used by Edge cloud provider (CP): separate admin control (ignore this case...b'coz we don't want to constrain Edge CP on what their orch/control platform is)
        2. onap-edge used by "SP" (SP=onap central, and responsible for e2e of onap-central domain): onap instance for SP's use....ie., not for edge CP's use

      About your point: "the communications between the instances would be mostly at the application or service levels",

      • yes, if "SP" relies on Edge CP
      • no, if "SP" uses an onap-edge instance to monitror/control state of its slice(s)

      1. 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.

        1. >> 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.

          • ONAP-central <> to any CP: IaaS/PaaS API (for slice component network attributes)
          • ONAP-central <> ONAP-edge: onap APIs (for slice component control/management attributes)

          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 (smile). 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'.

          1. 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"

            1. 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.

            2. >> "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?

          2. I want to point out that the Edge Compute white paper mentions the following:

            Edge computing introduces challenges (e.g., small footprint, large scale, etc.,) as well as new opportunities such as more flexibility for system designers to dis-aggregate computing functionality across platforms and across geographies. It enables developers to build systems that can flexibly distribute computational load across dispersed servers such that compute-intensive functions can occur at physically disjoint locations

            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?

            1. >> 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.

  17. 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).


  18. 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.  (smile) 

    1. 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

    2. 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.

    3. 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)


    4. 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.   

      1. @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.

      2. >> 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.

        1. 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

          1. 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.

            1. 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. 

              1. >> 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. 

  19. 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. 

  20. 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

  21. 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

    1. Agreed. There are already projects (e.g. https://www.akraino.org/) that specifically address the Edge and MEC.

      1. 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. 


    2. Note there are 2 different aspects:
      1) edge domain's orchestration stack
      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

  22. 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.

  23. 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:

    • Which ONAP central components would interact with components running on the Edge both for Instantiation (NF Creation/LCM) and Post Instantiation (NF Configuration/OAM/Analytics)? (SO, Multi-Cloud, DCAE, SDN-C/R, ...)
      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?

    • How ONAP central components would interact with components 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.
  24. 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. 

  25. 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.