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