The Control Layer

The Control Layer utilizes the powerful data integrity features of the Fabric Layer to provide guaranteed delivery of information, both upstream and downstream between the devices and the systems responsible for them. The Fabric Layer protocol provides data sequencing, session time-stamping and failover/recovery that ensures that there is always a source for files needing to be loaded for the device and a welcome listener for data being sent upstream. 

The server-side infrastructure consists of collectors and controllers. The collectors are the recipient of upstream data they can be grouped according to the kinds of data they receive or they can call be capable of collecting all data and distributing it to where it's needed. Besides the data itself, it maintains an audit trail of all received data which can be used to ensure that devices are operating as reporting as expected.

The data that the collectors manage includes:

  • Transient data:
    • traffic statistics;
    • event counters;
    • health metrics
  • Relatively static data that is mostly only updated when it changes:
    • status indicators;
    • operating modes;
    • states of downloaded files.
  • Binary streaming data:
    • memory dumps;
    • log files (including real-time tailing);
    • tunneled data for local device protocols

The controllers coordinate the flow of traffic using transaction semantics (open, prepare, rollback, commit). It delivers commands and data to the Control Layer agent in devices that are used to determine what and when certain activities should happen. It is designed such as to need to initiate connections as rarely as possible, by proactively instructing devices on its various activities during scheduled device-initiated control sessions.

During these proactive device check-ins, and on the occasionally required server-initiated control command, the controller transfers:

  • Individual object/attribute puts:
    • Counter resets;
    • Configuration object changes;
    • On-demand data upload commands;
    • Action commands such as drop connection or device reset.
  • Data templates that define specific sets of data to be grouped for transport up or down:
    • Formats of data items;
    • Device subsystem responsible for maintaining the items and the interfaces used to obtain/store them;
    • Version numbers that allow for continued interoperability even if not all devices have the same template version.
  • Profiles that contain proactive commands for the agent:
    • Scheduled reporting, to the collectors, of data defined by specified templates ;
    • Triggered reporting, based on simple threshold and event rules, of data defined by specified templates;
    • Available download files such as firmware, application code and configuration files along with optional rules for determining when the device should download them.
      • Files can be downloaded using HTTP, FTP or other protocols from non-managed servers, or from the controller.
  • Binary files, streamed and compressed using the Fabric Layer's L4Z compression:
    • Configuration files;
    • Firmware code;
    • Application code;
    • Resource files for applications;
    • Staged files for access by other devices on the local network (e.g., vendor-specific firmware/configuration files).

Technically, all data transports from the controllers are initiated by the device. On-demand connections are requested via connection requests sent to the device by the Fabric Layer protocol, either directly or via NAT ports held open by STUN requests (the controller maintains its own STUN server) or, when absolutely required, by connections held open during service intervals via Web Sockets.

Besides downloading rules to devices, the controller is also responsible for enforcing those rules, monitoring the status of collected data in the collector to ensure that data is received as instructed and checking with devices that did not conform to get status, reissue the profile instructions if necessary or alert to the Self-Healing Layer if repeated attempts to automatically resolve the problem are unsuccessful.

A management console, a part of the controller, is responsible for editing templates and profiles, including the rules and also reports on collector performance and, most importantly, tracks and reports on the state of all upload and download transactions, both as a resource to upper layers and also for user monitoring and possible intervention.

Not to be forgotten, the Control Layer agent, running on each managed device, receives the values, templates and rules templates and performs them as required. The rules at the Control Layer are simple ones: take action on a schedule, on a simple trigger or on command.  It reports in on its progress at each of its designated reporting intervals for each of its assigned tasks. 

Typical scenarios include:

  • Reporting status indicators as set by the Self-Healing Layer (green, yellow, red-type statuses) along with other profile-defined values that go with them on a regular basis (daily is probably normal);
  • Reporting status changes or critical non-transient value changes (such as configuration file version changes, operating modes or health status);
  • Keeping ports and/or Web Sockets connections open during configured intervals to support server-initiated commands.

 

The Self-Healing Layer....