Changing subject because i think this is a broader/different
discussion than GRASP signature/extensions
I can not link ICN to the use-cases you describe. I could however easily map
the resilient light-switch use-case to multicast and GRASP:
Light switches could M_FLOOD instructions, such as in old building automation:
GROUP_123 on/off. And lights are then preconfigured to belong to a group. Or as
you propose, they could M_FLOOD status, as you propose. And lights are then
preconfigured to be interested in a particular set of light-switches (or other
states, motion sensors etc..).
I am sure a pub-sub geek would describe this as a pub/sub bus kinda operation.
Difference to multicast/messages is that buses supposedly cache state, so a
light that had power failure should immediately get th relevant information,
whether it is group status or other states of interest from the bus instead of
having to wait or re-request messages.
grasp is not a reliable bus so far. But i guess if we would come up with
objective-cache ASA it could easily become one.
Would be lovely to define a "controller-free" model for sensor/actor
architectures.
Wrt to resilience and whether to run data across ACP to be able to validate its
correct/resilient operation: I think we often said that simpler networks such
as low-power iot networks may not want to afford the complexity of separate ACP
and data-plane, in which case the data-plane is the acp, aka:
automatic/secure/resilient. However:
In a large/fast/complex netework, you may have different degrees of degradation
of the network, and the purpose of the ACP is to be the one layer of
last-defense, of what the network should be able to do when everything else may
have failed, especially also to perform possibly complex repair operations
remotely. So the question really is how much you want put into that last line
of defense.
IMHO automated testing and automated injection of errors and all this good
stuff for resilient networks should test the data-plane, and in a simple
approach, all the control for these ongoing OAM operations could go across the
ACP, but maybe even most of that complex and maybe high-load control should go
to data-plane. Think about ongoing Mbps streams of network telemetry to
centralized or decentralized analytics engines that attempt to measure network
health. ACP or not...
Cheers
Toerless
On Wed, Aug 24, 2022 at 04:55:05PM -0400, Michael Richardson wrote:
>
> The use case that led me to start some of this discussion was that of
> using Information Centric Networking in emergency situations.
>
> A key observation that many have made is that backup/emergency systems need
> constant maintenance and testing, and if they aren't used regularly then they
> tend to rot.
>
> This leads to the view that if a converged network can be made resilient
> enough to be used during emergencies, then there are a number of advantages:
>
> a) it probably has more than enough capacity for the emergency traffic!
> b) if it breaks, then someone will notice, and there is an incentive to fix it
> c) many situations which aren't full on emergencies benefit from the
> resiliency
>
> I looked through some documents, such as:
> https://www.rfc-editor.org/rfc/rfc7945.html#section-3
>
> https://www.rfc-editor.org/rfc/rfc8884.html
> Research Directions for Using Information-Centric Networking (ICN) in
> Disaster Scenarios
> Read the requirements at:
> https://www.rfc-editor.org/rfc/rfc8884.html#section-3.3
> and compare them to what GRASP offers?
>
> In thinking about building automation IoT systems, the ICN approach is rather
> useful. In it, one does not tell a light switch which light bulbs to
> control, but rather tells a light bulb what senses should be relevant to it.
> The sensors then simply announce their state, and the bulbs respond.
>
> In a converged building network, where there might be many hundred Gb/s of
> bandwidth for the tenants to use, the sensor network could be accomodated by
> a series of gateways which translate between 802.15.4 radios or BACnet, and
> a fiber-optic backbone. But the control network needs to be protected from
> the rest of the traffic, and isn't that what the ACP does?
>
> Is there that much difference between learning that an optical module has
> gone bad via SNMP/NETCONF over ACP, and learning that the elevator door is
> damaged and won't close, so elevator 14 is out of service, over BACnet?
> (Could the two be related?)
>
> So in the view that the resiliency of the control network must be
> continuously be tested, then the right answer is to use the control (ACP)
> network for all the automation functions.
>
> Of course we can run DTLS for MQTT and the like over the ACP, and for many
> things we probably should do that, but we also need all the caching and
> flooding mechanisms that GRASP offers.
> (particularly during a flood. Hmm. Some kind of RFC2616-like RFC about new
> M_FLOOD objectives for use during a flood ....)
>
> --
> Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
