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 - In Progress:
- Edge Scoping
- Clarify Where/What is Edge...and, focus of this effort
- 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)
- Requirements for ONAP R2+
- Target Dates:
- April 30th for Use Case sub committee update about functional requirements for Casablanca and beyond
Presentation Link: ONAP-edge-automation-wg-usecase-update-04-30-2018.pptx - May 15th for Architecture sub committee update about any changes to the functional/reference architecture for Casablanca and beyond
- April 30th for Use Case sub committee update about functional requirements for Casablanca and beyond
- Target Dates:
Call Schedule:
Time: 8:00am PT - 10:00am PT
- Day: Every Monday
- Zoom: vmware.zoom.us/j/3055973130
List Subscription/Meeting Notification:
WG Coordinators:
Call 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 Scoping wiki? - item 2.C.I from last session - see gliffy diagram in Edge Scoping page 1 and 2: Vimal provided review of table in Edge Scoping 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 Scoping 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 Scoping
|
| May 7th, 2018 | Hierarchical DCAE - Lusheng Ji, Vijay Venkatesh Kumar High level review of Multi-Cloud use cases - Distributed Edge Cloud Infrastructure Enablement in ONAP |
|
| May 14th, 2018 | 1) Levgen 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. 3) Finalize minimum viable needed ONAP edge for Casablanca | 1) Levgen 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 |
| Future Calls | Potential Topics
|