Architecture
This information describes how the OPX architecture provides an abstraction of hardware devices for network switching platforms in a Linux environment. Each component implements a set of well-defined APIs using full software modularity with hardware and software platform abstractions.
- Linux infrastructure
- Control plane services (CPS)
- Network adaptation service (NAS)
- Switch abstraction interface (SAI)
- Platform adaptation service (PAS)
- System device interface (SDI)
- Platform description infrastructure
- Applications and tools
- NAS run-time
Using well-defined APIs allow OPX to provide full software modularity and abstraction of the hardware and software platforms.
| Feature | Description |
|---|---|
| Software partitioning | Software is partitioned into subcomponents that are organized as Linux packages — each package contains only related functionality |
| Software layering | System components depend only on the components that logically support them |
| Hardware and software platform abstraction | The SDI, SAI modules, and platform startup scripts are the only hardware-specific components in OPX — all other modules are hardware-independent. Hardware-specific variations (such as number and names of physical ports, or number of power supplies) are defined using platform definition files. OPX uses portable operating system interface (POSIX) APIs. Software platform implementation-specific details are abstracted using OPX run-time libraries (common utilities and logging) as necessary. |
| Open API | User applications interact with OPX modules using the CPS API, and OPX provides an object-centric API in the control plane services (CPS) component |
The Linux infrastructure consists of a collection of services, libraries, and utilities pre-installed in an OPX generic image. Together with the Linux kernel, these components provide the foundation for the implementation of the OPX software components.
The CPS provides an object-centric framework that mediates interactions between applications, and enables user applications to interact with software components. The CPS defines two types of application roles — clients and servers.
| Role | Description |
|---|---|
| Client applications | Execute, create, set, get, and delete operations on individual objects or lists of objects |
| Server applications | Execute operations requested by client applications |
Because client applications operate on objects, they do not need to be aware of the location or name of the server application that executes a requested operation.
The CPS services support a publisher/subscriber model. Server application publish relevant events — client applications can subscribe (register) for specific events and objects.
Client applications can register for events generated when objects are created, modified, or deleted. The publisher/subscriber approach and object-centric operations allow for completely independent operation of client and server applications.
The CPS API object model provides disaggregation between client and server applications. The client and server are unaware of one other — they communicate only through a CPS API object.
Custom-written applications use the CPS API to communicate with OPX components. OPX provides both C/C++ and Python programming interfaces. The object model provided by the CPS layer is defined using YANG models which are used to generate C header files — providing a programmatic representation of objects and their attributes.
The header files are shared between client and server applications — the C/C++ representation of objects and their attributes is designed to ensure compatibility between multiple versions of the object model.
The NAS manages the high-level NPU abstraction and adaptation, and abstracts and aggregates the core functionality required for networking access at Layer 1 (physical), Layer 2 (VLAN, link aggregation), Layer 3 (routing), ACL, QoS, and network monitoring.
The NAS provides adaptation of the low-level switch abstraction provided by the SAI for standard Linux networking APIs and interfaces, and CPS API functionality. The NAS is also responsible for providing packet I/O services using the Linux kernel IP stack (see Network adaptation service for complete information).
The OPX switch abstraction interface (SAI) implements an API for network processor units (NPUs) supported on Dell EMC platforms. The SAI API is an open interface that abstracts vendor-specific NPU behavior.
The SAI API is the result of a joint effort of multiple NPU vendors and user companies, who contributed the SAI to the Open Compute Platform project. OPX is NPU-independent and not locked into specific NPU hardware. If a new NPU is used in an OPX platform, the only component that Dell EMC engineers replace is the SAI.
The PAS provides a higher-level abstraction and aggregation of the functionality provided by the SDI component, and implements the object models associated with system devices. The PAS monitors system devices and reports (publishes) status changes or faults as events. It also allows user applications to retrieve current status information and set control variables of system devices.
The PAS object API allows user applications to:
- Read current values reported by temperature sensors
- Get and set fan speed values
- Set a LED state
- Read power levels reported by PSUs
- Get system inventory and EEPROM information
- Set and get operations on transceivers
The PAS detects:
- Insertion and removal of common field replaceable units (FRUs) such as PSUs and fans
- Over-temperature events based on pre-defined thresholds
- Media insertion or removal on physical ports
The PAS is responsible for:
- Monitoring the status of system devices
- Allowing applications to retrieve current status information
- Reporting status changes or faults as CPS events
- Allowing applications to set the control variables of system devices
All hardware components except for NPUs are abstracted as system devices. The system device interface (SDI) API defines a low-level platform-independent abstraction for all types of system devices. Only system device drivers that implement the SDI API are hardware-specific—the API itself is hardware-independent.
Example system devices:
- Fans/cooling devices
- Power supplies
- Temperature sensors
- LEDs
- EEPROM
- Programmable devices
- Transceivers
The implementation of the SDI API can use any approach suitable for a given platform or vendor:
-
sysfsaccess to Linux kernel device drivers - User space device drivers using UIO or other methods
- New vendor-specific kernel methods accessible through
sysfs, netlink, orioctlcalls - Combination of any of these methods
Other approaches not mentioned are also possible, as long as the implementation supports SDI API.
This example shows a simple implementation of the standard SDI function sdi_temperature_get using sysfs (see System device interface for complete information).
The platform description infrastructure describes platform-specific configuration parameters — number of ports per system, supported transceiver modules, mapping of Linux interfaces to physical ports, and number of fans and power supply units. This component also contains the platform-specific system startup configuration and scripts.
OPX provides a set of tools and commands that allow system administrators to manage Dell EMC-specific software and hardware functionality such as software upgrades, physical port, media information, and system inventory (see Operation and commands for more information). OPX provides a Dell EMC-implemented thermal control application which prevents damage of hardware components in case of overheating and/or fan failure.
CAUTION: Do not disable the thermal control application, as hardware damage may result.
NAS run-time processes and components (see Run-time for complete information).