must: Requirements that are marked as must are considered mandatory and must exist in the reference architecture and reflected in any implementation targeting this reference architecture. The same applies to must not.
should: Requirements that are marked as should are expected to be fulfilled by the reference architecture but it is up to each service provider to accept an implementation targeting this reference architecture that is not reflecting on any of those requirements. The same applies to should not.
RFC2119
may: Requirements that are marked as may are considered optional. The same applies to may not.
Traceability to Reference Model.
"Architecture" in this chapter refers to NFVI + VIM (as specified in Reference Model Chapter 3).
| Ref # | sub-category | Description | Traceability |
|---|---|---|---|
req.gen.ost.01 |
Open source | The Architecture must use OpenStack APIs. | RA-1 5.3 |
req.gen.ost.02 |
Open source | The Architecture must support dynamic request and configuration of virtual resources (compute, network, storage) through OpenStack APIs. | RA-1 5.3 |
req.gen.cnt.01 |
Cloud nativeness | The Architecture should consist of stateless service components. However, where state is required it must be kept external to the component. | OpenStack consists of both stateless and stateful services where the stateful services utilize a database. For latter see "Configuring the stateful services" |
req.gen.cnt.02 |
Cloud nativeness | The Architecture should consist of service components implemented as microservices that are individually dynamically scalable. | |
req.gen.scl.01 |
Scalability | The Architecture should support policy driven auto-scaling. | This requirement is currently not addressed but will likley be supported through Senlin, cluster management service. |
req.gen.rsl.01 |
Resiliency | The Architecture must support resilient OpenStack components that are required for the continued availability of running workloads. | |
req.gen.rsl.02 |
Resiliency | The Architecture should support resilient OpenStack service components that are not subject to req.gen.rsl.01. |
|
req.gen.avl.01 |
Availability | The Architecture must provide High Availability for OpenStack components. | RA-1 4.2 "Underlying Resources" |
Table 2-1: General Requirements
| Ref # | sub-category | Description | Traceability |
|---|---|---|---|
req.inf.com.01 |
Compute | The Architecture must provide compute resources for VM instances. | RA-1 3.3.1.4 "Cloud Workload Services" |
req.inf.com.02 |
Compute | The Architecture should include industry standard hardware management systems at both HW device level (embedded) and HW platform level (external to device). | |
req.inf.com.03 |
Compute | The Architecture should support symmetrical CPU multi-processing with shared memory access as well as multi-threading. | |
req.inf.com.04 |
Compute | The Architecture must be able to support multiple CPU SKU options to support various infrastructure profiles (Base, Network Intensive, and Compute Intensive). | RA-1 4.4.1. "Support for Profiles and T-shirt instance types" |
req.inf.com.05 |
Compute | The Architecture must support Hardware Platforms with NUMA capabilities. | RA-1 4.4.1. "Support for Profiles and T-shirt instance types" |
req.inf.com.06 |
Compute | The Architecture must support CPU Pinning of the vCPUs of VM instance. | RA-1 4.4.1. "Support for Profiles and T-shirt instance types" |
req.inf.com.07 |
Compute | The Architecture must support different hardware configurations to support various infrastructure profiles (Base, Network Intensive, and Compute Intensive). | RA-1 3.3.3. "Host aggregates providing resource pooling" |
req.inf.com.08 |
Compute | The Architecture must support allocating certain number of host cores/threads to non-tenant workloads such as for OpenStack services. | Dedicating host core/sibling threads to certain workloads (e.g., OpenStack services. Please see example, "Configuring libvirt compute nodes for CPU pinning" |
req.inf.com.09 |
Compute | The Architecture must ensure that the host cores/threads assigned to a workload are thread-sibling aware: that is, that a core and its associated SMT threads are either all assigned to non-tenant workloads or all assigned to tenant workloads. | Achieved through configuring the "cpu_dedicated_set" and "cpu_shared_set" parameters in nova.conf correctly. |
req.inf.stg.01 |
Storage | The Architecture must provide remote (not directly attached to the host) Block storage for VM Instances. | RA-1 3.4.2.3. "Storage" |
req.inf.stg.02 |
Storage | The Architecture should provide Object storage for VM Instances. | OpenStack Swift Service (RA-1 4.3.1.4 "Swift") |
req.inf.stg.03 |
Storage | The Architecture may provide a file system service (file system storage solution) for VM Instances. | RA-1 4.2.4. "Storage Backend" |
req.inf.stg.04 |
Storage | The Architecture may support Software Defined Storage (SDS) that seamlessly supports shared block storage, object storage and flat files. | RA-1 4.2.4.1. "Ceph Storage Cluster" |
req.inf.stg.05 |
Storage | The Architecture should be able to accommodate VNFs that store back into its image through use of hypervisor attached volumes. | Wouldn't that be a Security Violation |
req.inf.stg.06 |
Storage | The Architecture should make the immutable images available via location independent means. | RA-1 4.3.1.2. "Glance" |
req.inf.stg.07 |
Storage | The Architecture should provide high-performance and horizontally scalable VM storage. | RA-1 4.2.4.1. "Ceph Storage Cluster" |
req.inf.stg.08 |
Storage | The Architecture should allow use of externally provided large archival storage for its Backup / Restore / Archival needs. | |
req.inf.stg.09 |
Storage | The Architecture should make available all non-host OS / Hypervisor / Host systems storage as network-based Block, File or Object Storage for tenant/management consumption. | |
req.inf.stg.10 |
Storage | The Architecture should provide local Block storage for VM Instances. | RA-1 "Virtual Storage" |
req.inf.stg.11 |
Storage | The Architecture should support the Block storage capabilities specified in https://docs.openstack.org/api-ref/block-storage/. | RA-1 5.2.3. "Cinder" |
req.inf.ntw.01 |
Network | The Architecture must provide virtual network interfaces to VM instances. | RA-1 5.2.5. "Neutron" |
req.inf.ntw.02 |
Network | The Architecture must include capabilities for integrating SDN controllers to support provisioning of network services, from the OpenStack Neutron service, such as networking of VTEPs to the Border Edge based VRFs. | RA-1 3.2.5. "Virtual Networking – 3rd party SDN solution" |
req.inf.ntw.03 |
Network | The Architecture must support low latency and high throughput traffic needs. | RA-1 4.2.3. "Network Fabric" |
req.inf.ntw.04 |
Network | The Architecture should support service function chaining. | Is this VNFM/NFVO requirement |
req.inf.ntw.05 |
Network | The Architecture must allow for East/West tenant traffic within the cloud (via tunnelled encapsulation overlay such as VXLAN or Geneve). | RA-1 4.2.3. "Network Fabric" |
req.inf.ntw.06 |
Network | The Architecture should support Distributed Virtual Routing (DVR) to allow compute nodes to route traffic efficiently. | |
req.inf.ntw.07 |
Network | The Architecture must support network resiliency. | RA-1 3.4.2.2. "Network" |
req.inf.ntw.08 |
Network | The NFVI Network Fabric should embrace the concepts of open networking and disaggregation using commodity networking hardware and disaggregated Network Operating Systems. | |
req.inf.ntw.09 |
Network | The NFVI Network Fabric should embrace open-based standards and technologies. | |
req.inf.ntw.10 |
Network | The NFVI Network Fabric must be capable of enabling highly available (Five 9’s or better) NFVI. | RA-1 3.4.2.2. "Network" |
req.inf.ntw.11 |
Network | The NFVI Network Fabric should be architected to provide a standardised, scalable, and repeatable deployment model across all applicable NFVI sites. | |
req.inf.ntw.12 |
Network | The SDN solution should be configurable via orchestration or VIM systems in an automated manner using openly published API definitions. | |
req.inf.ntw.13 |
Network | The SDN solution should be able to support federated networks. | |
req.inf.ntw.14 |
Network | The SDN solution should be able to be centrally administrated and configured. | |
req.inf.ntw.15 |
Network | The Architecture must support multiple networking options for NFVI to support various infrastructure profiles (Base, Network Intensive, and Compute Intensive). | RA-1 4.2.3.4. "Neutron ML2-plugin Integration" and "OpenStack Neutron Plugins" |
req.inf.ntw.16 |
Network | The Architecture must support dual stack IPv4 and IPv6 for tenant networks and workloads. | |
req.inf.ntw.17 |
Network | The Architecture should use dual stack IPv4 and IPv6 for NFVI internal networks. | |
req.inf.ntw.17 |
Network | The Architecture should support the network extensions specified in https://docs.openstack.org/api-ref/network/v2/. | RA-1 5.2.5. "Neutron" |
req.inf.acc.01 |
Acceleration | The Architecture should support Application Specific Acceleration (exposed to VNFs). | RA-1 3.2.6. "Acceleration" and RA-1 4.3.1.10. "Cyborg" |
req.inf.acc.02 |
Acceleration | The Architecture should support NFVI Acceleration (such as SmartNICs). | "OpenStack Future - Specs defined" |
req.inf.acc.03 |
Acceleration | The Architecture should not rely on SR-IOV PCI-Pass through to provide acceleration to VNFs. |
Table 2-2: Infrastructure Requirements
| Ref # | sub-category | Description | Traceability |
|---|---|---|---|
req.vim.01 |
General | The Architecture must allow infrastructure resource sharing. | RA-1 3.2. "Consumable Infrastructure Resources and Services" |
req.vim.02 |
General | The Architecture should support deployment of OpenStack components in containers. | RA-1 4.3.2. "Containerised OpenStack Services" |
req.vim.03 |
General | The Architecture must allow VIM to discover and manage NFVI resources. | RA-1 5.2.7. "Placement" |
req.vim.04 |
General | The Architecture must support Enhanced Platform Awareness (EPA) only for discovery of infrastructure resource capabilities. | |
req.vim.05 |
General | The Architecture must include image repository management. | RA-1 4.3.1.2. "Glance" |
req.vim.06 |
General | The Architecture must allow orchestration solutions to be integrated with VIM. | Orchestration of what |
req.vim.07 |
General | The Architecture must support multi-tenancy. | RA-1 3.2.1. "Multi-Tenancy" |
req.vim.08 |
General | The Architecture must support resource tagging. | "OpenStack Resource Tags" |
req.vim.09 |
General | The Architecture should support horizontal scaling of OpenStack core services. |
Table 2-3: VIM Requirements
| Ref # | sub-category | Description | Traceability |
|---|---|---|---|
req.int.api.01 |
API | The Architecture must provide Control API endpoints to cloud platform core services. | RA-1 5.3. "Consolidated Set of APIs" |
req.int.api.02 |
API | The Architecture must provide GUI access to tenant facing cloud platform core services. | RA-1 4.3.1.9 "Horizon" |
req.int.api.03 |
API | The Architecture must provide APIs needed to discover and manage NFVI resources. | RA-1 5.2.7. "Placement" |
req.int.acc.01 |
Acceleration | The Architecture should provide an open and standard acceleration interface to VNFs. | RA-1 5.3.4. "Cyborg" |
req.int.acc.02 |
Acceleration | The Architecture should not rely on SR-IOV PCI-Pass through for acceleration interface exposed to VNFs. |
Table 2-4: Interfaces and APIs Requirements
| Ref # | sub-category | Description | Traceability |
|---|---|---|---|
req.tnt.gen.01 |
General | The Architecture must support multi-tenancy. | duplicate of req.vim.07 |
req.tnt.gen.02 |
General | The Architecture must support self-service dashboard (GUI) and APIs for users to deploy, configure and manage their workloads. | RA-1 4.3.1.9 "Horizon" and 3.3.1.4 Cloud Workload Services |
Table 2-5: Tenant Requirements
| Ref # | sub-category | Description | Traceability |
|---|---|---|---|
req.lcm.gen.01 |
General | The Architecture must support zero downtime expansion/change of physical capacity (compute hosts, storage increase/replacement). | |
req.lcm.adp.01 |
Automated deployment | The Architecture should allow for “cookie cutter” automated deployment, configuration, provisioning and management of multiple NFVI sites. | |
req.lcm.adp.02 |
Automated deployment | The Architecture must support hitless upgrades of software provided by the cloud provider so that the availability of running workloads is not impacted. | |
req.lcm.adp.03 |
Automated deployment | The Architecture should support hitless upgrade of all software provided by the cloud provider that are not covered by req.lcm.adp.02. Whenever hitless upgrades are not feasible, attempt should be made to minimize the duration and nature of impact. |
|
req.lcm.adp.04 |
Automated deployment | The Architecture should support declarative specifications of hardware and software assets for automated deployment, configuration, maintenance and management. | |
req.lcm.adp.05 |
Automated deployment | The Architecture should support automated process for Deployment and life-cycle management of VIM Instances. | |
req.lcm.cid.02 |
CI/CD | The Architecture should support integrating with CI/CD Toolchain for NFVI and VIM components Automation. |
Table 2-6: LCM Requirements
| Ref # | sub-category | Description | Traceability |
|---|---|---|---|
req.asr.mon.01 |
Integration | The Architecture must include integration with various infrastructure components to support collection of telemetry for assurance monitoring and network intelligence. | |
req.asr.mon.02 |
Monitoring | The Architecture should support Network Intelligence capabilities that allow richer diagnostic capabilities which take as input broader set of data across the network and from VNF workloads. | |
req.asr.mon.03 |
Monitoring | The Architecture must allow for the collection and dissemination of performance and fault information. | |
req.asr.mon.04 |
Network | The NFVI Network Fabric and Network Operating System must provide network operational visibility through alarming and streaming telemetry services for operational management, engineering planning, troubleshooting, and network performance optimisation. |
Table 2-7: Assurance Requirements
| Ref # | sub-category | Description | Traceability |
|---|---|---|---|
req.sec.gen.01 |
General | The Architecture must provide tenant isolation. | |
req.sec.gen.02 |
General | The Architecture must support policy based RBAC. | |
req.sec.gen.03 |
General | The Architecture must support a centralised authentication and authorisation mechanism. | |
req.sec.zon.01 |
Zoning | The Architecture must support identity management (specific roles and permissions assigned to a domain or tenant). | |
req.sec.zon.02 |
Zoning | The Architecture must support password encryption. | |
req.sec.zon.03 |
Zoning | The Architecture must support data, at-rest and in-flight, encryption. | |
req.sec.zon.04 |
Zoning | The Architecture must support integration with Corporate Identity Management systems. | |
req.sec.cmp.02 |
Compliance | The Architecture must comply with all applicable standards and regulations. | |
req.sec.cmp.03 |
Compliance | The Architecture must comply with all applicable regional standards and regulations. |
req.sec.ntw.03 |
Networking | The Architecture must have the underlay network incorporate encrypted and/or private communications channels to ensure its security. | |
|---|---|---|---|
req.sec.ntw.04 |
Networking | The Architecture must configure all of the underlay network components to ensure the complete separation from the overlay customer deployments. | |
req.sec.ntw.05 |
Networking | The Architecture must have the underlay network include strong access controls that adhere to the V1.1 NIST Cybersecurity Framework. |
Table 2-8: OpenStack Security Requirements.