OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

smartgrid-interest message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: What's wrong with having devices communicate in their ownnative languages


OK guys.  I hesitate to pontificate too much since we are getting a bit off track here, but as someone who built a company back in the 90’s who developed BOTH routers and gateways specifically for connecting control networks to IP networks I can’t help but wade in on a topic that I am very intimate with.  Although I tend to agree that that gateways are better than tunneling routers in most cases where you have heterogeneous networks I do feel the need to play the devil’s advocate a bit here.

 

To say that system boundaries should be dictated by network boundaries is a bit too simplistic for me.  While I will admit that it is often very difficult to tunnel control/device network protocols over IP I don’t think that just because a packet is entering a tunnel it is necessarily crossing a system boundary.  I also think that saying tunneling should never be used is akin to saying things like “late night romantic phone calls  should never be conducted over packet switched networks like the internet, i.e. VOIP.”  I prefer to draw system boundaries based upon functional responsibilities and ease of moving information across the boundaries.

 

There is no doubt that network boundaries should play a part in deciding where to draw system boundaries, but if by system boundary you mean that you have to put in a gateway and do semantic mapping across that gateway then you also have to be very careful.  Everywhere you put a gateway you have to deal with the so called “binding” problem and when the binding problem starts to get distributed across your network the complexity can grow sharply.  This can be especially true when you have to go back and start swapping out already commissioned equipment or reconfiguring your network. With tunnels the binding problem is isolated to both ends of the tunnel. For every anecdote of someone having a problem using a tunneling router I can probably give you one where the a gateway and the binding problem bit someone in the ass.

 

Again I’m not trying to advocate tunnels and routers over semantic mappings and gateways I’m just trying to point out that each has their place and neither should be condemned outright.  The fact is that transporting information across heterogeneous networks is not for kids and there is no magic bullet.

 

All that being said – of course we need to have semantically consistent data models that can “hopefully” be both transported and mapped to a variety of networks, protocols, and end devices that have to consume the information.

 

 

-ed koch

 

 

From: Considine, Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu]
Sent: Thursday, April 02, 2009 7:42 AM
To: smartgrid-interest@lists.oasis-open.org
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:michel@universal-devices.com]
Sent: Thursday, April 02, 2009 1:41 AM
To: smartgrid-interest@lists.oasis-open.orgSubject: 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:brian@skyfoundry.com]
Sent: Tuesday, March 31, 2009 11:11 AM
To: smartgrid-interest@lists.oasis-open.org
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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]