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

FYI: An article I just read = Brent

 

6LoWPAN Goes Where ZigBee Can't

An IP-based protocol puts sensor
applications on the Internet.

by Jon Titus, Senior Technical Editor

 
 
Many “standard” and proprietary protocols
use the media-access controller (MAC) and the physical circuits (PHY)
associated with IEEE 802.15.4 radios. Those protocols use their own
arrangements of bits and bytes to transfer information between nodes, but none
of them use the Internet Protocol (IP). So they cannot directly communicate
with Internet-based devices and Web servers/browsers. The IPv6 over Low power
Wireless Personal Area Networks (6LoWPAN) standard offers an alternative
because it employs the IPv6 protocol and can operate equally well over wireless
and wired connections.

To find out more about 6LowPAN, I talked with Geoff Mulligan, the chairman
of the IP for Smart Objects (IPSO) Alliance and 6LoWPAN Working Group Chair.
"When I worked for Invensys, we started a project to put wireless IPv6
communications in smoke alarms and appliances. The header and address
information for IPv6 amounts to 40 bytes. But the 802.15.4 packets have only
127 bytes, so IPv6 would take much of the available space. Some bright
engineers came up with the idea of compressing the IPv6 header information so
it needs only three or four bytes on average."

 
 
The
compression is completely stateless, which means that it creates no binding
state between the compressor-decompressor pair. Stateless compression gives
nodes the flexibility to communicate with any neighbor in compact form at all
times.(Ref 1.) In addition, the stateless compression gives a network multiple
entry and exit points, whereas a "stateful" network is susceptible to
single-point failures.

 

"As a result of stateless compression, the 6LoWPAN community has software
'stacks' that require less RAM and ROM than a ZigBee stack, for example,"
added Mulligan. "Instead of having a monolithic header, you only add the
bits and bytes you need for, say, fragmentation or mesh routing. If you don't
need those capabilities, the packet doesn't carry that type of information,
thus reducing the overhead."

The Internet Engineering Task Force (IETF) oversees the 6LoWPAN
standardization and specification work under Request for Comments (RFC) 4944.
The specifications are open and developers can buy 6LoWPAN code, use
open-source code, or write their own. But 6LoWPAN communications don't require
a complete rewrite of an IEEE 802.15.4 radio stack. Instead, 6LoWPAN adds an
adaptation layer that lets the radio stack and IPv6 communications operate
together. 

"The beauty of 6LoWPAN communications is that they let people
communicate with devices across the Internet without having to go through, say,
a ZigBee-to-IP translation step," explained Mulligan. "If they have a
network of sensors in Antarctica the Internet will connect them directly to it.
When the sensor bridge-network connects to Internet, it 're-inflates' the
compressed headers and puts back all the needed IPv6 information."

The lack of gateways that translate protocols also improves end-to-end
communication security. If you use a gateway to connect a proprietary network
to the Internet, you have two security "spheres;" one for the
Internet and one for the proprietary network. That arrangement provides a
potential point of attack that could destroy the integrity of the end-to-end
link.

"Work on the 6LoWPAN specifications continues," stressed Mulligan.
"Engineers are working to answer questions such as how do users commission
a network and how do they establish good security so their network doesn't
connect to a neighbor’s network?"

The 6LoWPAN hardware relies on the IEEE 802.15.4 radio-communication
standard and although IPv6 is relatively new, the Internet Protocol has over 30
years of history behind it. So, 6LoWPAN equipment should not encounter any
problems with the other type of IP--intellectual property. Large companies such
as IBM, Sun, Cisco, and Microsoft have invested heavily in IP-based
communications and would not have done so unless the believed the IP had no
hidden patent liabilities.  Unfortunately, proprietary or emerging network
hardware and software standards might run up against existing patents that
engineers have yet to uncover.

Companies offer development kits that can help developers kick start a
6LoWPAN project or just investigate its capabilities. Sensinode (www.sensinode.com) offers a K210 6LoWPAN
Devkit and Atmel (www.atmel.com) provides
its 2.4 GHz Evaluation and Starter Kit (ATAVRRZRAVEN) that runs a port of the
Contiki 2.2.2 OS, which contains the small uIPv6 stack and SICSlowpan
802.15.4-over-IPv6 compression (http://www.sics.se/contiki).
Arch Rock (www.archrock.com) has a
PhyNet OEM Development Kit (IE version) that comes configured with the PhyNet
IE Engine that lets developers use direct C API calls to the Arch Rock
IP/6LoWPAN linkable kernel library to access operating-system services and
standard TCP/UDP/IP-based networks. Jennic (www.jennic.com)
also offers a 6LoWPAN Network Protocol stack that operates with the company's
JN5139 wireless microcontrollers and modules.

If 6LoWPAN sounds interesting, but you have a ZigBee or other 802.15.4
project in the works you can still implement 6LoWPAN communications later. Just
ensure you can "reflash" your firmware in the field so it can accept
code for a 6LoWPAN stack. According to Mulligan, at least one utility company
will take this approach with its first meter-reading equipment.  

 

 

From: Edward Koch
[mailto:] 

Sent: Thursday, April 02, 2009 10:14 AM

To: Considine, Toby (Campus Services IT);


Subject: [smartgrid-interest] RE: What's wrong with having devices
communicate in their own native 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:] 

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

To: 

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