Zero Touch Use Case proposal
Source: Tom Tofigh ( AT&T), Bora Eliacik (Argela-usa)
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
– 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
- 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.