Documentation of Infrastructure (INF) Project

INF Overview

This project is for reference implementations of O-Cloud infrastructure which is compliant with O-RAN Cloud Platform Reference Designs in O-RAN ALLIANCE Specifications.

In O-RAN architecture, the near-RT RIC, O-DU and O-CU could have different deployment scenarios. They could be container based or VM based, and the performance sensitive parts of the 5G stack require real time platform, especially for O-DU, the L1 and L2 are requiring the real time feature, all these will be supported by the O-Clouds in INF project.

StarlingX is an opensrouce cloud-native infrastructure project with fully integrated cloud software stack that provides a fully featured open source distributed cloud (See StarlingX Distributed Cloud for details). In different deployment scenarios in the O-RAN architecture, StarlingX O-Cloud can be deployed as a Regional Cloud Platform to support Near-RT RIC and/or O-CU, or as Edge Cloud Platform to support O-DU and/or O-CU.

INF O-Cloud O2 sub-project

The INF O-Cloud O2 sub-project is for reference implementations of the O-RAN O2 IMS and DMS service to expose the INF O-Cloud to SMO via the O-RAN O2 interface.

Please see the detail of O2 service in the INF O2 Service Overview.

And the INF O2 service is also integrated in StarlingX O-Cloud as a containerized application, please see the detail in the O-RAN O2 Application in StarlingX and the StarlingX O-RAN O2 Application Installation Guide.

INF O-Cloud Spec Compliance

The following lists all reference implementations in INF project that are compliant with the O-RAN specifications.

Supported O-Cloud Requirements

Operating System Requirements

  1. Support both the standard kernel and the real time kernel.

  2. Deterministic interrupt handling with a maximum latency of 20 μs for the real time kernel.

  3. CRI plugin containerd support.

  4. QEMU/KVM support for virtual machines.

Cloud Platform Runtime Requirements

  1. Accelerator Driver: driver for loading, configuring, managing and interfacing with accelerator hardware providing offload functions for O-DU container or VM.

  2. Network Driver: Network driver(s) for front-haul, back-haul, mid-haul, inter container or VM communication, management and storage networks.

  3. Board Management: Board management for interfacing with server hardware and sensors.

  4. PTP: Precision time protocol for distributing phase, time and synchronization over a packetbased network.

  5. Software-defined Storage (SDS): Software implementation of block storage running on COTS servers,

  6. Container Runtime: Executes and manages container images on a node.

  7. Hypervisor: Allows host to run multiple isolated VMs.

Generic Requirements for Cloud Platform Management

  1. Fault Management

    • Framework for infrastructure services via API

      • Set, clear and query customer alarms

      • Generate customer logs for significant events

    • Maintains an Active Alarm List

    • Provides REST API to query alarms and events

    • Support for alarm suppression

    • Operator alarms

      • On platform nodes and resources

      • On hosted virtual resources

    • Operator logs - Event List

      • Logging of sets/clears of alarms

      • Related to platform nodes and resources

      • Related to hosted virtual resources

    • StarlingX Kubernetes Fault Management Overview

    • StarlingX OpenStack Fault Management Overview

  1. Configuration Management

    • Managed Installation

      • Auto-discovery of new nodes

      • Manage installation parameters (i.e. console, root disks)

      • Bulk provisioning of nodes through XML file

    • Nodal Configuration

      • Node role, role profiles

      • Core, memory (including huge page) assignments

      • Network Interfaces and storage assignments

    • Inventory Discovery

      • CPU/cores, SMT, processors, memory, huge pages

      • Storage, ports

      • GPUs, storage, Crypto/compression H/W

  2. Software Management

    • Manages Installation and Commissioning

      • Auto-discover of new nodes

      • Full Infrastructure management

      • Manage installation parameters (i.e. console, root disks)

    • Nodal Configuration

      • Node role, role profiles

      • Core, memory (including huge page) assignments

      • Network Interfaces and storage assignments

    • Hardware Discovery

      • CPU/cores, SMT, processors, memory, huge pages

      • Storage, ports

      • GPUs, storage, Crypto/compression H/W

  3. Host Management

    • Full life-cycle and availability management of the physical hosts

    • Detects and automatically handles host failures and initiates recovery

    • Monitoring and fault reporting for:

      • Cluster connectivity

      • Critical process failures

      • Resource utilization thresholds, interface states

      • H/W fault / sensors, host watchdog

      • Activity progress reporting

    • Interfaces with board management (BMC)

      • For out of band reset

      • Power-on/off

      • H/W sensor monitoring

  4. Service Management

    • Manages high availability of critical infrastructure and cluster services

      • Supports many redundancy models: N, or N+M

      • Active or passive monitoring of services

      • Allows for specifying the impact of a service failure and escalation policy

      • Automatically recovers failed services

    • Uses multiple messaging paths to avoid split-brain communication failures

      • Up to 3 independent communication paths

      • LAG can also be configured for multi-link protection of each path

      • Messages are authenticated using HMAC

      • SHA-512 if configured / enabled on an interface by-interface basis

  5. HA Management

    • High-availability services for supporting cloud platform redundancy

  6. User Management

    • User authentication and authorization

    • Isolation of control and resources among different users

  7. Node Feature Management

    • Detection and setting of node-level policies to align resource allocation choices (i.e.NUMA, SR-IOV, CPU, etc.)

  8. HW Accelerator Management

    • Support for managing hardware accelerators, mapping them to O-RAN applications VMs and/or containers, and updating accelerator firmware

  9. Support the ansible bootstrap to implement the low touch provisioning

  • Enable the ansible configuration functions for infrastructure itself including the image installation and service configuration.

  1. Distributed Cloud

  • StarlingX Distributed Cloud configuration supports an edge computing solution by providing central management and orchestration for a geographically distributed network of StarlingX systems.

  • See StarlingX Distributed Cloud for details.

