Subject: Re: Looking ahead
To: Ivo Vachkov <email@example.com>
From: Allen Briggs <firstname.lastname@example.org>
Date: 06/06/2007 22:58:17
On Wed, Jun 06, 2007 at 05:14:36PM +0300, Ivo Vachkov wrote:
> I'll define it this way. In embedded systems you usually have two
> types of systems that require network capabilities. Those that use the
> network for transport data (client devices) and those that make sure
> others can transport data (infrastructure devices - switches, routers,
> etc). This, of course, is not absolute. And
> 1) tiny would be a network stack that includes protocols that are
> mostly used: ARP, IP, ICMP, UDP, TCP, etc. Probably routing and packet
> filtering will be here too.
> 2) full would include in addition to those IPv6, IPSec, SCTP, advanced
> firewalling, policy-based routing, etc.
OK. Thanks for that definition. I would actually have divided it a
little differently. I tend to think of sort of four different types:
1) Devices with a network connection for control (perhaps
a weather station or similar)
2) Devices that want to move a lot of data (perhaps a
3) Devices that need to route / bridge networks (perhaps
a wireless access point), and
4) Infrastructure types of devices.
Especially with #2 - #4, there are a bunch of different sizes of
devices with a number of different protocol needs. And the boundaries
are certainly blurred in some cases--especially #2 & #3. In general,
I think there's probably a reasonable need for:
1) ARP/IP/ICMP/UDP/TCP (& maybe IPV6/ICMP6 soon?)
2) 1 + IPSec
3) 1 + filtering & routing
4) 1 + policy routing
And various combinations. Which is kind of what we have now with
options, but with the options stripped, our stack is not really
"tiny"--although perhaps better when routing is ripped out.
> Consider the following situation: you have built an image with the OS
> and tools you need. Several months later you find that now you need
> tcpdump or tcpblast or vndconfig or what so ever you missed before.
Fair enough. Thanks for articulating that.
> >> * mesh routing protocol implementations
> >What protocols? References?
That's a LOT of stuff. I think it would be best for folks who are
more familiar with that space to suggest a path for which protocols
make sense for various applications. I don't see a need to be fully
FLAC (Four-Letter Acronym Compliant).
> >> * sensor support
> This is more like a pure design. A stable API with a formal language
> (or just a way) to describe what kind of data is expected from the
> sensors will be good starting point to run NetBSD as a node in
> industrial installations.
> Close to the one above. If NetBSD can offer API or framework for
> drivers and control mechanisms for robots you can expect interest on
> using it in that area too. Yes, NetBSD supports the CPU, but it's not
> the only component in a modern robot. Microsoft started this with
> Robotics Studio. And now several manufacturers support them.
I'm not sure that I'd want to use NetBSD for robotic control without
some more real-time "guarantees". But I suppose there are some
places where that's less of a concern as we're "good enough".
Again, are there existing designs for sensor / control that would
make sense to implement or adopt? Or is this a case where there's
a void and you're suggesting that it be filled? Do you have interest
in looking into this?
Thanks again for the informative reply,
Allen Briggs | http://www.ninthwonder.com/~briggs/ | email@example.com