Hi all, thanks so very much for all the responses. As I had
expected, this is one of those topics that elicits passionate debate and
discussions.
Now, I am going to go in chronological order:
Brian, I almost agree with you but I have a question: in your analogy
of gateway/routers, where do you see QOS, Firewall, IPSec, SNMP, etc. be
implemented at? I am sure you do not mean that all end points will implement
QOS, IPSec, etc. and, therefore, at least there are some high level functions
that the end points will not understand regardless of their protocol. Does this
mean endpoints should not be IP based, no, not at all. It just means that there
are system boundaries which have not yet been well defined. As such, to me, talking
about the transport protocol now without boundary requirements is tantamount to
building a software system based on an operating system (of course, nothing
wrong with this but not very scalable).
This brings me to Neil and his right on assessment on the
management and non-functional side of things and the importance of CMIP or
something similar. Neil is taking the question and bringing it up a couple of
levels to address the requirements and boundaries first.
And, Toby, yes also I love your missive – and even though
I might not agree with your conclusions – since you have so eloquently explained
the necessity for defining system boundaries and information models: you do not
want your mouse and keyboard to be IP based (they could be of course). But, I
suspect, you do want them to be compatible/interoperable with your other
computers as much as possible.
Ben, I am in agreement with you but I am not convinced that the
ship has sailed yet!
David, you are right but, working for IBM for 11 years, I can tell you
that even IP based systems (such as Cisco firewalls) can sometimes create the same
type of havoc especially in data centers where you have to have 4 zones with
different levels of access/direction just to keep your internal network secure.
And, here’s my conclusion in very simple terms: IP is great. It
makes a lot of development efforts much easier: open a socket, send stream (or
datagram), do your processing and be done with it. But, saying that IP solves
all interoperability problems, to me, is a little premature until such time
that we have clearly identified system boundaries, the information model, functional
requirements, and non-functional requirements such as security, scalability,
bandwidth, etc.
Thanks again to all for your responses.
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: David RR Webber
(XML) [mailto:david@drrw.info]
Sent: Thursday, April 02, 2009 9:19 AM
To: Considine,Toby (Campus Services IT)
Cc: smartgrid-interest@lists.oasis-open.org
Subject: RE: [smartgrid-interest] What's wrong with having devices
communicate in their own native languages
Amen! A classic missive - think I'll print and frame.
Been in those similar trenches. IBM SNA over TCP/IP - oh
what fun. Two weeks of priority calls up and down the east coast with
IBMs top support staff - reboots, installs, reinstalls, patches - only to then
notice a $6 repeater was "lights out" behind the door in the machine
room...
-------- Original Message --------
Subject: [smartgrid-interest] What's wrong with having devices
communicate in their own native languages
From: "Considine, Toby (Campus Services IT)"
<Toby.Considine@unc.edu>
Date: Thu, April 02, 2009 10:41 am
To: "smartgrid-interest@lists.oasis-open.org"
<smartgrid-interest@lists.oasis-open.org>
http://www.w3.org/TR/REC-html40">
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…
"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
Chair, OASIS oBIX TC
Facilities Technology Office
University of North Carolina
Chapel Hill, NC
|
|
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?
********************************
********************************
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
---------------------------------------------------------------------
To unsubscribe, e-mail: smartgrid-interest-unsubscribe@lists.oasis-open.org For
additional commands, e-mail: smartgrid-interest-help@lists.oasis-open.org
|