Device Adapter Framework

The BAA layer provides the capability to manage access nodes of the same type from different vendor implementations across the BAA layer's Southbound Interface (SBI) where each vendor implementation can provide an adaptation to the abstracted standard data model for that type of device (e.g., OLT, DPU) across the BAA layer's Northbound Interface (NBI). To realize this capability, the OB-BAA software architecture's PMA Registry component includes an Adapter Framework where each vendor implementation is defined as an instance of a Vendor Device Adapter (e.g., Device Adapter A, Device Adapter B) that is adapted to the Standard Device Adapter (SDA) for that type of device.

Adapter Framework

The OB-BAA software architecture's Adapter Framework provides the following capabilities:

Device Adapters

The Architecture section's overview discussed that the representation of an AN is exposed through interfaces in the BAA layer. These views of the AN are defined as:

The vendorAN and pAN representations are realized in OB-BAA using two different types of Device Adapters - Standard Device Adapters and Vendor Device Adapters.

Standard Device Adapter (SDA)

The Standard Device Adapter provides a standard compliant abstract data model per device type (e.g., DPU, OLT) that represents the standard pAN instances to management and control systems. The BAA layer uses the SDAs to validate the compliance of Vendor Device Adapters.

Warning: In this release of OB-BAA, the OLT and DPU SDAs defined in TR-413 are provided by the OB-BAA distribution. However, SDA's are not pluggable modules and only the SDA's provided by the OB-BAA distribution are supported. In a future release new SDA's can be defined and deployed by the BAA layer administrator.

Vendor Device Adapter (VDA) or Coded Adapter

New instances of a vendorAN requires a corresponding VDA that supports instances of the vendorAN based on the unique combination of Vendor + Hardware Variant + Model version (E.g. Nokia DPU 1.0, Huawei OLT 2.0).

The purpose of the VDA is to:

As a VDA is specific to a vendor, the VDAs are developed by Vendors and are pluggable into OB-BAA using the VDA's interface.

The VDA that is plugged into OB-BAA has certain requirements. These are:

Info: Future releases of OB-BAA will allow VDAs to define:

The Adapter Framework At Work

The Adapter Framework translates the commands received by the BAA layer in the standard data model for that type of pAN into the data model supported by the vendorAN instance. Conversely the Adapter Framework takes events that come from the vendorAN instance and translates the event into a representation supported by the pAN device type. The flow is depicted in the diagram below:

The diagram below provides an example of an "Edit Configuration" command as it processes through the Adapter Framework:

Vendor Device Adapter Interface

The following the interface for that each instance of a VDA implements to work in the Adapter Framework.

public interface DeviceInterface {
   /**
     * Veto changes if needed based on adapter specific rules.
     *
     * @param device    Device for which the request is dedicated
     * @param request   request which needs to validated based onn rules
     * @param dataStore the existing device datastore
     */
    void veto(Device device, EditConfigRequest request, Document dataStore) throws SubSystemValidationException;
 
    /**
     * Send an edit-config request for a device at the SBI side.
     *
     * @param device  Device for which the request is dedicated
     * @param request the edit-config request
     * @return future response
     * @throws ExecutionException throws Execution Exception
     */
    Future<NetConfResponse> align(Device device, EditConfigRequest request) throws ExecutionException;
 
    /**
     * Send request to device on first contact scenario at SBI side.
     *
     * @param device Device for which the request is dedicated
     * @param getConfigResponse get-config response from PMA
     * @return pair of request and response
     * @throws NetconfMessageBuilderException throws Netconf Message builder exception
     * @throws ExecutionException             throws Execution Exception
     */
    Pair<AbstractNetconfRequest, Future<NetConfResponse>> forceAlign(Device device, NetConfResponse getConfigResponse)
            throws NetconfMessageBuilderException, ExecutionException;
 
    /**
     * Send a get request to device at SBI Side.
     *
     * @param device     Device for which the request is dedicated
     * @param getRequest The filtered get request for device
     * @return future response
     * @throws ExecutionException throws Execution Exception
     */
    Future<NetConfResponse> get(Device device, GetRequest getRequest) throws ExecutionException;
 
    /**
     * Send a get-config request to device at SBI Side.
     *
     * @param device           Device for which the request is dedicated
     * @param getConfigRequest The filtered get-config request for device
     * @return future response
     * @throws ExecutionException throws Execution Exception
     */
    Future<NetConfResponse> getConfig(Device device, GetConfigRequest getConfigRequest) throws ExecutionException;
 
    /**
     * Get the connection state for the device based on the protocol.
     *
     * @param device Device for which the request is dedicated
     * @return Connection State of the device
     */
    ConnectionState getConnectionState(Device device);
}

<–Architecture