[ell-i-developers] Re: Node management, discovery and such issues

  • From: Pekka Nikander <pekka.nikander@xxxxxx>
  • To: ell-i-developers@xxxxxxxxxxxxx
  • Date: Sat, 15 Feb 2014 19:31:07 +0200

> How close are we to have working network interface? Anyway we can
> and should discuss the generics a bit before jumping to producing
> code.

Well, just porting Contiki again, properly this time, would take probably a 
week of my time, i.e. 2-4 weeks of calendar time.  However, I don't think 
that's the right approach.

I'm planning now to start porting the old SPI code to the new runtime, then 
adding ENC28J60 Ethernet support.  If everything goes well, that should be up 
and running mid next week or so.

In parallel, we should now really think about how to implement TCP/IP or at 
least UDP/IP.  Contiki is one option, but the code is -- well -- not so nicely 
written.  It works, it produces relatively small binaries, but it is quite 
ugly.  LWIP is large what I've heard, and I haven't reviewed its source.  
Arduino Ethernet library is one option, but again I have no idea of its real 
code quality.  I believe there may be other possibilities as well, but those 
are the ones I've been considering.

Alternatively, we can write our own UDP/IP, and I believe that eventually we 
will.  The base ARP, IPv4, and UDP is quite easy, shouldn't take more than a 
few weeks.  IPv6 can be left for later.  What is harder is DHCP and any 
management protocols we may need.

Then, on the top of that, we should be able to adjust libcoap, which AFAIK is 
the best CoAP package at the moment:


However, I don't know how up-to-date it is, and it may still be better for us 
to write our own CoAP instead.

> In my view, we should have a two pronged approach on how a ELL-i
> network finds itself and determines network health.
> First, the nodes should have a means of finding other ELL-i nodes
> on an island network that is not connected to any other network.

Right.  For that we can use e.g. mDNS / Bonjour.  I believe CoAP also has such 
facilities, but I haven't had time to study the issue.  There most probably are 
also protocols in the HTML5 space for this, and we most likely want to go the 
CoAP/HTML5 way.

> This can be done with some existing broadcast-response protocol
> and works nicely in demo and lab environments. After this probing
> phase the nodes should somehow test if the others really are what
> they claim to be. I’m suspecting Pekka knows something of this
> as his name is attached to some possibly related protocols such
> as HIP.

I don't remember if HIP had any zero-configuration as such -- I guess others 
have been doing something in that space.  But I wouldn't worry about that still 
for some time.  

> We can make network discovery a bit easier by providing a cloud
> service so that a freshly installed node can as its first act
> "call home" and be told from that central control of its neighboring
> network configuration. After this the nodes can opt-out of central
> control and continue working without actual internet connection.

That's obviously one possibility.

> Anyway the ideas have been discussed at times at live meetups
> without documenting anything. I’m taking this mail to be a first
> step to approach some documented ideas about how our network
> configuration is discovered and then later on maintained and
> tracked.

Good opening.

One additional aspect we have that most others don't is also keeping track of 
the detail physical location of each node, i.e. where exactly they are within a 
building or other facility.


Other related posts: