Edge Sub-committee creation proposal

Owned by Ramki Krishnan
Last updated: Oct 07, 2018
3 min read

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


  • Challenges with independent task forces/coordinators: 

    • Independent task forces under each one of the sub-committees (use case, architecture, security, modelling etc.) and independent external open source/standards coordinator can lead to more fragmentation of the work happening in Edge

Key Deliverables for upcoming ONAP releases:

  • Contributions towards Architecture (closely interface with architecture subcommittee)

  •  

    • Multi-tenant Edge Cloud Domain 

      • Which can support several Edge locations with different

        • Workload profiles that enable Telco VNFs, Third party workloads, MEC, IoT and other application workloads etc.  

        • Infrastructure profiles that enable Distributed, Highly-secure, Config/Cloud-diverse, Capacity-constrained and Performance/Isolation-aware network functions and application workloads.

      • Which can leverage Cloud Native Transformation in a heterogeneous cloud environment 

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

    • ONAP <-> Multi-tenant Edge Cloud Domain 

      • Hierarchical ONAP Central/Edge Architecture including closed-loop service assurance 

  • Contributions towards Security (closely interface with security subcommittee)

    • Distributed Edge Clouds introduce unique security challenges as described in detail in the infrastructure profiles

  • Contributions towards Modelling (closely interface with modelling subcommittee)

    • Distributed Edge Clouds needs new cloud infrastructure modelling – there is substantial work that happened in this area in Beijing/Casablanca time frame

  • Contributions towards Functional Requirements per Release (closely interface with use case subcommittee)

    • ONAP <-> Multi-tenant Edge Cloud Domain IaaS/PaaS Intent-based APIs and Context (e.g. summarized telemetry information) APIs

  • 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: