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

Compare with Current View Page History

« Previous Version 36 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 

Definitions

Day0 configuration:  Configuration that is applied at the time of VNF instantiations (Example: Ether config-drive, config-init or config-map)

Day 2 configuration: on-going configuration after Day-0 configurations

(in VNFs, Day 1 configuration is treated as Day 2 configuration in the following table)

Management application:  Can be ONAP component or equivalent component from third parties

Requirement ItemPriorityAdded byModified by and modificationMapping to requirements from DCAE team
Ability to onboard management applications, that are to be deployed in cloud-regions, in ONAP-Central. Shall not have any expectations that all management applications are onboarded as a single bundle.high

Srinivasa Addepalli


Allow new MS/applications/components to be onboarded independently

Ability to compose multiple management applications to be part of one management bundle and defining the dependency graph of applications belonging to a bundlehigh

Srinivasa Addepalli


Allow Service assurance flow composition and deployment of individual or group of component
Ability to deploy management applications in selected cloud regions that are owned by ONAP operatorhighSrinivasa Addepalli
Allow Service assurance flow composition and deployment of individual or group of component
Ability to deploy management applications that are ephemeral (example: Analytics applications)high

Srinivasa Addepalli


Allow Service assurance flow composition and deployment of individual or group of component

Ability to deploy 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)

lowSrinivasa Addepalli

Support for deploying management applications independent of each other when there are no dependencies (no expectation that all management applications are brought up together).high

Srinivasa Addepalli


Allow Service assurance flow composition and deployment of individual or group of component
Ability to deploy few management applications based on VNF instantiations and bring down when VNF is terminatedhigh

Srinivasa Addepalli


Dynamic deployment of MS based on xNF instantiation
Ability to apply configuration (Day0 configuration) of management applications at the time of deploymenthigh

Srinivasa Addepalli



Support for various Day0 configuration profileshigh

Srinivasa Addepalli



Support for Day 2 configuration of single or multiple instances of management applications in various cloud regionshighSrinivasa Addepalli

Support for management applications depending on other management applications - Support for configuration (Day2 configuration) of provider services when the consuming service is being instantiated and removal of the configuration on provider services when consuming service is terminated (Example: When analytics applications are brought up, analytics/collection framework need to be updated with additional configuration such as DB table, Kafka topic etc..)highSrinivasa Addepalli

Dynamic topics provisioning and role assignment for MS

Support for Day 2 configuration (add/delete) of appropriate management applications upon VNF instantiation/termination (Example: configuration of analytics & collection services when VNFs are brought up and removing the added configuration upon VNF termination)highSrinivasa Addepalli

Dynamic reconfiguration of MS based on xNF instantiations

Secure connectivity between central ONAP and management applications in cloud regionshigh

Srinivasa Addepalli



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

Srinivasa Addepalli



Monitoring and visualization of management applications of cloud-regions along with ONAP components at the ONAP-Centralhigh

Srinivasa Addepalli


Complete view of MS and relation maintained at single/multisite K8S scenarios

Healthcheck of all deployment component to be available for CLAMP/external system

Scale-out of management application components at the cloud-regions & traffic (transaction) distributionhigh

Srinivasa Addepalli



Ability to upgrade management application components without loss of functionalitylow

Srinivasa Addepalli



High availability of management applications in the cloud regionshigh

Srinivasa Addepalli



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

Srinivasa Addepalli



Support management applications as containershigh@Srinivasa Addepalli

Support management applications as VMslow

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 management workload functions as an Offload

Clarification Notes:

In this case, their is no hierarchical orchestration.

Edge using ONAP Orchestration

Clarification Notes:

In this case, their is a two (or more) level orchestration hierarchy when ONAP Central is interfacing with ONAP Edge Orchestrator.

Edge *not* using ONAP Orchestration

Clarification Notes:

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 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 Controller function to install ONAP SW components (purely ONAP mgmt. based or 3rd party integrated with ONAP mgmt.). Note that this also supports ONAP specific K8S cluster installation.
  • Support ONAP managed workloads on edge

Priority - High?

Rationale:

  • Analytics and closed loop offloads 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.










Participant Operator Priority

  • AT&T - ?
  • Reliance Jio - ?
  • Verizon - ?
  • Vodafone - ?
  • Allows ONAP Central Controller 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 - ?


  • ONAP edge orchestrator should be  registered in ONAP central with the service specific capabilities it can offer. This step should happen before service instantiation.









Priority - Medium?

Rationale:

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

Rationale:

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

  • ONAP edge orchestrator should be  registered in ONAP central with the service specific capabilities it can offer. This step should happen before service instantiation.
  • 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