Multi OS and Deployment Configurations

  • The INF project supports Multi OS and currently the following OS are supported:

    • StarlingX

      • Debian 11 (bullseye)

      • CentOS 7

      • Yocto 2.7 (warrior)

    • OKD

      • CentOS Stream CoreOS 4.17

A variety of deployment configuration options are supported:

  1. All-in-one Simplex

A single physical server providing all three cloud functions (controller, worker and storage).

  1. All-in-one Duplex

Two HA-protected physical servers, both running all three cloud functions (controller, worker and storage), optionally with up to 50 worker nodes added to the cluster.

  1. All-in-one Duplex + up to 50 worker nodes

Two HA-protected physical servers, both running all three cloud functions (controller, worker and storage), plus with up to 50 worker nodes added to the cluster.

  1. Standard with Storage Cluster on Controller Nodes

A two node HA controller + storage node cluster, managing up to 200 worker nodes.

  1. Standard with Storage Cluster on dedicated Storage Nodes

A two node HA controller node cluster with a 2-9 node Ceph storage cluster, managing up to 200 worker nodes.

  1. Distributed Cloud

Distributed Cloud configuration supports an edge computing solution by providing central management and orchestration for a geographically distributed network of StarlingX systems.

NOTE:

  • For Debian and CentOS based image, all the above deployment configuration are supported.

  • For Yocto Based image, only deployment 1 - 3 are supported, and only container based solution is supported, VM based is not supprted yet.

Upstream Opensource Projects

About StarlingX

StarlingX is a complete cloud infrastructure software stack for the edge used by the most demanding applications in industrial IOT, telecom, video delivery and other ultra-low latency use cases. With deterministic low latency required by edge applications, and tools that make distributed edge manageable, StarlingX provides a container-based infrastructure for edge implementations in scalable solutions that is ready for production now.

About Yocto and OpenEmbedded

The Yocto Project is an open source collaboration project that provides templates, tools and methods to help you create custom Linux-based systems for embedded and IOT products, regardless of the hardware architecture.

OpenEmbedded is a build automation framework and cross-compile environment used to create Linux distributions for embedded devices. The OpenEmbedded framework is developed by the OpenEmbedded community, which was formally established in 2003. OpenEmbedded is the recommended build system of the Yocto Project, which is a Linux Foundation workgroup that assists commercial companies in the development of Linux-based systems for embedded products.

About OKD

OKD is a complete open source container application platform and the community Kubernetes distribution that powers OpenShift.

Contact info

If you need support or add new features/components, please feel free to contact the following: