Re: [smartgrid-interest] What's wrong with having devices communicate in their own native languages

Thanks Toby for the valid, yet entertaining 
analogies.

A couple pragmatic points to add:

 

It is not realistic expect adoption of a single 
protocol (one vertical stack). The train has left the station - the stuff 
already out there will live on indefinitely.  Protocol convergence 
techniques (of which tunneling is one) will a necessary inconvenience. IP is not 
the internet - it is a packet format and addressing scheme. Often people say 
"IP" and mean a stack of protocols on top of IP - TCP, UDP, and on up the 
stack. We all know IP doesn't provide interoperable information 
exchange - it provides for exchange packets (or buckets) of bits. The 
reality is we are seeing IP as a transport all the way to the end point 
(mostly on proprietary link layers at the moment).  We'll also have 
endpoints that don't understand IP...and thus we'll have some kind of 
convergence layers to accommodate those.  I suspect the idea of 
convergence 'shims' will be needed at all layers of the stack for the same 
reason - a lot of stuff is on it's way into the field already.  It may 
seem like there is an opportunity to define and force a single set of standards 
every vendor will adopt, and even if we accept that could happen, it won't 
change the fact that this train has left the station and we are trying to catch 
up to an industry that is accelerating. We may *think*  it best to 
ensure all that legacy stuff gets ripped out and junked, and only good 
clean standard based equipment populates the new smarter grid, but that is 
neither very "green" nor very likely. Just like those "late night explicit romantic phone call" will likely stay with us as well :-).

 

-Ben

 

 

 

 

 

 

  
----- Original Message ----- 

  
From: 
  Considine, Toby (Campus Services IT) 
  

  
To:  
  

  
Sent: Thursday, April 02, 2009 7:41 
  AM

  
Subject: [smartgrid-interest] What's 
  wrong with having devices communicate in their own native languages 

  

  

  
Subject 
  changed because discussion was veering far from EMIE

  
 

  
It 
  all depends on where you define the system boundaries.

  
 

  
I 
  don’t care if you and your family walk around naked in your house. When you go 
  on the street, and expect to interact with others, then societal expectations 
  for behavior and dress kick in. I don’t care if you create small naturist 
  clubs where you can walk around naked with a larger group. Every naturist camp 
  always has a sign by the door “Did you remember to put on clothes?” Streaking, 
  though, is always disruptive. As someone who has managed any number of “native 
  protocols” interacting on a campus backbone, I know that those are much more 
  disruptive then the kids who streak the library each semester before 
  exams.

  
 

  
Tunneling 
  protocols over IP is the like late night explicit romantic phone call. It may 
  be an expedient solution to a short term problem in a niche situation, but it 
  is no architecture. If the communication style extends to other phone calls, 
  you get social problems, and potential law suits. Tunneling protocols, xxxx 
  over IP, are just  problematic. They are barriers to interoperability. 
  They often don’t recognize external costs. I have seen dozens of man hours 
  expended to avoid a second $500 gateway. I’ve seen similar amounts of man 
  hours expended again and again by network operations staff to sustain the 
  protections that these tunneled protocols need.

  
 

  
The 
  great wide internet is non-deterministic – which causes problems in lots of 
  native protocols. Native protocols have all sorts of untested and undefined 
  dependencies. I can regale you with stories of control protocols over IP 
  disrupted by  replacement of a router blade…and of broadcast storms 
  stopped only by unplugging all building system gateways, and then rebooting 
  all routers, and then letting things stabilize, and then turning on each 
  building gateway one at a time…why? Because the makers of that proprietary 
  “it’s our own variant of UDP” control protocols over IP just didn’t anticipate 
  the obscure interaction, and even extensive use of VLANs could not protect 
  these systems.

  
 

  
At 
  another University located near UNC, almost a year was spent figuring out that 
  merely putting an un-configured HP Jet Direct card on-line would take the 
  control system of the coal plant off line. Now that was 
  fun.

  
 

  
The 
  net of these experiences is a few principles that *I* hold 
  dear…

  
 

  
-          
   Systems 
  should be small and coherent, and should not have the internet in the middle. 
  If the internet is in the middle, or perhaps even if IP is in the middle, it 
  should be defined as two systems.

  
-          
  Internal 
  “native” protocols should not be used to communication between 
  systems.

  
-          
  Anything 
  that can be attached to the internet, will be. This means that it will be 
  exposed to unanticipated protocols, hostile interactions, and even accidental 
  DOS attacks. We should define interfaces to systems 
  accordingly.

  
-          
  The 
  communication stack at the edge of a system should be well tested and well 
  debugged, and have been used in as many open scenarios as possible so that all 
  exceptionalism will have been eliminated. I never want to find that 
  “unanticipated interaction”

  
-          
  When 
  any combination of systems gets to a sufficient size, interoperability (or the 
  lack thereof) becomes the most significant determinant of expense. (Every now 
  and then, someone turns to me and says “wouldn’t it be easier if we just 
  picked one vendor, one brand, and…I point out that if we did that, it would 
  take us 20 years to get the “one true protocol” installed, and by that time, 
  we would be unable to buy the legacy systems any more.

  
 

  
At 
  the edge of the system, we should have well defined discoverable interfaces. 
  There will be circumstances, few and rare, in which we legitimately need to 
  split a system in half – but not many. Does this mean I want IP everywhere? 
  Well, almost. Zigbee is not IP, but for purposes of this conversation it might 
  be.

  
 

  
Take 
  my PC. It has two IP addresses for its two interfaces (wired and wireless). I 
  do not need an IP address on my mouse, nor on my screen. See, I don’t want IP 
  everywhere. But I uses KVM to access my servers, with an IP based 
  communications from my mouse keyboard, and display. KVM is a special case, 
  with special needs, and special costs, and I can break that one IP per system 
  rule because I can articulate the reasons, and support the special security 
  requirements this requires. My KVM also has no interoperability requirements. 
  

  
 

  
How 
  do you define system?

  
What 
  is the interoperability requirement?

  
Do 
  you want the integration to scale?

  
Will 
  one integrator be responsible for all systems, and all systems that interact 
  with them?

  
 

  
On 
  one side of those questions is “native protocols” and “xxx over IP” 
  

  
On 
  the other side IP is not enough, and you have services and discoverability and 
  mature security and…

  
 

  
Take 
  your pick. Answer all 4 questions. Then, and only then, is it time to listen 
  to the justification of the native protocol. It would be interesting if to see 
  how many want to put *that* explanation into the sales literature for 
  the product…

  
 

  
tc

  
 

  
 

  

  

  
  

  
"A 
  man should never be ashamed to own that he has been in the wrong, which is but 
  saying ... that he is wiser today than yesterday." -- 
  Jonathan Swift

  

  
  

  
    
    

      
        
Toby 
        Considine

        
Chair, 
        OASIS oBIX TC
Facilities Technology Office
University of North 
        Carolina
Chapel Hill, NC

      
        
  

      
        
Email: 
        Toby.Considine@ unc.edu
Phone: 
        (919)962-9073 

        
http://www.oasis-open.org 
        

        
blog: 
        www.NewDaedalus.com

  
 

  
 

  

  

  
From: Michel Kohanim 
  [mailto:] 
Sent: Thursday, April 02, 
  2009 1:41 AM
To: 
  : RE: 
  [smartgrid-interest] Draft Charter - Energy Market Information 
  Exchange

  
 

  
Hi 
  Brian, I had to think about this for a day! Perhaps my statements are going to 
  cause a heated debate, but, here I go:

  
 

  
I 
  really do not see why everything has to communicate IP. What’s wrong with 
  having devices communicate in their own native languages and over their 
  desired (most optimal) media? What do we gain by having all devices 
  communicate IP if – and as you (Brian) suggested – we do not first come up 
  with the abstract model? We have a hammer?

  
 

  
With 
  kind regards,

  
 

  
********************************

  
Michel Kohanim, 
  C.E.O

  
Universal Devices, 
  Inc.

  
 

  
(p) 
  818.631.0333

  
(f) 
  818.708.0755

  
http://www.universal-devices.com

  
********************************

  
 

  

  
From: Brian Frank 
  [mailto:] 
Sent: Tuesday, March 31, 2009 11:11 
  AM
To: 
Subject: 
  Re: [smartgrid-interest] Draft Charter - Energy Market Information 
  Exchange

  
 

  
Couple of my thoughts since Toby cross-posted some of my 
  oBIX ideas...

I don't suspect that many in this group need to be 
  convinced that technologies like 6LoWPAN create the opportunity to communicate 
  IP all the way out to the edge.  In fact, it is hard to imagine using 
  anything but IP for communication these days - even for sub $10 devices 
  (legacy devices excluded of course).

But just because a 6LoWPAN device 
  speaks IP doesn't necessarily mean that it going to run a SOAP 
  stack:
  - These are typically sub-3$ dollar microprocessors with less 
  than 100KB of memory
  - Low end wireless networks don't run TCP 
  well,  only UDP; this means common techniques for end-to-end security 
  such as TLS are not available
  - Payload size on a 6LoWPAN packet is 
  ideally less than ~80 bytes
  - 6LoWPAN nodes spend most of their time 
  sleeping which makes communication difficult

But these are all 
  surmountable problems if you define an information model which works well 
  end-to-end.  Translating between protocols (HTTP-to-UDP) is pretty 
  easy.  Translating between data encodings is also easy 
  (XML-to-Binary).  But translating between data models is really, really 
  hard and almost always results in a degradation of information.

So my 
  perspective is that the most important task is define the abstract 
  model.  Then you can apply different protocols and encoding as needed as 
  long as everyone is working off the same basic ontology.  

This is 
  exactly what oBIX does.  It defines a very simple, but powerful 
  meta-model for building models.  The oBIX meta-model is based on type 
  theory that embraces the notion that modeling the real-world is a messy and 
  inexact science.  But it turns out to work really well for simple sensors 
  all the way up to million point SCADA 
  systems.

Brian