Page tree
Skip to end of metadata
Go to start of metadata

Purpose

This Wiki page is intended to capture and define the Auto Use Cases. 

Use Case Diagrams

Hybrid Cloud for R1 ONAP Deployment and Hybrid VNF Use Cases

The diagram below illustrates two local cloud stacks (OpenStack, and cloud-native) which when used in combination represent one type of "hybrid cloud" environment. Hybrid clouds may be necessary to deploy VNFs that are partially cloud-native, i.e. include some VNFCs that are deployed in VMs under cloud control planes such as OpenStack. Work on a k8s-based cloud-native stack as illustrated below (the k8s nodes) is underway in the Models project, as part of a broader work on cloud-native stack options (see the tools folder in the Models repo). That k8s-based stack will be used as the local cloud control plane into which three key ONAP subsystems will be integrated: monitoring (VES), closed-loop control (DCAE, Policy), and orchestration (Multi-VIM, initially represented by Cloudify in standalone mode). See the VES Project Plan for info on how this relates to the Fraser release goals for VES. The other stack shown below is based on OpenStack Helm but could be any OpenStack-based OPNFV distribution. An OpenStack Helm based stack is expected to be ready to test with Auto early in 2018 (WIP in OpenStack), and the hybrid cloud use cases thus sometime after that. In the meantime, we can make progress with the cloud-native stack and establish the basic ONAP subsystem integration and test approaches described above.

Link to the source of the diagram below: hybrid_pod.vsdx

F Release Detailed Use Case Definitions

This section defines each use case in greater details.

Edge Cloud

SectionDescription
IDAuto-UC-01
Title

Service Provider's Management of Edge Cloud

DescriptionAs an NFV edge service provider, I need an edge platform that is both efficient (in terms of control/automation overhead) and largely autonomous for VNFs once launched. Thus ability to deploy the minimal subset of ONAP functions needed for autonomy under typical VNF lifecycle events, e.g. start, stop, scale, recover from faults, collect/process telemetry, ...
Primary Actor (s)
  1. Service Provider
  2. Cloud control plane and automation platform
Preconditions
  1. hardware environment in which Edge cloud may be deployed
  2. a Edge cloud has been deployed and is ready for operation
  3. ONAP has been deployed onto a cloud and is interfaced (ie provisioned for API access) to the Edge cloud
Main Success Scenario (s)
  • lifecycle management - stop, stop, scale (dependent upon telemetry)
  • recovering from faults (detect, determine appropriate response, act); ie exercise closed-loop policy engine in ONAP
    • verify mechanics of control plane interaction
  • collection of telemetry for machine learning
Alternate ScenariosTest with Cloudify
Exception Scenariosnone
Post Conditionsundefinded
JIRA Traceability

AUTO-1 - Getting issue details... STATUS

 

ONAP use case: Edge Automation Through ONAP


Resiliency Improvements through ONAP

SectionDescription
IDAuto-UC-02
Title

Resilience Improvements through ONAP

Description

As an NFV edge service provider, I need to assess what degree of added VIM+NFVI platform resilience I obtain by leveraging ONAP closed-loop control, vs VIM+NFVI self-managed resilience, so I can determine the ROI for integrating ONAP with my VIM+NFVI platforms, both locally on the VIM+NFVI platform, or remotely.

Primary Actor (s)
  1. Service Provider
  2. Cloud control plane
  3. Automation platform
Preconditions
  1. hardware environment in which Edge cloud may be deployed
  2. Edge cloud has been deployed and is ready for operation
  3. ONAP has been deployed onto a cloud and is interfaced (ie provisioned for API access) to the Edge cloud
  4. Components of ONAP have been deployed on the Edge cloud as necessary for specific test objectives
Main Success Scenario (s)
  • assess VIM+NFVI resilience under specific stresses without ONAP support
  • assess VIM+NFVI resilience under specific stresses with ONAP support, i.e. VES+DCAE+CLAMP+specific policies to address the type of stress
  • stress the system via

    • traffic: different types as needed per the resiliency measurements

    • instability

      • physical infra failure (host, NIC, disk, ...)

      • virtual infra failure (cloud control plane components, SDNC components, NFVI components)

      • security threats

  • measure resiliency in terms of

    • link failure, e.g. loss ping failures

    • transaction failure, e.g. failed web/API requests

    • service degradation/failure duration or recovery time

    • scope of disruption

Alternate ScenariosNone identified.
Exception ScenariosONAP CLAMP control loop encounters failure to complete policy action for recovery and reaches a condition such as MaxRetriesExceeded, TimeLimitExceeded, or other failures (Refer https://wiki.onap.org/display/DW/Control+Loop+Design).
Post Conditions

Service recovers from faults, failures, errors, attacks, or is migrated to other available host(s).

Faults, if injected by the use case, are removed from the system.

JIRA Traceability AUTO-2 - Getting issue details... STATUS

Background

ONAP CLAMP (Control Loop Automation Management Platform) is used to design, deploy and execute the control loop automation. It takes specific policy based action to address the stress or instability experienced by the service. Refer to CLAMP Project for more details. 

 

Additional analysis for Auto Use Case 2: Resiliency Improvements Through ONAP

  • not sure a "without ONAP" test would make sense: what would really be measured ? A manual detect/repair time ? The Cloud VIM could recover cloud resources, but not VNFs.
  • suggestion: only do a "with ONAP" test, and measure the Recovery Time from the point of view of the test script (from simulated problem, to detected restoration)
  • then if the measured ONAP-enabled Restoration Time is within expectations (few seconds ? few minutes ?), the conclusion is that ONAP does improve resilience for the scenario
    • if this Restoration Time is too high for a typical SLA (too many minutes, or hours, or more), then the conclusion is that ONAP was not setup properly, or that it is not currently supporting a fast restoration of the use case scenario
  • readiness preparation common to all test case scenarios:
    • onboard/deploy VNFs
      • compatible with underlying physical architecture
      • ideally with ONAP SDC/VID/MSO/AAI suite; otherwise with some separate installer, but then ONAP monitoring+actions still have to be configured with awareness of these "external" VNFs
    • configure ONAP monitoring and actions (VES, DCAE, Policies, CLAMP), which enable the HA


These 2 diagrams illustrate the approach: 



Diagram view of test cases for Resiliency Improvement use case (10 identified so far):



Enterprise vCPE

zhang chenEric Maye

SectionDescription
IDAuto-UC-03
Title

vCPE as a cloud service for enterprise users

DescriptionAs an NFV edge service provider, I need to provide the site2site, site2dc and site2internet service to the tenants both efficiently and safely by deploying enterprise-based vCPE. Enterprise users could receive high-quality and cheap cloud service. And in here, MSO, SDN-C, APP-C and VNFM are used to manage and control the required VNF in the access network as a cloud service.
Primary Actor (s)
  1. Enterprise Service Provider
  2. Cloud control plane and automation platform
Preconditions
  1. hardware environment in which Edge cloud may be deployed
  2. a Edge cloud has been deployed and is ready for operation
  3. the enterprise edge devices, such as ThinCPE, could get access to the Edge cloud with WAN interfaces
  4. MSO, SDN-C, APP-C and VNFM have been deployed onto a cloud and is interfaced (ie provisioned for API access) to the Edge cloud
Main Success Scenario (s)
  • vnf spin up
    • vcpe spinning-up, MSO calls the VNFM to spin up a vcpe instance and then updates the active vnf list
    • vfw spinning-up, MSO calls the VNFM to spin up a vfw instance and then updates the active vnf list
  • site2site
    • l3vpn service subscribing, MSO calls the SDNC to create vxlan tunnels to carry l2 traffic between client's thincpes and SP' vcpe, and enable vcpe to route between different sites.
    • l3vpn service unsubscribing, MSO calls the SDNC to destroy tunnels and routes, thus diable the the traffic between different sites.
Alternate Scenariossite2Internet
  • internet service subscribing, TBD
  • internet service unsubscribing, TBD
Exception ScenariosWhen the vpn service number exceeds the limit on a vcpe, the MSO will automatically spins up a new vcpe instance for new vpn services.
Post ConditionsAccess to edge devices and having connection to Vcpe.
JIRA Traceability AUTO-7 - Getting issue details... STATUS
  • No labels