Re: [homenet] Capabilities of small devices

[Michael Richardson]

Ralph Droms  wrote:
>> No, the point is that right now if you just take a bunch of IPv4 nat
>> routers and plug them together, they work, because they're all
>> translating.

> Depends on how you plug them together.  They will also work correctly
> as bridges if plugged together correctly, too.  By enabling spanning
> tree bridging or waiting for SPF bridging, those devices could be
> plugged together randomly and still work.

They won't (in the sense that all computers won't be able to print to all
printers, while simultaneously unless you also turn off the multiple DHCPv4
servers.

But, we went through this two (or was it three) years ago.

--
Michael Richardson , Sandelman Software Works




pgp3cvLbNSpHi.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Capabilities of small devices

[Jim Gettys]

On Wed, Aug 14, 2013 at 11:20 AM, Michael Thomas  wrote:

> On 08/14/2013 08:03 AM, Jim Gettys wrote:
>
>>
>> The one I've measured consumes of order 5W, IIRC (WNRD3700v2).  As noted,
>> this is a 600Mhz SOC MIPS architecture (Atheros).  This is now about 2
>> years old: more recent routers are yet higher performance. Relative to what
>> you are used to on a desktop, the biggest performance differences are
>> caused by having a small cache (making many interpreted languages
>> relatively slow).  Even so, it's much faster than most desktops/servers
>> were not all that long ago, for integer codes.
>>
>> I believe the power consumption is often dominated by the 1G ethernet
>> ports; a 1ghz SOC is only around 1W power consumption.  Each ethernet port
>> can consume significant power.  If you use a USB port, it can also consume
>> power (up to 2W).
>>
>> The WiFi may account for a watt or so of the consumption (it turns out
>> that transmit and receive typically consume comparable amounts of power;
>> the transmit power isn't significant relative to the power consumed by the
>> signal processing that is done on receive).  The WiFi devices in handheld
>> devices may be somewhat more efficient (but also poorer performance: it
>> pays to have a good radio in the router, where power is easy to come by.).
>>
>>
> Thanks for the stats, Jim. Having worked on both iphone and android apps,
> it is
> *maddeningly* difficult to be a good battery citizen. There is no
> instrumentation
> last I looked to determine things like "If you transmit n bytes, typical
> battery use
> will be m mw at distance X" or "if you turn on this sensor at rate x, you
> can expect
> it to consume y mw", etc. I wish the Google and Apple would do something
> more
> than just being a scold ("don't use those features!") and forcing
> developers to put
> inane disclaimers in their product descriptions. If they really wanted good
> battery performance, they'd provide the OS level reporting that is
> necessary to
> make good decisions. Like, oh say, "Golly it takes a lot of juice to get
> to that tower,
> maybe I'll back off!"
>
> And of course this isn't just phones, it's anything with a battery.
>
>
My knowledge of power consumption is a bit dated on WiFi: I had to live and
breathe power consumption on battery devices when working on OLPC 5-6 years
ago.  It may be considerably lower at this date (probably is) on WiFi
devices used primarily for handhelds. Someone with current data would be
helpful to chime in here.

On the OLPC, we had a autonomous processor (a very low power ARM 9, IIRC),
four packet buffers, and the device could forward packets in the mesh
network without requiring the main processor to be involved at all. That
module consumed somewhere between .5 and 1W, IIRC.  Actual numbers are
someplace in the OLPC Wiki...  Transmit & receive power were roughly
comparable.

The big headache about WiFi is the current need to leave the receiver
powered up (taking the signal processing power hit).  And, of course,
most handhelds don't have another CPU to do the packet forwarding (so you'd
need to wake up the CPU to forward any packets).  It ought to be the case
that you'd not have to listen at all times (and I think there are
unimplemented 802.11 features to do so), but in practice, the last I knew,
you had to always be listening, so the power consumption was continuous.

The other major headache is trying to reduce unnecessary wakeups to the
main CPU (and when you do, take care of as much business as you can).
 IIRC, we got the wakeup rate down to order of 10's/second. I know Linux
has improved quite a bit in this area over this period; dunno what the
current state of the art is.
 - Jim





> __**_
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/**listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Capabilities of small devices

[Jim Gettys]

On Mon, Aug 12, 2013 at 5:40 AM, Mikael Abrahamsson wrote:

> On Mon, 12 Aug 2013, Teco Boot wrote:
>
>  Joel Jaeggli mentioned the forwarding performance. Today's homenets are
>> mainly single subnet with link-speed forwarding between (gig) ethernet
>> ports, in hardware. L3 forwarding in software with single uplink or WiFi
>> port at near to gig speed is doable. Forwarding in software on all ports
>> require a new generation of low power and cheap CPU, I think. So probably
>> use hardware forwarding as much as possible?
>>
>
> Hardware assisted forwarding might be problematic due to us deciding on
> new functionality (source based routing for instance). I've read that in
> some routers the forwarding is done by microcode implemented by the
> hardware manufacturer, hindering the integrator (who buys the SoC in bulk)
> from doing what might be needed.
>
> So yes, forwarding performance is a concern, at least when we're talking
> above 100 megabit/s.
>

Actually, I think (Dave Taht can tell us with data), that forwarding
performance is fine even on today's routers up to 300-400Mbps on the
WNDR3800 running CeroWrt (which routes, rather than bridging between
interfaces)..  The 600Mhz MIPS can't saturate a gigabit ethernet, however
(at least not without using lots of hardware offload on the ethernet
controller, which hurts latency and creates
other problems (packet bursts).

But as SOC's are increasing in speed while the price goes down...

>
> I also think it would be beneficial if we could figure out as soon as
> possible what the requirements are on the forwarding plane, writing this
> down, so that hardware designers can avoid putting functionality into
> hardware that won't do what we need going fo
> r
> ward.


Hardware "assists", e.g. TSO, and GSO, are a problem, particularly in the
home.  You don't want line rate bursts going onto your WiFi (though
fq_codel helps that quite a bit, it's still evil).


>
>
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se
> __**_
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/**listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Capabilities of small devices

[Dave Taht]

oh, no, forwarding rates are not very good. I have a bunch of numbers on
forwarding rates on the wndr3800 stuff, at best it's half that for routing
rather than bridging. I can give you current pps or bytes/sec, but not
right now. (felix just did a ton of tuning in this area). Bridging
outperforms routing by like 6x1.

Add in firewall rules or nat, or a software rate limiter, and you are well
below 100Mbit for forwarding rates over the ethernet on that particular box.

It's not the SOC per se' that's the issue, it's the tiny caches (vs, like,
um, ivy bridge), and the (generally 16 bit single channel) pretty slow
memory interfaces common in these platforms, as well as MIP's general
decrepitude.




On Wed, Aug 14, 2013 at 8:13 AM, Jim Gettys  wrote:

>
>
>
> On Mon, Aug 12, 2013 at 5:40 AM, Mikael Abrahamsson wrote:
>
>> On Mon, 12 Aug 2013, Teco Boot wrote:
>>
>>  Joel Jaeggli mentioned the forwarding performance. Today's homenets are
>>> mainly single subnet with link-speed forwarding between (gig) ethernet
>>> ports, in hardware. L3 forwarding in software with single uplink or WiFi
>>> port at near to gig speed is doable. Forwarding in software on all ports
>>> require a new generation of low power and cheap CPU, I think. So probably
>>> use hardware forwarding as much as possible?
>>>
>>
>> Hardware assisted forwarding might be problematic due to us deciding on
>> new functionality (source based routing for instance). I've read that in
>> some routers the forwarding is done by microcode implemented by the
>> hardware manufacturer, hindering the integrator (who buys the SoC in bulk)
>> from doing what might be needed.
>>
>> So yes, forwarding performance is a concern, at least when we're talking
>> above 100 megabit/s.
>>
>
> Actually, I think (Dave Taht can tell us with data), that forwarding
> performance is fine even on today's routers up to 300-400Mbps on the
> WNDR3800 running CeroWrt (which routes, rather than bridging between
> interfaces)..  The 600Mhz MIPS can't saturate a gigabit ethernet, however
> (at least not without using lots of hardware offload on the ethernet
> controller, which hurts latency and creates
> other problems (packet bursts).
>
> But as SOC's are increasing in speed while the price goes down...
>
>>
>> I also think it would be beneficial if we could figure out as soon as
>> possible what the requirements are on the forwarding plane, writing this
>> down, so that hardware designers can avoid putting functionality into
>> hardware that won't do what we need going fo
>> r
>> ward.
>
>
> Hardware "assists", e.g. TSO, and GSO, are a problem, particularly in the
> home.  You don't want line rate bursts going onto your WiFi (though
> fq_codel helps that quite a bit, it's still evil).
>
>>
>>
>> --
>> Mikael Abrahamssonemail: swm...@swm.pp.se
>> __**_
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/**listinfo/homenet
>>
>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
>


-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Capabilities of small devices

[Jim Gettys]

On Mon, Aug 12, 2013 at 10:44 AM, Howard, Lee wrote:

>
>
> On 8/12/13 7:03 AM, "Henning Rogge" 
> wrote:
>
> >On 08/12/2013 11:40 AM, Mikael Abrahamsson wrote:
> >> On Mon, 12 Aug 2013, Teco Boot wrote:
> >>
> >>> Joel Jaeggli mentioned the forwarding performance. Today's homenets
> >>> are mainly single subnet with link-speed forwarding between (gig)
> >>> ethernet ports, in hardware. L3 forwarding in software with single
> >>> uplink or WiFi port at near to gig speed is doable. Forwarding in
> >>> software on all ports require a new generation of low power and cheap
> >>> CPU, I think. So probably use hardware forwarding as much as possible?
> >>
> >> Hardware assisted forwarding might be problematic due to us deciding on
> >> new functionality (source based routing for instance). I've read that in
> >> some routers the forwarding is done by microcode implemented by the
> >> hardware manufacturer, hindering the integrator (who buys the SoC in
> >> bulk) from doing what might be needed.
> >>
> >> So yes, forwarding performance is a concern, at least when we're talking
> >> above 100 megabit/s.
> >>
> >> I also think it would be beneficial if we could figure out as soon as
> >> possible what the requirements are on the forwarding plane, writing this
> >> down, so that hardware designers can avoid putting functionality into
> >> hardware that won't do what we need going forward.
> >
> >I agree, software forwarding should be the standard way. That makes it
> >also more easy to adapt different routing protocols to HOMENET.
>
>
> You guys are trying to hard to engineer products.  Figure out what it
> should do and how, and let implementers implement it.  If you need
> implementers to tell you how to do it, let's get more of them in here.
>

Yup.  People here should have a bit of faith in Moore's law.   These are
real computers, and nothing I've seen is very difficult.

 And most of this stuff is already running fine in OpenWrt/CeroWrt as
existence proof of viability.

I do urge everyone to get their hands dirty, of course.

Then you'd be discovering things like:
   1) to deploy DNSSEC, you need to securely get time at boot time from the
network.
   2) to deploy DNSSEC, you need enough randomness in the entropy pool to
generate the self-signed certs when you do the initial installation.

(both these examples are very real, and Homenet should ensure these get
fixed).

Rather than worrying so much about whether the routers can do what you
need, you'll be finding the real issues that need to be solved.
- Jim


> Lee
>
>
>
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Capabilities of small devices

[Howard, Lee]

From: Jim Gettys mailto:j...@freedesktop.org>>
Date: Wednesday, August 14, 2013 11:03 AM
To: Brian Carpenter 
mailto:brian.e.carpen...@gmail.com>>
However, today's devices are overwhelmingly battery-powered, so even
if compute power and memory are not the issues, electricity matters.

Your home router is not battery powered (except for if you run it off a battery 
back up system).


This is true, but I believe this thread started as a discussion of the 
capabilities of devices that aren't what we currently think of as "The home 
router" but still have routing functions, or have other interactions with 
Homenet which might be constrained.  When specifying protocols for 
interoperability, the most-constrained device determines the capabilities.

Lee


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Capabilities of small devices

[Jim Gettys]

On Mon, Aug 12, 2013 at 4:44 AM, Mikael Abrahamsson wrote:

> On Mon, 12 Aug 2013, Henning Rogge wrote:
>
>  Personally I like the way CODEC WG approached this, by making a
>>> reference implementation available in source code in the standard. This
>>> is probably not practical for a complete homenet router,
>>>
>>
>> Why? A "homenet" package (most likely multiple packages) for OpenWRT as a
>> reference implementation would be a great thing.
>>
>
> Well, I meant publishing the source code in the RFC text. I believe *WRT
> style implementation freely available is a great idea of course.
>
>
>  And it might give consumers the chance to get a router with a reasonable
>> modern linux.
>>
>
> Exactly. I'm running CeroWRT on a WNDR3800 that I bought refurbished for
> 70USD. My hope is that in a few years when homenet is "done" this kind of
> device will be generally available at a lower price point new and available
> to everyone.
> 
>
>
The 3800 costs what it does in part due to having two radios (2.4 and
5ghz).  A single radio router would be cheaper (but not interesting for a
mesh network, due to 1/N performance with number of hops).


> --
> Mikael Abrahamssonemail: swm...@swm.pp.se
> __**_
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/**listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Capabilities of small devices

[Jim Gettys]

On Thu, Aug 8, 2013 at 4:54 PM, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:

> On 09/08/2013 01:21, Olafur Gudmundsson wrote:
>
> > Moral: do not constrain homenet requirements by yesterdays devices.
>
> Fair enough (after all, the IPv6 design is great for an end-of-era
> minicomputer).
>
> However, today's devices are overwhelmingly battery-powered, so even
> if compute power and memory are not the issues, electricity matters.
>

Your home router is not battery powered (except for if you run it off a
battery back up system).

The one I've measured consumes of order 5W, IIRC (WNRD3700v2).  As noted,
this is a 600Mhz SOC MIPS architecture (Atheros).  This is now about 2
years old: more recent routers are yet higher performance. Relative to what
you are used to on a desktop, the biggest performance differences are
caused by having a small cache (making many interpreted languages
relatively slow).  Even so, it's much faster than most desktops/servers
were not all that long ago, for integer codes.

I believe the power consumption is often dominated by the 1G ethernet
ports; a 1ghz SOC is only around 1W power consumption.  Each ethernet port
can consume significant power.  If you use a USB port, it can also consume
power (up to 2W).

The WiFi may account for a watt or so of the consumption (it turns out that
transmit and receive typically consume comparable amounts of power; the
transmit power isn't significant relative to the power consumed by the
signal processing that is done on receive).  The WiFi devices in handheld
devices may be somewhat more efficient (but also poorer performance: it
pays to have a good radio in the router, where power is easy to come by.).

- Jim





>Brian
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Capabilities of small devices

[Henning Rogge]

On 08/12/2013 11:40 AM, Mikael Abrahamsson wrote:

On Mon, 12 Aug 2013, Teco Boot wrote:


Joel Jaeggli mentioned the forwarding performance. Today's homenets
are mainly single subnet with link-speed forwarding between (gig)
ethernet ports, in hardware. L3 forwarding in software with single
uplink or WiFi port at near to gig speed is doable. Forwarding in
software on all ports require a new generation of low power and cheap
CPU, I think. So probably use hardware forwarding as much as possible?


Hardware assisted forwarding might be problematic due to us deciding on
new functionality (source based routing for instance). I've read that in
some routers the forwarding is done by microcode implemented by the
hardware manufacturer, hindering the integrator (who buys the SoC in
bulk) from doing what might be needed.

So yes, forwarding performance is a concern, at least when we're talking
above 100 megabit/s.

I also think it would be beneficial if we could figure out as soon as
possible what the requirements are on the forwarding plane, writing this
down, so that hardware designers can avoid putting functionality into
hardware that won't do what we need going forward.


I agree, software forwarding should be the standard way. That makes it 
also more easy to adapt different routing protocols to HOMENET.


Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:henning.ro...@fkie.fraunhofer.de http://www.fkie.fraunhofer.de



smime.p7s
Description: S/MIME Cryptographic Signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Capabilities of small devices

[Henning Rogge]

On 08/12/2013 09:49 AM, Mikael Abrahamsson wrote:

On Mon, 12 Aug 2013, Henning Rogge wrote:


Many current home-routers have 32 MB RAM (some have more), some more
"expensive" ones (40$ and more) also upgrade the flash to 8 or 16 MB.


How much of this cost increase is due to the flash and RAM, and how much
is due to more expensive other components plus the software development
effort to perhaps drive additional features these more expensive devices
bring?


How much of it is just "hey, this is the improved version"? We don't know.

For 80$ you already get routers with 8 MB flash and 128 MB ram.


Personally I like the way CODEC WG approached this, by making a
reference implementation available in source code in the standard. This
is probably not practical for a complete homenet router,


Why? A "homenet" package (most likely multiple packages) for OpenWRT as 
a reference implementation would be a great thing.



but at least my
hope is that there will be freely available code that implementers can
use so that just like they don't have to spend time to develop the linux
kernel they're running on their devices, they don't have to develop (or
buy) the routing control plane code (or forwarding for that matter),
because it's already available.


And it might give consumers the chance to get a router with a reasonable 
modern linux.


Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:henning.ro...@fkie.fraunhofer.de http://www.fkie.fraunhofer.de



smime.p7s
Description: S/MIME Cryptographic Signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Capabilities of small devices

[Henning Rogge]

On 08/12/2013 01:54 AM, Juliusz Chroboczek wrote:

A more important factor is the size of the memory on the devices,
a box with 8MB memory will have problem with running many services,
but many boxes sold today have 32-128MB memory (both NVRAM and RAM)


An additional point is that all home routers sold in the last 10 years
or so have enough RAM to perform stateful NAT for hundreds of
connections.  Anything that can do stateful NAT can do IPv6 and
link-state routing without effort.

The community mesh networking community (ahem) has a lot of experience
with cheap boxes.  Henning will correct me if I'm wrong, but as far as
I am aware,

   - no box sold in the last few years has RAM issues (kernel+v4+v6+well
 implemented routing daemon fit in 32 Megs with plenty to spare);
   - some older boxes lack flash, this is not an issue on recent boxes;
   - some popular cheap boxes used to have power supply issues
 (overheating and crashing under load).

As flash and RAM keep getting cheaper, I expect the power supply to
increasingly become the main problematic component.


Older (and cheap) home-routers had typically 4 MB flash and 16 MB RAM. 
You can run a dualstack router with routing protocol on this, but you 
have to be a bit careful not to overdo bloated additional software.


Many current home-routers have 32 MB RAM (some have more), some more 
"expensive" ones (40$ and more) also upgrade the flash to 8 or 16 MB.


Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:henning.ro...@fkie.fraunhofer.de http://www.fkie.fraunhofer.de



smime.p7s
Description: S/MIME Cryptographic Signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Capabilities of small devices

[Robert Cragie]

OK, IIRC this was with respect to the routing protocol and I agree 
regarding that point. However, this is a discussion about capabilities 
of home routers.


Robert

On 09/08/2013 11:44, Acee Lindem wrote:

Early on in this WG, we said the ROLL domain would connect to the homenet but 
not replace it.
Acee
On Aug 9, 2013, at 4:15 AM, Robert Cragie wrote:


Yes, but who's to say a light bulb won't be a home router? 6LoWPAN ND and RPL 
introduce the the concept of 6LRs and RPL Routers respectively, which are 
generally small devices (i.e. around the figures Frank mentions below) with a 
single wireless network interface.

These devices rarely seem to be considered in the homenet WG but will surely be 
part of a home network.

Robert

On 09/08/2013 03:11, Ted Lemon wrote:

On Aug 8, 2013, at 9:49 PM, Hartog, F.T.H. (Frank) den  
wrote:

At the same time, new and much smaller devices are introduced in the home. E.g. light 
bulbs (or rather LEDs nowadays) with IPv6 capability on a 256 kB - 32 MHz chip. Maybe we 
should define a baseline definition of what we mean with "small device" anno 
2013 to frame the homenet arch discussions and documents. Regards, Frank.

Do bear in mind that Olafur is talking about home routers here, not lightbulbs.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet






smime.p7s
Description: S/MIME Cryptographic Signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Capabilities of small devices

[Robert Cragie]

Yes, but who's to say a light bulb won't be a home router? 6LoWPAN ND 
and RPL introduce the the concept of 6LRs and RPL Routers respectively, 
which are generally small devices (i.e. around the figures Frank 
mentions below) with a single wireless network interface.


These devices rarely seem to be considered in the homenet WG but will 
surely be part of a home network.


Robert

On 09/08/2013 03:11, Ted Lemon wrote:

On Aug 8, 2013, at 9:49 PM, Hartog, F.T.H. (Frank) den  
wrote:

At the same time, new and much smaller devices are introduced in the home. E.g. light 
bulbs (or rather LEDs nowadays) with IPv6 capability on a 256 kB - 32 MHz chip. Maybe we 
should define a baseline definition of what we mean with "small device" anno 
2013 to frame the homenet arch discussions and documents. Regards, Frank.

Do bear in mind that Olafur is talking about home routers here, not lightbulbs.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet






smime.p7s
Description: S/MIME Cryptographic Signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Capabilities of small devices

[Henning Rogge]

On 08/09/2013 04:11 AM, Ted Lemon wrote:

On Aug 8, 2013, at 9:49 PM, Hartog, F.T.H. (Frank) den  
wrote:

At the same time, new and much smaller devices are introduced in the home. E.g. light 
bulbs (or rather LEDs nowadays) with IPv6 capability on a 256 kB - 32 MHz chip. Maybe we 
should define a baseline definition of what we mean with "small device" anno 
2013 to frame the homenet arch discussions and documents. Regards, Frank.


Do bear in mind that Olafur is talking about home routers here, not lightbulbs.


From a RAM/CPU perspective no current home routers should have a 
problem with IPv6. Its just that some manufacturers don't integrate the 
necessary components into their basic firmware.


I think IPv6 support should be mandatory for Homenet routers. Maybe they 
won't have an uplink to the Internet with IPv6, maybe they have some 
attached devices without IPv6, but the software on the core Homenet 
routers should have access to IPv6.


Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:henning.ro...@fkie.fraunhofer.de http://www.fkie.fraunhofer.de



smime.p7s
Description: S/MIME Cryptographic Signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet