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

Compare with Current View Page History

« Previous Version 30 Next »

Team:

Lead: 

ramki krishnan

Team:

ramki krishnan , Srinivasa Addepalli, Vimal Begwani, Mike Elliott, Vijay Venkatesh Kumar , Avi Chapnick , Borislav Glozman , Fernando Oliveira , Tal Liron , Margaret Chiosi , ravi rao , Raghu Ranganathan , Michael O'Brien , Xin Miao , Simone Mangiante <simone.mangiante@vodafone.com>, Timo Perala,  Davide Cherubini, John Ng

Others – please add yourself if you are interested

Meetings:

Every week as part of Edge Automation WG – Edge Automation through ONAP

Status: 

Draft.

Plan to be finalized in Arch. sub committee meeting on 01/15/2018.

References:

  1. ONAP Dublin Architecture Requirements: https://wiki.lfnetworking.org/display/LN/OPNFV-ONAP+January+2019+Session+Proposals?preview=/8257582/10551784/2019-01%20Dublin%20Architecture%20Requirements-pa1.pptx
  2. DCAE Platform Requirements: https://wiki.onap.org/download/attachments/28379482/DCAE%20Platform%20Requirements.pptx?api=v2

Activity Description:

Starting with Analytics, describe the options and recommendations for distributing management (ONAP etc.) functions.

Problem Statement:

  • Management Workloads
    • Currently, Multiple Orchestrators for Management Workloads (SDC, SO, OOF etc.)
      • ONAP Central Management   – OOM
      • Analytics Central/Distributed Management   – DCAE (ONAP, SP internal, Third Party)
    • There is an opportunity to get some alignment across multiple orchestrators which will be greatly beneficial especially in Distributed Edge environment
  • Managed Workloads
    • Fully Support for containerized network functions (work in progress)
    • Support for non-network functions (VM and Container based), e.g. vProbe, Automation Apps

Solution Direction:

  • Leverage existing capabilities, and select what; or motivate new approaches
  • Management Workload:
    • Align on a single orchestrator solution for all management workloads
  • Managed Workload:
    • Enhance SDC, SO, A&AI, MC etc. to support containerized functions
    • Leverage ONAP for deploying and managing non-network functions
  • Longer-term: 
    • Explore feasibility for orchestration alignment between managed workload and management workload
  • Cloud-Native-foundation: 
    • Leverage K8S (Operators, Custom Resource Definitions etc.) for Distributed Systems Management
      • Image management – at scale rolling upgrade

      • Policy/Configuration change – notify only deltas

    • Leverage Istio Service Mesh (Distributed Tracing etc.) for Component Performance Management


Distributed Management application Requirements / Considerations 

Requirement ItemPriorityAdded byModified by and modification
Ability to deploy ONAP management applications in selected cloud regions that are owned by ONAP operator
Srinivasa Addepalli

Ability to deploy ONAP management applications in selected cloud regions that are not owned by ONAP operator, but has business relationship

(Examples: Public Clouds or Edge Clouds owned by some other organization)


Srinivasa Addepalli
Ability to apply common configuration (Day0 configuration) of ONAP components at the time of deployment

Srinivasa Addepalli


Support for various Day0 configuration profiles

Srinivasa Addepalli


Support for Day 2 configuration of single or multiple instances of ONAP components in various cloud regions
Srinivasa Addepalli
Secure connectivity between central ONAP and ONAP management applications in cloud regions

Srinivasa Addepalli


Support for various connectivity protocols (Kafka, HTTP 1.1, 2.0, GRPC etc...) between ONAP-Central and ONAP components in cloud regions

Srinivasa Addepalli


Monitoring and visualization of ONAP components of cloud-regions along with ONAP components at the ONAP-Central

Srinivasa Addepalli


Scale-out of ONAP components at the cloud-regions & traffic (transaction) distribution

Srinivasa Addepalli


Ability to upgrade ONAP components without loss of functionality

Srinivasa Addepalli


High availability of ONAP component in the cloud regions

Srinivasa Addepalli


Support for third party management applications that provide similar functionality as ONAP management applications (Modularity)

Srinivasa Addepalli


Assumptions

ItemAdded byModified by
ONAP Management components can only be brought up in cloud-regions that are based on Kubernetes

Srinivasa Addepalli








Architectural Deployment Scenarios to consider:

Outcome of Edge Automation Discussions on 01/16/2019:

Deploy-ment Model

Non-ONAP Central

ONAP Central

Edge using certain ONAP functions as an Offload

Note: ONAP central could is interfacing with edge directly using Multi-Cloud APIs

Edge using ONAP Orchestration

Note: This covers the case where is a two (or more) level orchestration hierarchy when ONAP Central is interfacing with ONAP Edge Orchestrator using SO style APIs

Edge *not* using ONAP Orchestration/

Architecture Near-term Priority for VNF Orchestration/

Architecture Near-term Priority for App Orchestration

Note: This assumes at least a two level hierarchy for orchestration - ONAP Central Orchestrator and 3rd party Edge Orchestrator. This is specific to Service (VNF/App) Orchestration and *not* Cloud infrastructure orchestration. Interfacing to cloud infrastructure Orchestrators is already covered through ONAP multi-cloud.




DescriptionArchitecture Near-term Priority for VNFsArchitecture Near-term Priority for AppsDescriptionArchitecture Near-term Priority for VNF OrchestrationArchitecture Near-term Priority for App OrchestrationDescriptionArchitecture Near-term Priority for VNF OrchestrationArchitecture Near-term Priority for App Orchestration

Edge and Central Provider are same

NA

Yes for all cases

  • Allows ONAP Central to install their ONAP SW components (incl K8S cluster)
  • Support ONAP managed workloads on edge

Priority - High?

Rationale:

  • Analytics and closed loop offloads (purely ONAP-management-based or 3rd party integrated with ONAP management) are key edge use cases


Note: Analytics is currently addressed by a Distributed DCAE orchestrator based on Cloudify

Participant Operator Priority

  • AT&T - ?
  • Reliance Jio - ?
  • Verizon - ?
  • Vodafone - ?

Priority - Medium?

Rationale:

  • ONAP's primary focus is NFV Orch.
  • Allows ONAP Central to install ONAP Edge Orchestration SW (incl K8S cluster)
  • Support ONAP managed workloads on edge

Priority - Medium?

Rationale:

  • ONAP Edge Orchestration provides scalability which is a long-term use case


Participant Operator Priority

  • AT&T - ?
  • Reliance Jio - ?
  • Verizon - ?
  • Vodafone - ?

Priority - Medium?

Rationale:

  • ONAP's primary focus is NFV Orch.







Participant Operator Priority

  • AT&T - ?
  • Reliance Jio - ?
  • Verizon - ?
  • Vodafone - ?


  • Can install ONAP SW components via other mechanisms








Priority - Medium?

  • This is more of a standardization exercise given that different NFV orchestrators typically have different APIs




Participant Operator Priority

  • AT&T - ?
  • Reliance Jio - ?
  • Verizon - ?
  • Vodafone - ?

Priority - Medium?

  • ONAP's primary focus is NFV Orch.
  • This is more of a standardization exercise given that different NFV orchestrators typically have different APIs


Participant Operator Priority

  • AT&T - ?
  • Reliance Jio - ?
  • Verizon - ?
  • Vodafone - ?

Edge and Central Providers are different

NA

Yes for all cases

Use Existing VPCs (VPC creation out of scope for ONAP)

  • Allows ONAP Central to install their ONAP SW (incl K8S cluster)
  • Support ONAP managed workloads on edge
  • Can use Edge provider Services

Priority - High?

Rationale:

  • Same as above.


Participant Operator Priority

  • AT&T - ?
  • Reliance Jio - ?
  • Verizon - ?
  • Vodafone - ?

Priority - Medium?

Rationale:

  • Same as above.


Participant Operator Priority

  • AT&T - ?
  • Reliance Jio - ?
  • Verizon - ?
  • Vodafone - ?

Use Existing VPCs (VPC creation out of scope for ONAP)

  • Allows ONAP Central to install ONAP Edge Orchestration SW (incl K8S cluster)
  • Support ONAP managed workloads on edge
  • Can use Edge provider Services

Priority - Medium?

Rationale:

  • Same as above.


Participant Operator Priority

  • AT&T - ?
  • Reliance Jio - ?
  • Verizon - ?
  • Vodafone - ?

Priority - Medium?

Rationale:

  • Same as above.


Participant Operator Priority

  • AT&T - ?
  • Reliance Jio - ?
  • Verizon - ?
  • Vodafone - ?

Use Existing VPCs (VPC creation out of scope for ONAP)

  • Can install ONAP SW components via other mechanisms
  • Can use Edge provider Services




Priority - Medium?

Rationale:

  • Same as above.


Participant Operator Priority

  • AT&T - ?
  • Reliance Jio - ?
  • Verizon - ?
  • Vodafone - ?

Priority - Medium?

Rationale:

  • Same as above.


Participant Operator Priority

  • AT&T - ?
  • Reliance Jio - ?
  • Verizon - ?
  • Vodafone - ?

Definition of done:

  • This activity is closed when there is a:
    • Description of alternative concepts for distributing the ONAP functionality.
    • A recommendation for which alternatives to pursue (and when). 

Expected Timeframe:

 This activity is expected to conclude at/before the start of April, 2019 by the ONAP Architecture meeting at ONS.

Input Requirements: 

Definitions:


Architectural Options:


Conclusion: 


Other Deliverables:

LF blog and Architecture white paper during ONS time frame.


  • No labels