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

["Romascanu, Dan (Dan)" <[e-mail]>]

Hi,

I do not think that management equals SNMP and Netconf
I do not think that management equals the manager-agents architecture
I do not think that management equals control and telemetry

We need to think with fresh and open minds starting with the use cases
about how smart objects exchange status and measured parameters
information, and how they need to behave from a control plane point of
view in order to meet the requirements of a smart system. 

Then we can make an assessment of what of the management protocols and
data models developed (in the IETF and elsewhere) in the two decades of
network management experience in the Internet can be re-used and what
needs new development. 

Dan




> -----Original Message-----
> From: [e-mail] [mailto:smartobjectdir-
> [e-mail]] On Behalf Of Fred Baker
> Sent: Sunday, October 09, 2011 11:04 PM
> To: Vint Cerf
> Cc: [e-mail]
> Subject: [smartobjectdir] "Management" vs "control and telemetry"
> 
> 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 a
>  n 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.
> _______________________________________________
> smartobjectdir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/smartobjectdir