[Suit] SUIT Architecture -- Operating modes

[Hannes Tschofenig <[e-mail]>]

Hi all,

at the virtual interim meeting earlier this year Dave suggested terminology, which was based on
ITU-T work for firmware updates:

- Device Core: stores/uses software/firmware,
i.e., the IoT device itself

- Communicator: checks software/firmware
status of device and initiates update as needed
May or may not be on the device itself

- Status Tracker: tracks update status of
devices under its administration

- Firmware Server: distributes
software/firmware packages to devices
May or may not be combined with Status Tracker

At IETF#101 we talked about the following three categories for firmware update interactions:

- Client-initiated: IoT device polls for updates and downloads image when it wants
- Server-initiated: Server pushes update to a device
- Hybrid: Server pushes notification of availability of an update to a device, and the client then
  downloads the image when it wants.

In https://tools.ietf.org/html/draft-ietf-suit-architecture-00 Brendan and I made a proposal for
a new terminology. Here is the relevant text:

-----

3.10.  Operating modes

   There are three broad classifications of update operating modes.

   * Self initiated
   * Third-party initiated
   * Hybrid

   Self initiated updates take the form of a proactive IoT device that
   checks for updates.  Third-party initiated updates are triggered by
   an actor other than the IoT device, be it a server, a peer, or a
   user.  Hybrid updates are those that require agreement from both the
   target IoT device and another actor.

   Third-party initiated updates are important to consider because
   timing of updates may need to be tightly controlled in some high-
   reliability environments.

   An IoT device goes through several steps in the course of an update,
   each of which can be self-initiated or third-party initiated, or
   hybrid.  An IoT device may go through the following steps, though
   this is not a comprehensive list.

   * Notification
   * Pre-authorisation
   * Dependency resolution
   * Download
   * Installation

   The notification step consists informing an IoT device that an update
   is available.  This can be accomplished via polling (self-initiated),
   push notifications (third-party initiated), or more complex
   mechanisms.

   The pre-authorisation step involves verifying the update authority
   and making a determination that the device is prepared to initiate
   the fetching and processing of updates.  If the device has all
   information that is necessary to make this determination, then the
   pre-authorisation may be self-initiated.  However, the device can
   wait for instruction to begin (third-party initiated).  Hybrid
   approaches are possible as well.

   A dependency resolution phase is needed when more than one component
   can be updated or when a differential update is used.  The necessary
   dependencies must be available prior to installation.

   The download step is the process of acquiring a local copy of the
   payload.  When the download is self-initiated, this means that the
   IoT device chooses when a download occurs and initiates the download
   process.  When a download is third-party initiated, this means that
   either the remote service tells the IoT device when to download or
   that it initiates the transfer directly to the IoT device.  For
   example, a download from an HTTP server is initiated locally.  A
   transfer to a LwM2M Firmware Update resource [LwM2M] is initiated
   remotely.

   Installation is the act of processing the payload into a format that
   the IoT device can recognise.

   Each of these steps may require different permissions expressed in
   claims and may be implemented in a variety of ways.

----

Offline feedback from Dave indicates that it did not help improve clarify.
Hence, I am going it a new try. Let me know what you think.


-----

3.10.  Operating modes

   There are three broad classifications of update operating modes.

  * Client-initiated Update
  * Server-initiated Update
  * Hybrid Update

  Client-initiated updates take the form of a Communicator on a Device Core
  proactively checking for new firmware imagines provided by Firmware Servers.

  Server-initiated updates are important to consider because
  timing of updates may need to be tightly controlled in some high-
  reliability environments. In this case the Communicator, potentially in
  coordination with the Status Tracker, determines what IoT devices need
  qualify for a firmware update. Once those devices have been selected the
  Firmware Server distributes updates to those Device Cores.

  Note: This assumes that the Firmware Server is able to reach the Device Cores,
  which may require Device Cores to keep reachability information at the Communicator
  and / or at the Firmware Server up-to-date. This may also require keeping state at
  NATs and stateful packet filtering firewalls alive.

  Hybrid updates are those that require an interaction between the Device Core
  and the Firmware Server / Communicator. The Communicator pushes notifications
  of availability of an update to the Device Core, and the Device Core then
  downloads the image from the Firmware Server when it wants.

   An alternative approach is to consider the steps an IoT device has to go through
   in the course of an update:

   * Notification
   * Pre-authorisation
   * Dependency resolution
   * Download
   * Installation

   The notification step consists of the Communicator informing the Device Core
   that an update is available. This can be accomplished via polling (client-initiated),
   push notifications (server-initiated), or more complex
   mechanisms.

   The pre-authorisation step involves verifying whether the entity signing
   the manifest is indeed authorized to perform an update. The Device Core
   must also determine whether it should fetching and processing of the
   firmware image (unless it has been attached already to the manifest itself).

   A dependency resolution phase is needed when more than one component
   can be updated or when a differential update is used.  The necessary
   dependencies must be available prior to installation.

   The download step is the process of acquiring a local copy of the
   firmware image.  When the download is client-initiated, this means that the
   IoT device chooses when a download occurs and initiates the download
   process.  When a download is server-party initiated, this means that
   either the Communicator / Firmware Server tells the IoT device when
   to download or that it initiates the transfer directly to the IoT device.
   For example, a download from an HTTP-based Firmware Server is client-initiated.
   A transfer to a LwM2M Firmware Update resource [LwM2M] is server-initiated.

   If the Device Core has downloaded a new firmware image and is ready to
   install it it may need to wait for a trigger from a Communicator to
   install the firmware update, may trigger the update automatically, or
   may go through a more complex decision making process to determine
   the appropriate timing for an update (such as delaying the update
   process to a later time when end users are less impacted by the update process).

   Installation is the act of processing the payload into a format that
   the IoT device can recognise and the bootloader is responsible for then
   booting from the newly installed firmware image.

   Each of these steps may require different permissions.

----

Is this any better?

Writing the text above I noticed that the Communicator and the
Status Tracker have some overlapping functionality. Both entities
need to know about the status of the device. Also it would be
good to know what "initiates update" for the communicator
actually needs.

Finally, the term "Device Core" sounds a bit strange. Would it
be better to call it 'update service' or just refer to IoT device?

Ciao
Hannes


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.