<< Back

1. Overview

Dickering over Fine Points

1.1 Introduction

This Reference Architecture is focussed on OpenStack as the VIM chosen based on the criteria laid out in the Reference Model . OpenStack has the advantages of being a mature and widely accepted Open Source technology; a strong ecosystem of vendors that support it, the OpenStack Foundation for managing the community, and, most importantly, it is widely deployed by the global operator community for both internal infrastructure and external facing products and services. This means that the operators have existing staff with the right skill sets to support a Cloud Infrastructure (NFVI) deployment into development, test and production. Another reason to chose OpenStack is that it has a large active community of vendors and operators, which means that any code or component changes needed to support the Common Telco Cloud Infrastructure requirements can be managed through the existing project communities processes to add and validate the required features through well established mechanisms.

1.1.1. Vision

The OpenStack-based CNTT Reference Architecture will host NFV workloads, primarily VNFs, of interest to the CNTT community. The Reference Architecture document can be used by operators to deploy CNTT conformant infrastructure.

1.2 Use Cases

Several NFV use cases are documented in OpenStack. For more examples and details refer to the OpenStack docs found at the following link: https://docs.openstack.org/arch-design/use-cases.html. Examples include:

  • Overlay networks : The overlay functionality design includes OpenStack Networking in Open vSwitch GRE tunnel mode. In this case, the layer-3 external routers pair with VRRP, and switches pair with an implementation of MLAG to ensure that you do not lose connectivity with the upstream routing infrastructure.
  • Performance tuning : Network level tuning for this workload is minimal. Quality of Service (QoS) applies to these workloads for a middle ground Class Selector depending on existing policies. It is higher than a best effort queue but lower than an Expedited Forwarding or Assured Forwarding queue. Since this type of application generates larger packets with longer-lived connections, you can optimize bandwidth utilization for long duration TCP. Normal bandwidth planning applies here with regards to benchmarking a session’s usage multiplied by the expected number of concurrent sessions with overhead.
  • Network functions : Network functions is a broad category but encompasses workloads that support the rest of a system’s network. These workloads tend to consist of large amounts of small packets that are very short lived, such as DNS queries or SNMP traps. These messages need to arrive quickly and do not deal with packet loss as there can be a very large volume of them. There are a few extra considerations to take into account for this type of workload and this can change a configuration all the way to the hypervisor level. For an application that generates 10 TCP sessions per user with an average bandwidth of 512 kilobytes per second per flow and expected user count of ten thousand concurrent users, the expected bandwidth plan is approximately 4.88 gigabits per second. The supporting network for this type of configuration needs to have a low latency and evenly distributed availability. This workload benefits from having services local to the consumers of the service. Use a multi-site approach as well as deploying many copies of the application to handle load as close as possible to consumers. Since these applications function independently, they do not warrant running overlays to interconnect tenant networks. Overlays also have the drawback of performing poorly with rapid flow setup and may incur too much overhead with large quantities of small packets and therefore we do not recommend them. QoS is desirable for some workloads to ensure delivery. DNS has a major impact on the load times of other services and needs to be reliable and provide rapid responses. Configure rules in upstream devices to apply a higher Class Selector to DNS to ensure faster delivery or a better spot in queuing algorithms.

1.3 Terminology

General terminology definitions can be found in Glossary and specific terms relating to this reference architecture are to be found in OpenStack Related Terminology .

1.4 Principles

OpenStack Reference Architecture must obey to the following set of principles:

OpenStack specific principles

OpenStack considers the following Four Opens essential for success:

  • Open Source
  • Open design
  • Open Development
  • Open Community

This OpenStack Reference Architecture is organised around the three major Cloud Infrastructure resource types as core services of compute, storage and networking, and a set of shared services of identity management, image management, graphical user interface, orchestration engine, etc.

1.4.1 Exceptions

CNTT specifies certain policies and principles and strives to coalesce the industry towards conformant Cloud Infrastructure technologies and configurations. With the currently available technology options, incompatabilities, performance and operator constraints (including costs), these policies and principles may not always be achievable and, thus, require an exception process. CNTT specifies how to handle non-conforming technologies . In general, non-coformance with policies is handled through a set of exceptions (please also see Exception Types ).

The following sub-sections list the exceptions to the CNTT principles and shall be updated whenever technology choices, versions and requirements change. The Exceptions have an associated period of validity and this period shall include time for transitioning.

1.4.1.1 Technology Exceptions

The list of Technology Exceptions will be updated or removed when alternative technologies aligned with CNTT principles develop and mature.

Ref Name Description Valid Until Rationale Implication
ra1.exc.tec.001 SR-IOV This exception allows workloads to use SR-IOV over PCI-PassThrough technology. TBD Emulation of virtual devices for each virtual machine creates an I/O bottleneck resulting in poor performance and limits the number of virtual machines a physical server can support. SR-IOV implements virtual devices in hardware, and by avoiding the use of a switch, near maximal performance can be achieved. Compromises virtualisation and creates dependency on hardware defeating CNTT and Cloud Principles.
RM e.cap.016 HW Accelerators This exception allows workloads to use FPGA-s and other accelerators that require the inclusion of HW specific drivers in the workload. TBD Use of FPGA-s and other HW accelerators are needed to meet the technical requirements or economic goals of 5G, Edge and transcoding services. Compromises virtualisation and creates dependency on hardware defeating CNTT and Cloud Principles.

1.4.1.2 Version Exceptions

The list of Version Exceptions will be updated as and when alternative versions become available.

Ref Name Description Valid Until Rationale Implication
ra1.exc.ver.001 xxx xxxxxxxxxxxxx.

1.4.1.3 Requirements Exceptions

The Requirements Exceptions lists the Reference Model (RM) requirements and/or Reference Architecture (RA) requirements that will be either waived or be only partially implemented in this version of the RA. The exception list will be updated to allow for a period of transitioning as and when requirements change.

Ref Name Description Valid Until Rationale Implication
ra1.exc.req.001 Requirement xxx xxxxxxxxxxxxx.

1.5 CNTT OpenStack Reference Release

This Reference Architecture document in its Elbrus release version conforms to the OpenStack Train release. While many features and capabilities are conformant with many OpenStack releases, this document will refer to features, capabilities and APIs that are part of the OpenStack Train release. For ease, this CNTT Reference Architecture document version can be referred to as “RA-1 OSTK Train.”

1.6 Document Organisation

Chapter 2 defines the Reference Architecture requirements and, when appropriate, provides references to where these requirements are addressed in this document. The intent of this document is to address all of the mandatory (“must”) requirements and the most useful of the other optional (“should”) requirements. Chapter 3 and 4 cover the Cloud Infrastructure resources and the core OpenStack services, while the APIs are covered in Chapter 5. Chapter 6 covers the implementation and enforcement of security capabilities and controls. Life Cycle Management of the Cloud Infrastructure and VIM are covered in Chapter 7 with stress on Logging, Monitoring and Analytics (LMA), configuration management and some other operational items, Please note that Chapter 7 is not a replacement for the implementation, configuration and operational documentation that accompanies the different OpenStack distributions. Chapter 8 identifies certain Gaps that currently exist and plans on how to address them. For example, Service Function Chaining support needs to be addressed to realise the full potential and value of SDN and NFV.