Zero Touch Use Case proposal

Source:  Tom Tofigh ( AT&T),  Bora Eliacik  (Argela-usa)

Objective;

Demonstrate ONAP interworking with CORD platforms for ZERO touch operational Scenarios.  Consider operational requirements to manage CORD Edge Services.

• The aim is to integrate ONAP and CORD in such a way that

–      It is possible to remotely deploy VNFs and Apps

–      It is possible to remotely monitor stats

–      It is possible to remotely perform manual intervention

–      It is possible to set policies for self-healing

–      It is possible to have end to end orchestration and automation

Assumptions;

•   ONAP

–      Provides portals for service-onboarding

–      Provides portals DCAE / Policy

–      Provides DCAE/Policy APIs for CORD

• CORD Edge provides local autonomous proxy function

–      Service Composition

–      Monitoring services

–      Virtual Probes

This POC is expected to provide

• Simulate Real-World M-CORD Traffic Using Traffic Generators such as Spirent’s Landslide.
• Simulate Real-World R-CORD Traffic Using Traffic Generators from IXIA - IxLoad & Spirent STC with Triple Play test apps for Data, VoIP & IPTV
• ONAL master orchestrator will interwork with 2 separate CORD edge platforms
• Services are managed globally from ONAP service creation portals & provided to local proxies for autonomous operation.
• ONAP DCAE will have access to  global analytics & enforces data collection at local CORD edge level.  The DCAE register with CORD Edge local monitoring services for data collection and pub/sub operation

      Test Environment

• Operator has installed the infrastructure at the edge data center.
  • This could be any enterprise building.
  • Admin has installed M-CORD from ONAP remotely on to the edge data center.

• Local proxy CORDs utilize their local LDAP, and A-CORD Interfaces to collect real time analytics and events.    
• ONAP operators  can perform scaling and stress Testing from master orchestrator .
• Inject Error Conditions into a CORD Pod – (Ex: inject malformed control and data  packets from Spirent’s traffic generator)   
  
  

Key Operational Requirements

• Zero touch deployment
• Simplified configuration & orchestration
• Real time monitoring & troubleshooting
• End to end Fault , Performance Visibility across the Networks comprising of VNFs, PNFs
  • Hardware  monitoring and capacity based failure prevention
  •  Software modules monitoring from OS, Hypervisors, Containers, Applications
  • API monitoring
  • Software scripts monitoring
• New Services Launch operations
  • Portal, Provisioning, BSS, Omni-channel
• SDN controller operations (ONOS)
• VNFs, VIM, VNFM, MANO modules operations
  • OpenStack, XOS

Key Automation Requirements

• Capacity Management
• Event and Alarm management
• Configuration Management
• Inventory Management –VNF, PNF
• Security Management
• Availability Management
• Performance Management
• Identity and Access Management
• Scale in/Scale Out management
• Reliability management
• Closed Loop Network Correction based on DCAE BigData Analytics

Use Case 1;  Service Degradation, manual treatment

• Admin turns-up a set of virtual probes and subscribes to MME KPIs through ONAP DCAE.
• Admin sets thresholds on MME “Attach Request Failure Rate” KPI.
• Admin manually instantiates an additional eNodeB tester to simulate traffic towards the MME
• MME starts to reject some of the requests because of congestion
• Probe sends the KPIs to Monitoring service .Admin is notified about a service degradation through ONAP Alarm Portal
• Admin discovers that an additional MME instance is required to handle the workload
• Admin manually instantiates an additional MME instance as part of auto-scaling
  
  

Use Case 2: Service Degradation, self-healing

• Admin adds a policy for the use case 1.
• The same overload condition occurs
• Admin gets notified by the Alarm first
• Admin gets notified that policy is taking corrective action
• ONAP & CORD Policies heals the problem by instantiating an MME automatically
• Admin observes that Alarm goes off.