Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Name:  "Edge"

Co-chairs: 

  • Ramki Krishnan (VMware), Raghu Ranganathan (Ciena)

TSC Sponsor:

  • Srini Addepalli (Intel)

Purpose: 

  • Summary:
    • Identify architectural gaps in ONAP in satisfying edge requirements and drive those requirements in various ONAP projects.
    • Deep engagement with edge related external open source initiatives to drive the above.

  • Accomplishments:
    • The Edge Automation through ONAP (https://wiki.onap.org/display/DW/Edge+Automation+through+ONAP) effort started as a working group in May 2018 as part of the use case subcommittee and is targeting concrete deliverables impacting multiple ONAP projects and driving the ONAP edge requirements & architecture for Casablanca and beyond. The working group has been run with its own meetings and maintaining set of wiki pages. As part of Casablanca, multiple initiatives have been taken such as supporting Kubernetes based edges, Aggregation of metrics and Cloud-agnostics way of utilizing cloud/edge site features. There is strong interest from the community in this working group and we would like transition to a subcommittee. Please find the rational below.

  • Rationale for transition to subcommittee:
    • Strong and consistent interest from the community in terms of attendance and contributions
    • Distributed Edge Cloud is a key area of focus for operators and vendors towards 5G transformation, local breakout, ultra-low-latency MEC applications and bandwidth-intensive IoT applications 
    • Collaboration with other key edge related open source initiatives O-RAN Alliance, Linux Foundation (Akraino, EdgeX Foundry, IoTvity etc.), Kubernetes (Edge Working Group, Network Service Mesh, Multus, OVN etc.)
    • The work needs substantial discussions and engagement with external open source initiatives to make concrete ONAP architecture recommendations realize the implementation – this is very different from other functional & non-functional requirement group which are ONAP specific
    • Making it a formal subcommittee with targeted focus provides substantial visibility and can enable better ONAP internal and ONAP external participation

Key Deliverables for upcoming ONAP releases:

  • Contributions towards Architecture (closely interface with architecture subcommittee)
    • Architecture for Multi-tenant Edge Cloud Domain which can support several Edge locations with different workload profiles – Telco VNFs, Third party workloads, MEC, IoT and other application workloads etc.  As part of this effort, we will be studying the relevancy of ONAP projects, gaps and solutions.
    • ONAP <-> Multi-tenant Edge Cloud Domain IaaS/PaaS Intent-based APIs for infrastructure profiles that enable Distributed, Highly-secure, Config/Cloud-diverse, Capacity-constrained and Performance/Isolation-aware network functions and application workloads.
    • Hierarchical ONAP Central/Edge Architecture to support aforementioned IaaS/PaaS Intent-based APIs.
    • Architecture for Service Assurance addressing a large number of edge clouds.
    • Cloud Native Transformation of Edge
      • This work will be immediately beneficial to ONAP supporting deployment of containerized VNFs, since the edge cloud requirements are a super-set of general data center requirements.
  • Contributions towards Functional Requirements per Release (closely interface with use case subcommittee)
  • Contributions towards Functional Requirement realization (closely interface with all ONAP projects)
  • Working closely with other key edge related open source initiatives
    • Joint Architectural (APIs etc.) discussions
    • Joint demo planning for conferences
    • ONAP Network Service <-> External Edge Open Source initiatives value add APIs
      • Examples - Proximal placement of MEC App and 5G CU-UP VNF for delivering ultra-low-latency services

Participants List:


  • No labels