[smartobjectdir] "Management" vs "control and telemetry"

[Fred Baker <[e-mail]>]

Let me step out on a limb here, one which Ersue and Dan will very quickly try to saw off. I'm of the opinion that our "Management" protocols, SNMP and NetConf, are very poorly suited to the world of Smart Objects, and that if we simply describe this as "management" the Internet Community will dismiss it as a previously solved problem.

Let me give you two relatively simple examples.

You will recall that when we were developing SNMP, we talked a lot about the Internet Toaster, and that Epilogue developed a Toaster MIB (which can still be found of you ask Google) to demonstrate the operation of it. The premise of the Toaster MIB is that there is some central controller; someone places bread into the toaster, wanders off to the toaster controller, and the toaster controller might do a SET to put actuate the toaster, and then might monitor is SNMP objects to see how things were going.

The simplest example is what I call the Internet Light Bulb, something on which I have an internet draft half written. Let's imagine I have a single light bulb (or a multicast group full of lightbulbs, but for the moment it is one bulb) that is operated by two (or more) switches. Electrically, that's not hard -

                            ,-.
         +-----|||---------(   )----------------+
         |                  `-'                 |
         |      /-------------------------      |
         +-----/                           /----+
                 -------------------------/

I have two switches, each with two positions. If they are both in the same position current flows, and if they are in different positions current doesn't flow.

In a building control environment (Echelon makes this product, and I am describing their implementation), each switch has an identity and each light bulb has an identity. When someone throws a switch, the switch announces "I am X, and I command Y to go to the state 'ON'". Y receives the command, verifies that it is still Y (all the other light bulbs receive it too, and note that they are not Y), verifies that X is authorized to give it that command, and turns itself on. It then announces "I am Y, and I am in the state 'ON'". Each other switch X' receives the announcement, decides whether it cares what state Y is in, and if so records that Y is in fact on. Subsequently, if someone else tells another switch to turn Y on, it will do nothing; Y is already on. But if someone throws any of the switches to turn Y off, the switch will say "I am X', and I think Y should be off".

Here's a slightly more complex example: a thermostat. Somewhere, there is, let's imagine, an energy management system. It is being told by the utility that between this time and that the price is HIGH and is otherwise LOW. It has a policy that includes telling the thermostat (at times this and that) to change its thresholds. The thermostat, in turn, has two thresholds. If the temperature falls below one temperature it will turn on the heat, and if the temperature goes above that it will turn off the heat. If the temperature rises above a second threshold it will turn on the air conditioning, and if it falls below, it will turn the air conditioning off. When the price is LOW, the two thresholds might be at 71 and 73 degrees Fahrenheit respectively; when the price is HIGH, they might be at 68 and 78. So the EMS might set the thresholds from time to time using whatever protocol it likes, perhaps NetConf; when the thermostat observes the temperature crossing one threshold or the other, it could report that to the EMS and let the EMS send a command to the heater or the air conditioner; more likely, it will announce that it thinks the temperature is "Cold", "Nice", or "Hot", and the heater and the air conditioner will observe that their policy is that when it is "Cold" or "Hot" (respectively) it policy (controlled by the EMS) is to turn itself on, and when it is "Nice" to turn itself off.

The information that needs to be exchanged, in each case, is the source's identity ("I am X"), the target's identity ("I think that Y..."), a variable name ("on/off status"), and a value ("on"). It also needs to announce a method (it is reporting current state or it is requesting a state change), and it needs whatever information is necessary to prove its identity. Current equipment used in embedded systems - the stuff our proposed system is trying to displace - does this (Echelon's equipment) in a total of 11K ROM and 2-4K RAM for the entire system, never mind the management interpreter. I know of no SNMP implementation that can do that, nor any XML implementation, and they certainly don't use one protocol to read information and another to write it. So for the purpose at hand, protocols I am seeing presented as The One True Religion have implementers of existing commercial systems telling me while giggling in their sleaves that they have "no fear of real competition" from an IETF/IRTF implementation. That's quote/unquote.

I could imagine the thing being in JavaScript Object Notation, a notation designed along the lines of RFC 5545, or a variety of other approaches. My point is S-I-M-P-L-E, and designed to enable conversations among actors in the game but without religious dogma about who is a controller and who is controlled. They are actors with state, and an actor might be a controller or a controllee in subsequent milliseconds.