The Transponder Abstraction Interface, or TAI, defines the API to provide a form-factor/vendor independent way of controlling transponders and transceivers from various vendors and implementations in a uniform manner. It is based upon and quite common to the Switch Abstraction Interface, or SAI.
TAI is hosted by Telecom Infra Project (TIP) Open Optical and Packet Transport (OOPT) working group.
TAI is an interface specification implemented as a collection of C-language header files. TAI adopts the use of many terms from SAI, including "Adapter" and "Adapter Host".
An Adapter is similar to a user mode driver. It translates the hardware independent TAI interface to a specific hardware implementation. This is implemented as a shared library, and will typically be provided by the module vendor. This shared library is called libtai.so. TAI library is used interchangebly with TAI adapter.
If the transponder supports multiple types of module hardware vendors, TAI multiplexer can be used to multiplex several kinds of TAI adapters. For details, see docs/TAI-MUX.pdf.
An Adapter Host is hardware independent software which uses the TAI interface to provide optical transponder functionality to other parts of the system. An adapter host loads the shared library adapter. TAI application is used interchangebly with TAI adapter host.
Some TAI adapters are open sourced in the implementation repo.
+------------------------+
| |
| Adapter Host |
| |
+------------------------+
-------------TAI Interface-------------
+------------------------+
| |
| Adapter |
| |
+------------------------+
--------------HW Interface-------------
+------------------------+
| |
| Hardware |
| |
+------------------------+
- inc/ : TAI API definition
- meta/ : TAI meta library
- TAI meta library provides helper methods for allocation, serialization etc..
- tools/taish : TAI shell
- TAI shell works as a TAI application and provides debug features for TAI library
- tools/framework : TAI library framework
- A framework to develop TAI library
The adapter host begins using TAI by invoking the tai_api_initialize()
function. This function allows the adapter to initialize various data structures
for subsequent use. It does not initialize the underlying hardware. There
are two parameters passed to the tai_api_initialize() function: flags, which
is currently unused and must be set to zero, and services.
services is a pointer to a structure of function pointers. This structure
provides the adapter with function entry points (services) in the adapter host
which the adapter can call. There is currently only one member in the structure,
module_presence, which the adapter calls whenever there is a change in the
presence or absence of modules in the system. As a matter of fact, the adapter
will typically call the module_presence() function for each module in the
system, perhaps even before returning from the tai_api_initialize() function.
The module_presence() function may be called from a different thread than the
main adapter host thread. And since TAI functions are not thread-safe, the
adapter host is required make sure that it does not re-enter the TAI interface
from the module_presence() function. This can be done by, for example,
enqueueing the notifications for later processing on the main adapter
host threa