Chapter 2
Stratum Architecture and Component Model
Beneath Stratum's clean, programmable interfaces lies an intricate architecture purpose-built for adaptability, robustness, and futureproofing. This chapter dissects the technology stack with the precision of a systems architect, exposing the interplay of modular layers and extensible components that make Stratum uniquely capable of unifying heterogeneous switching hardware. By delving into these architectural blueprints, readers will uncover the design patterns that empower both simplicity and advanced programmability at scale.
2.1 Platform Abstraction and Portability
Stratum achieves decoupling of switch software from hardware specifics through a carefully architected platform abstraction layer (PAL) that enables seamless compatibility across diverse network device platforms. This abstraction is critical for accommodating the heterogeneity of modern switching hardware, which encompasses application-specific integrated circuits (ASICs), network processing units (NPUs), and hybrid switching architectures. By isolating hardware-dependent functionalities, Stratum allows uniform control logic to function transparently, regardless of the underpinning platform.
At the core, the platform abstraction layer mediates between the high-level forwarding behavior specified by the control plane and the low-level programming interfaces of target hardware. This mediation abstracts away vendor-specific hardware details, register structures, and operational idiosyncrasies. The PAL defines a set of well-structured APIs representing common switch capabilities such as packet forwarding, table management, counter manipulation, and pipeline control. This API-centric design engenders a hardware-agnostic programming model, allowing Stratum's control components to interact with a standardized interface while the PAL handles the translation to proprietary hardware commands.
Device heterogeneity presents two primary challenges: differing pipeline architectures and variable feature sets. Pipeline architectures may vary from single-table pipelines to complex multi-stage processing, often with vendor- and model-specific computational units. Feature diversity includes varied support for match-action tables, varying types of counters, metadata fields, and quality-of-service (QoS) mechanisms. Stratum's abstraction techniques address these variations by encapsulating device-specific capabilities within modular device drivers that implement the PAL's APIs. These drivers perform capability detection and translate abstract operations into the hardware's native constructs.
To handle divergent pipeline topologies, Stratum leverages a flexible pipeline abstraction model that expresses device pipelines as graphs of processing stages. The PAL provides mechanisms to query pipeline layouts and capabilities, enabling the software to adapt forwarding logic accordingly. This approach allows the centralized control plane to generate forwarding rules and table entries that are valid for the specific pipeline structure of the underlying hardware. Device drivers implement hardware-specific parsing and programming strategies ensuring that control directives conform to the device's operational model.
Multi-vendor compatibility is realized not only by the API abstraction but also through adopting open standards for control and data plane interactions. For example, Stratum relies on the Protocol-Independent Switch Architecture (PISA) model and the P4 programming language to define forwarding behavior declaratively. The PAL supports P4-compatible pipelines by integrating vendor-provided or open-source P4 compilers and target-specific backends, enabling consistent deployment of forwarding logic across platforms. This openness reduces vendor lock-in and promotes innovation by allowing new hardware capable of P4 forwarding to be integrated with minimal software changes at the system level.
Another critical abstraction technique is the use of uniform data models and state synchronization semantics. Stratum employs consistent device state schemas that represent tables, counters, and forwarding state independent of underlying hardware formats. Device drivers translate these schemas into native formats while preserving state consistency and transactional updates. Moreover, the PAL implements synchronization primitives that ensure control and data planes remain coherent during asynchronous updates or failover events, which is indispensable in distributed network environments.
Hardware portability is further enhanced through automated hardware capability discovery and runtime adaptation. Upon initialization, the platform abstraction layer introspects device capabilities such as maximum table sizes, supported match types, and pipeline depth. This information configures the control plane's operational parameters and optimization strategies, preventing incompatibilities and improving performance. Dynamic adaptation enables Stratum to operate efficiently on new or upgraded hardware without requiring control plane modifications or recompilation.
In addition, Stratum uses a layered modular architecture for device drivers, separating common hardware interaction patterns from vendor-specific implementations. This modularity facilitates incremental development and testing of new hardware targets, as existing abstractions can be extended or overridden by specific drivers. It also encourages code reuse and reduces complexity by isolating proprietary logic to confined modules while exposing a uniform interface to the rest of the system.
The combination of standardized APIs, flexible pipeline representations, open programmable data plane models, uniform state management, and capability-aware runtime adaptation forms the foundation for Stratum's robust platform abstraction layer. This design paradigm enables a single control plane to effectively program and manage a heterogeneous network fabric without sacrificing performance or functionality, fulfilling the stringent requirements of modern disaggregated network architectures.
Illustrative Example: Consider a network operator deploying Stratum across two switch models: one based on a fixed-function ASIC pipeline with a vendor-specific programming interface and another using an NPU that supports a fully programmable P4 pipeline. The platform abstraction layer exposes a unified API that allows the control plane to write forwarding rules in terms of standard match-action tables. Under the hood, the ASIC driver translates these rules into device-specific register writes and table entries, while the NPU driver compiles and loads P4 code dynamically. Both devices export metrics and counters according to the same state model, allowing consistent monitoring and management, despite hardware differences.
class ForwardingTable { public: virtual Status AddEntry(const TableEntry &entry) = 0; virtual Status ModifyEntry(const TableEntry &entry) = 0; virtual Status DeleteEntry(const TableEntry &entry) = 0; ...
