...
Utilize vendors VNFs in the ONAP platform.
TIC Location | VNFsCode / Vendor | Intended VNF Provider |
Edge | vSBC | Huawei |
vPCSCF | Huawei | |
vSPGW | ZTE/Huawei | |
vePDG | ? | |
Core | vPCRF | Huawei |
VI/SCSCF | Huawei | |
vTAS | Huawei | |
VHSS | Huawei | |
vMME | ZTE/Huawei |
Note: The above captures the currently committed VNF providers, we are open to adding more VNF providers.
Note: The committed VNF providers will be responsible for providing support for licensing and technical assistance for VNF interowrking issues, while the core ONAP usecase testing team will be focused on platform validation.
NFVI+VIM:
Utilize vendors NFVI+VIMs in the ONAP platform.
TIC Location | NFVI+VIMs | Code / VendorIntended VIM Provider |
Edge | Titanium Cloud (OpenStack based) | Wind River |
VMware Integrated OpenStack | VMware | |
Core | Titanium Cloud (OpenStack based) | Wind River |
VMware Integrated OpenStack | VMware |
Note: The above captures the currently committed VIM providers, we are open to adding more VIM providers.
Note: The committed VIM providers will be responsible for providing support for licensing and technical assistance for VIM integration issues, while the core ONAP usecase testing team will be focused on platform validation.
Network equipment? (TBA)
Network equipment vendors.
...
Network equipment | intended provider |
---|---|
DC gateway | |
WAN/SPTN PE router |
Note: The above captures the currently committed HW providers, we are open to adding more HW providers.
Note: The committed HW providers will be responsible for providing support for licensing and technical assistance for HW integration issues, while the core ONAP usecase testing team will be focused on platform validation.
Topology Diagram:
Work Flows:
Customer ordering
...
Controll Automation:
Open Loop
- Auto ticket creation based on the policy (stretch goal)
Closed Loop
- Auto-scaling (stretch goal)
When a large-scale event, like concert, contest, is coming, the service traffic may increase continuously, the monitoring data of service may grow higher, or other similar things make the virtual resources located in TIC edge become resource-constrained. ONAP should automatically trigger VNF actions to horizontal scale out to add more virtual resource on data plane to cope with the traffic. On the contrary, when the event is done, which means the traffic goes down, ONAP should trigger VNF actions to scale in to reduce resource.
...
After the fault detected and its root correlated, ONAP should do the auto-healing action as specified by a given policy to make the system back to normal.
Open Loop
- Auto ticket creation based on the policy
Closed Loop
- Horizontal scaling to support add or remove machines into the pool of resources
- Vertical scaling to support add or remove resources (ex. CPU, Memory, Storage) from existing virtual machines ?Stretch goal?
- comment: Vertical Scaling seems to be explicitly discouraged by the VNF Guidelines. Is Vertical Scaling a valid use case requirement?
Configuration flows (Stretch goal)
- Create (or onboard vendor provided) application configuration Gold standard (files) in Chef/Ansible server
- Create Chef cookbook or Ansible playbook (or onboard vendor provided artifacts) to audit and optionally update configuration on the VNF VM(s)
- Install the Chef client on the VM (Ansible doesn’t requires)
- After every upgrade or once application misconfiguration is detected, trigger auditing with update option to update configuration based on the Gold Standards
- Post-audit update, re-run audit, run healthcheck to verify application is running as expected
- Provide configuration change alert to Operation via control loop dashboard
...
- SDC
Add logic to use the new modeling when designing the service, and then distribute the resulting artifacts - SO
Add logic to understand the new artifacts; orchestrate/manage changes according to it - SDNCSDN-C/SDN Agent
Add logic to support to provision the underlay and overlay connection service between clouds, including 3rd party commercial SDN controllers. - DCAE
Support statistics collection on the VoLTE case and receipt of events as per the new model - VNF
Support to integrate with S-VNFM/S-EMS to fulfill the NS lifecycle management and configuration.
- VFC VF-C and DCAE
Support more complex control Support the above control loops - SO/SDNCSDN-C/SDN Agent/VFCVF-C
Monitor the service to verify the all NSs/VNFs have been executed, and update A&AI. - A&AI
Support the new data model - Policy
Support new policy related to the scaling and healing in VoLTE use case - Multi-VIM
Support multiple VIMs
...
Functional Platform RequirementVoLTE | Priority | basic/stretch goal default basic goal | |
---|---|---|---|
VNF onboarding1 | 2 | ||
Service Design | 1 | 1 | |
Service Composition | 1 | 1 | |
Network Provisioning | 1 | 1 | |
Deployment automation1 | 1 | ||
Termination automation | 1 | 1 | |
Policy driven/optimal VNF placement | 1 | 3 | stretch |
Performance monitoring and analysis1 | 2 | ||
Resource dedication1 | ? | ||
Controll Loops 1 | 2 | ||
Capacity based scaling1 | 3 | stretch | |
Triggered Healthcheck1 | 2 | ||
Health monitoring and analysis1 | 2 | ||
Data collection1 | 2 | ||
Data analysis | 1 | 2 | |
Policy driven scaling | 1 | 3 | stretch |
Policy based healing1 | 2 | ||
Configuration audit1 | 3 | stretch | |
Multi Cloud Support | 1 | 2 | |
Framework for integration with OSS/BSS1 | 3 | stretch | |
Framework for integration with vendor provided VNFM(if needed) 1 | 1 | ||
Framework for integration with external controller1 | 1 | ||
Non-functional Platform RequirementVoLTE | |||
Provide Tools for Vendor Self-Service VNF Certification (VNF SDK)1 | NA | NA | |
ONAP platform Fault Recovery1 | NA | NA | |
Security1 | NA | NA | |
Reliability | 1 | NA | NA |
Dister Recovery | 1 | NA | NA |
ONAP Change Management/Upgrade Control/Automation | 1 | NA | NA |
Work Commitment:
< identify who is committing to work on this use case and on which part>
Work Item | ONAP Member Committed to work on VoLTE | ||
---|---|---|---|
Modeling | CMCC, Huawei, ZTE, BOCO | ||
SDC | CMCC, ZTE | ||
SO | CMCC, Huawei, ZTESDNC | ||
SDN-C/SDN-Agent | CMCC, Huawei | ||
DCAE/Homles/CLAMP | CMCC, ZTE, BOCO, Huawei, Jio | ||
VFCVF-C | CMCC, HUAWEI, ZTE, BOCO, Nokia, Jio | ||
A&AI | HUAWEI, ZTE, BOCO | ||
Policy | ZTE | SDN-Agent | Huawei |
Multi-VIM | VMWare, Wind River | ||
Portal | CMCC |