Skip Navigation LinksHome > Products > N-BASE > Scalability

Scalability

Metaswitch's network software products are all architected and implemented such that they can scale across a wide range of scalability requirements. For example, Metaswitch network software products are utilized by devices ranging from small footprint, hand held devices, all the way to core switch/router applications that handle billions of transactions per year.

A key part of that scalability is that the core network software product code, and the N-BASE itself, contain no hard coded limits. For example, there are no compile-time constants, and data structures and search strategies are designed in such a way that they can be scaled efficiently and arbitrarily. As a result, as our customers' platforms and architectures evolve, and as they require greater scale, no adjustments are required to the core code.

Some of that scalability is the result of careful design choices within the individual network software products, each of which is designed, implemented and maintained within very specific performance and scalability targets.

But a great deal of that scalability is the result of either the network software products using N-BASE features, or the result of inherent N-BASE design features.

The following illustrates some of the design and implementation strategies adopted within the network software products and within the N-BASE to achieve unconstrained scalability.

Flexibility and scheduling

The N-BASE architecture is flexible enough to exploit the extra processing power in multi-threaded, multicore and multi-processor systems. For example, components may be distributed within a task, within a processor, across multicore processors, across multiple processors, or across multiple cards, to achieve the optimal architecture for a particular target platform.

The N-BASE scheduling model requires that no component can block pending a single action, which enables vastly parallel processing across the components within a single network software product, and across the components from potentially multiple network software product within a given task or processor instance.

Message buffers

Network software product components do not communicate directly – but rather communicate via N-BASE "messages", which are dedicated buffers, managed by the N-BASE, and separate from other memory management requirements.

Passing messages between product components that reside within the same address space, whether the components are from the same product or multiple products, reduces to a simple function call that simply moves a pointer to the buffer concerned.

The N-BASE also provides a set of utilities for management of, and access to, messages in dedicated buffers (see above). In particular, network software product components are not aware of the underlying buffer structure, which can be contiguous or dis-contiguous, and can be mapped directly onto underlying hardware memory structures.

This approach means that, in many cases, a message buffer can be processed across a series of components without memory copies – through each component accessing and manipulating the message contents via the appropriate N-BASE utilities, and by the message being passed between components via pointer moves. This is a major scalability benefit, as in other network software architectures memory copies between layers and/or components can be a major component of all execution time – especially on the "golden path".

Memory

Network software product components do not manage operating system memory directly – but acquire, manage and release memory via the N-BASE Memory Manager.

The N-BASE Memory Manager default implementation aids scalability and performance by reducing calls to the operating system memory manager and reducing memory fragmentation.

The N-BASE Memory Manager may be further tuned for scalability, in terms of the overall amount of memory managed, the mix of memory block sizes, and whether the Memory Manager acquires further operating system memory post-initialization. Metaswitch provide a range of diagnostics to aid in such tuning.

Timers

Network software products tend to set a large number of relatively short timers – with timers typically set per link, per session etc., and often running for less than 100 milliseconds. General purpose and embedded operating systems timer implementations often perform poorly in such situations.

The N-BASE default timer implementation can manage a very large number of fine-grained timers, using timer heaps and lists, and can do so with a very small number of operating system timer resources.

Control blocks

Network software products use a relatively large number of control blocks (which are essentially linked pieces of memory acquired through the N-BASE Memory Manager) to track information about links, sessions, etc.

For large scale implementations, a particular component may be managing many thousands of control blocks, where each control block is identified by a specific identifier. For example, a link control block may need to be located by a Link ID that is supplied on an incoming link message. As such, design decisions about management and search strategies for such data structures can have a major impact on performance and scalability.

The network software product components do not manage or search control block structures directly – but rather

  • use the N-BASE Memory Manager (see above) to acquire and release control blocks
  • use N-BASE utilities to manage and search control block data structures.

The N-BASE utilities are stable, robust and highly optimized utilities that are tuned to particular data structures and search strategies – and allow for highly scalable implementations. For example there are optimized N-BASE utilities for managing and searching

  • hash tables
  • AVL, AVLL and AVL3 trees - asynchronous binary trees of different types with different occupancy trade-offs
  • Patricia trees (also known as radix tries/trees, Patricia tries, or crit bit tries/trees)
  • dictionaries
  • doubly linked lists
  • arrays
  • pointers/handles
  • tables.

Diagnostics

The network software products use a very rich set of N-BASE diagnostics tools, where there are a variety of different diagnostics available and the level of detail can be configured for each.

These diagnostics can be stored in memory rather than on disk, which minimizes the overhead in recording diagnostics when debugging issues (e.g. window conditions) that only occur in high scale scenarios.


More Information

For more information about the N-BASE and Metaswitch's network software products and expertise contact .