• Proposed name for the project: Resource Scheduler
• Proposed name for the repository: Conductor
• Project Categories: (Requirements)

The overall goal of this project is to enhance the resource scheduler for the performance optimization, with the information of network and resource isolation.

• Network information monitoring and collection

For the telecommunication applications, besides the number of CPU and memory, the resource scheduler needs much more information of network for resource allocation. Currently, the function of the OpenStack to monitor and collect information from network is not enough for much applications. The information is listed below:

• The bandwidth and time delay of each physical link between the physical hosts
• The physical network topology
• The state of the VLinks already scheduled in the physical network
• …

• Resource Isolation

To provide low call latency, compute capability of VMs must be guaranteed for VNF. Every VM should not interfere with other VMs. However, OpenStack couldn’t isolate compute resources completely at present. Firstly, the NFVI management system may preempt CPU resources from VMs of VNF. Secondly, when two or more VMs may share one core, service processes will affect each other. In above cases, call latency on VMs will be extended and can’t meet carrier-grade requirements.

• Resource allocation optimization

One application usually consists of several VMs and VLinks. The VMs and VLinks may have different resource requirements and constraints. The allocation of the VMs and VLinks should not only obey these requirements and constraints, but also meet the policy of the optimize performance for the system as possible, like minimize the number of the hosts, or load-balance with minimal difference among the hosts, and so on. However, the VM deployment is implemented by Nova-Scheduler of OpenStack via filters and weighting method currently, and can’t guarantee high performance. Even more, the Ceilometer in OpenStack could not get the information of network, so the Nova-Scheduler can’t support the network resource requirements and constraints. If the VMs which need to be allocated simultaneously can be considered together, the performance of the result would be better. So the scheduler needs to be enhanced for multi VM allocation optimizing of this problem. The figure below shows the Resource Scheduling for VNF with some specific policies and deployment constrains. The VNFM or NFVO request the VNF deployment by Or-Vi or Vi-Vnfm interface. The request contains the compute/storage/network resource each VM needed in the VNF, the deployment policies such as Load Balance, constrains such as VM-VM affinity/anti-affinity, QOS requirement of the VLink, etc. The network information can be getting from the Neutron, Ceilometer, libvert, and even SDN Controller. Then the Scheduler gets the current Host and PLink status, and schedules VM and Host to deploy VNF successfully.

• Describe the problem being solved by project
  • 1) Network information monitoring and collection
    • Monitoring the physical and virtual network, and collecting the corresponding information, including the bandwidth and time delay of the physical network, the physical topology of the network, the VLinks among the VMs which are already scheduled, etc.
  • 2) Resource Isolation
    • When the VNF strictly requires low latency, the VNF can apply for strongly isolated compute resources. For example, one VM can monopolize some CPU cores and be isolated from other VM.
    • A guest OS environment with low scheduling latency and high-precision timer can be provided for the media-plane VNF to provide fluency voice services.
    • Basing on network bandwidth filter, The OpenStack can place VM to guarantee sufficient network bandwidth.
  • 3) Enhanced scheduler for optimize the performance of the VMs and Vlinks allocation.
    • Include the network resource, following all the resource requirements and constraints, get high performance for the allocation policies in DC.
    • Multi-VM scheduling at the same time for optimization.
    • Other optimization aspect corresponding with nova scheduler.

• Specify any interface/API specification proposed
  • Nf-vi, Or-Vi, Vi-Vnfm

• Specify testing and integration:
  • Debugging and Tracing: N/A
  • Unit/Integration Test plans: N/A
  • Client tools developed for status shows etc: N/A

• Identity a list of features and functionality will be developed
  • 1) Network information monitoring and collection.
  • 2) The mechanism of resource isolation.
  • 3) Enhanced scheduler for multi VMs to be scheduling together for high utilization of the resource.

• Identify what is in or out of scope. So during the development phase, it helps reduce discussion.
  • In scope:
    • Network information collection
    • Resource isolation
      • The mechanism of resource isolation
    • Enhanced scheduler
      • Enhanced scheduler including the information of network
      • Multi-VM scheduling at the same time
      • Other optimization aspect corresponding with nova scheduler
  • Out of scope
    • Policy Engine
    • Resource Reservation

• Describe how the project is extensible in future
  • OpenStack Qos will extend features through its Nova API.
  • Resource orchestration implementation

Specify testing and integration like interoperability, scalability, high availablity

• N/A

What QA and test resources will be available?

• N/A

• Documentation on all functions will be provided.

• Identify similar projects is underway or being proposed in OPNFV or upstream project
  • Copper:
    • The Copper focuses on the policy engine, mostly on how to describe the policy with the policy language, but this project doesn't focus on how to implement any single policy. Our project wants to achieve some mechanism and policies, not focus on policy engine.
  • Promise:
    • The Promise focuses on the resourse reservation. However, the network information collection and resource isolation in the resource scheduler project are not the content of the Promise. And the enhanced scheduler considers about the mechanisms above, as well as the performance optimization, which is not consider about the resource reservation.

• Identify any open source upstream projects and release timeline.
  • OpenStack Nova
  • OpenStack Heat
  • OpenStack Neutron
  • OpenStack Ceilometer
  • OpenDayLight
  • KVM
• Are there any external fora or standard development organization dependencies. If possible, list and informative and normative reference specifications.
  • N/A
• If project is an integration and test, identify hardware dependency.
  • This project shall not have any hardware dependency

• Names and affiliations of the committers:
  • Haibo Zhang (HUAWEI: zhanghaibo@huawei.com)
  • Ruopeng Wang (HUAWEI: Ruopeng.Wang@huawei.com)
  • Zhiqi Wang (HUAWEI: zhiqi.wang@huawei.com)
  • Ximing Li (HUAWEI: liximing@huawei.com)
  • Qiao Fu (China Mobile: fuqiao@chinamobile.com)
  • Hao Pang(HUAWEI: shamrock.pang@huawei.com)
  • Yimin Wang (HUAWEI: yimin.wang@huawei.com)
  • Qi Liang (HUAWEI: liangqi1@huawei.com)
  • Mingjiang Li (HUAWEI: limingjiang@huawei.com)

• Contributors:
  • Zhipeng Huang (HUAWEI: huangzhipeng@huawei.com)
  • Kin-Yip Liu (Cavium: Kin-Yip.Liu@caviumnetworks.com)
  • Ryota Mibu (NEC: r-mibu@cq.jp.nec.com)

• Describe the project release package as OPNFV or open source upstream projects.
  • User requirements of OPNFV Resource Scheduler.
  • Gap analysis on Resource Scheduler with open source upstream projects.
  • Propose BPs in Nova project (https://wiki.openstack.org/wiki/Nova ) .
• If project deliverables have multiple dependencies across other project categories, described linkage of the deliverables.
  • TBD

• When is the first release planned?
  • Gap analysis is planned to be finished in April, 2015.
  • OPNFV resource scheduler software framework architecture (including API specification) is planned to be finished by August, 2015.
• Will this align with the current release cadence
  • Yes.