In message <4e95c231.5030...@freedesktop.org> Jim Gettys writes: > On 10/11/2011 12:05 AM, Jari Arkko wrote: > > Home routers would also have MAC addresses, but again, if we need a > > 32-bit quantity then shortened 48/64 bit identifiers may > > (theoretically) have collisions. > > > > That being said, if the home routers have to discover their IPv6 > > prefix through a protocol and store it in flash, they could probably > > do so also for a router ID. Unless there was some chicken and egg > > problem that required the router ID for all this discovery to work... > As to storing in flash, since most in homenet have not typically worked > on embedded systems, worse luck... > > There is typically a read/write file system that can store state on a > current Linux home router (e.g. OpenWrt); it may or may not mapped over > the entire flash (which is desirable, as you'd like wear levelling to > use all blocks on the flash). > > The bulk of the firmware is likely contained in a read-only file system > called Squashfs, which does LZW compression on a per file basis; > overlayed on top may be a read/write file system. > > Most commonly the read/write file system has been a file system called > jffs2 over bare flash, originally implemented on the Compaq iPAQ > handheld, a project I helped lead after I got sick of HTTP. And OLPC > had a gigabyte of flash (which pushes jffs2 to/beyond it's design > limits). There are later flash file systems under development, but I > don't have first hand experience with any of them. > > Flash has the characteristic that write is relatively slow, and erase is > generally glacial. Most interesting flash file systems try to do lazy > erasure (erase freed blocks when they have a chance later, rather than > at the time you may free a file). > > Since you don't want to wear out the flash, the jffs2 does journaling; > one write will commit (potentially) a bunch of changes to multiple > files, rather than each write generating one write. > > How many writes you get depends on the flash technology, whether the > flash is "bare" or has some "smart" controller, and the wear levelling > technology (if any) in use, along with whether all blocks participate in > the wear levelling or not (jffs2 does good wear levelling; but using a > big squashfs file system + a very small jffs2 file system will reduce > the effectiveness; some cheap USB storage devices only do wear levelling > on the free blocks, and try to hide the fact it is flash from the system > above. I put "smart" in quotes, because they've often been hideously > stupid, with their smarts limited to looking like IDE with a very lame > flash translation layer. The most recent "smart" flash disks for > laptops are actually getting very smart, with some help from the OS to > help with the erasure problem. But they still cost substantially more, > I suspect. > > I think most home routers currently use bare flash, though it's not > clear to me if this will continue or not since the volume market may > make the economics change. > > In any case, with flash of any sort, you don't want to sit there and > demand to do lots of periodic writes (on Linux/UNIX you'd mount -atime, > for example). > > All this being said, storing state at the rate of machines/routers > appearing or disappearing on a home network, or your ISP going down, > isn't likely to cause a problem. You just have to be careful enough to > not do anything really stupid; e.g. you map daemons with chatty logs to > run their logs to /dev/null, or to tempfs in RAM. And you might take a > big latency hit if you have to guarantee the write is stable before > continuing an algorithm (if you run into needing to erase a block for > some reason). And obviously you don't write tons of data when you don't > half to. And update in place may be a bad idea relative to other > techniques (which is why journaling file systems such as jffs2 are so > desirable). > > - Jim
Jim, Nice reminder on the limitations of flash and some of the workarounds. Some neat hardware does erase on write and buffers the write itself, and can store enough energy in a small battery to flush the writes on power down. Its faster and maximized flash life. Its essentially a RAM front ended flash. I think it was expensive for consumer use. For provider equipement it makes logging to flash feasible thereby avoiding spinning media which may object to a 65 C ambient. Routing protocols are even less stateful than DHCP in this regard. There is no "lease" to be preserved between boots. The configuration (today in non-zero-config situations) is not sufficiently immuatable to put in a squashfs but may not be changed for months or years. Any old filesystem over bare flash is OK for that. Everthing else in a routing protocol is acquired at run time and therefore should be in RAM (ramfs or in application space RAM). With a zero config routing protocol at worst there would be a small amount of information that would generally be updated only once if at all on a reboot. Using a random number for router ID and remembering it across reboots and supporting a router ID collision repair would support this, since the collision on reboot would be rare even if the router was moved within the topology. If the router ID was not tied to an address it would not have to change when moved within the topology. Even the interesting problem of moving a router wire by wire would work. The adjacency and any address allocation acquired over it would be lost with each wire pulled. When plugged in elsewhere, new addressing would be needed and it would bring up a new adjacency or set of adjacencies (or more correctly participate in DR election and adjacency with the DR and BDR if there was a dumb switch in there and it were a true BCAST subnet). An interesting observation is that two addresses can be requested if the DR election is among two parties and after election it is apparent that they are the only two. If a third is added it is not a point to point link and a larger block can be requested. Curtis _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
