Re: [Suit] SUIT Architecture -- Operating modes

[Emmanuel Baccelli <[e-mail]>]

Hi Dave

On Wed, Jun 6, 2018 at 11:37 AM Dave Thaler <dthaler=
[e-mail]> wrote:

>
> The notification of an update can be device initiated (pull) or remotely
> initiated (push).
> The transfer of the actual image can also be device initiated (pull) or
> remotely initiated (push).
> The three cases are (I think the other combination doesn't make sense):
> 1) Push notification, push image
> 2) Push notification, pull image
> 3) Pull notification, pull image
>
>
In my opinion, this is also potentially clearer.
One comment though: does case 1 really make sense?
If the image is pushed anyways, there is arguably no need for prior
notification.
Or are we implicitly mixing "notification" with "pre-authorization" aspects?

Emmanuel





>
> -----Original Message-----
> From: Suit <[e-mail]> On Behalf Of Hannes Tschofenig
> Sent: Wednesday, June 6, 2018 5:27 PM
> To: [e-mail]
> Subject: [Suit] SUIT Architecture -- Operating modes
>
> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-suit-architecture-00&data=02%7C01%7Cdthaler%40microsoft.com%7Cfdbcbf2e3be442dc544208d5cb8fc354%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636638740682287207&sdata=Z8JJlDZINiolbZmqINLWCMEaWT1%2BcUkAGQpBqfhjvCw%3D&reserved=0
> 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.
>
> _______________________________________________
> Suit mailing list
> [e-mail]
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7Cdthaler%40microsoft.com%7Cfdbcbf2e3be442dc544208d5cb8fc354%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636638740682287207&sdata=W0Ak6fX0oHbALgg5XxU0YiN9z%2Ber18j7sUJbjfbqow8%3D&reserved=0
>
> _______________________________________________
> Suit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/suit
>