Architecture

This information describes how the OpenSwitch 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.

Components

• 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
• Application and tools
• NAS run-time

Linux infrastructure

The Linux infrastructure consists of a collection of services, libraries, and utilities pre-installed in an OpenSwitch generic image. Together with the Linux kernel, these components provide the foundation for the implementation of the OpenSwitch OPX software components.

Control plane services

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.

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.

Network adaptation service

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 enables 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).

Switch abstraction interface

The SAI API is based on the Open Compute Project SAI API specification. The NAS implementation uses the SAI API, rather than a vendor-dependent SDK API to access NPU services.

Platform adaptation service

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
• Read power levels reported by PSUs
• Get system inventory and EEPROM information
• Set transceiver module state (Tx laser on/off) and get module information

The PAS detects:

• Common field replaceable units (FRUs) such as PSUs and fans - insertion and removal events
• Over-temperature events for pre-defined temperature thresholds
• Transceiver insertion or removal on physical ports

System device interface

A system device refers to a hardware component including:

• Fans/cooling devices
• Power supplies
• Temperature sensors
• LEDs
• EEPROM
• Programmable devices
• Transceivers

All hardware components except for NPUs are abstracted as system devices. The 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.

The implementation of the SDI API can use any approach suitable for a given platform or vendor:

• sysfs access to Linux kernel device drivers
• User space device drivers using UIO or other methods
• New vendor-specific kernel methods accessible through sysfs, netlink, or ioctl calls
• 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).

Platform description infrastructure

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.

Applications and tools

The OPX software provides a set of tools and commands that allow system administrators to access hardware functionality such as physical port, transceiver information, and system inventory (see Operation and commands for more information).

A thermal control application is also provided to prevent damage of hardware components in case of overheating and/or fan failure.

Run-time

NAS run-time processes and components (see Run-time for complete information).