Date: Mon, 08 Dec 97 21:55:13 -0500 From: Brad Karp <karp@eecs.harvard.edu> To: Charles Mott <cmott@srv.net> Cc: pst@shockwave.com, freebsd-hackers@freebsd.org, karp@dominator.eecs.harvard.edu Subject: Re: FreeBSD Metricom driver: I wrote one in September... Message-ID: <199712090255.VAA28659@dominator.eecs.harvard.edu> In-Reply-To: Your message of "Sun, 07 Dec 97 20:44:06 MST." <Pine.BSF.3.96.971207203729.21220B-100000@darkstar.home>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Charles. About your questions: > I'd be curious to hear how your IP-MAC mapping works. Is it some sort of > stochastic token passing between neighbors? To what size networks can it > scale? Metricom radios have unique hardware addresses, much as Ethernet cards do. But they don't let users broadcast packets. My driver receives neighbor acquisition reports from the radio (provided by the radio hardware, using a protocol done by the radios that you can't change and don't see), and uses them to query neighbors (via unicast) for their IP and MAC addresses (providing the remote node with its own mapping at the same time). Each node builds a table of the IP->MAC mappings in this way. This architecture scales well, as mapping entries can be cached for arbitrarily long periods (they're replaced by any newly arrived conflicting entries, just like ARP entries for Ethernet are). So the overall message rate for maintaining _one node's_ table is quite low--it is O(the rate of new neighbor acquisition events). Because reachability is a property of individual node pairs, and the Metricom medium doesn't support broadcast, I see no way to avoid per-neighbor request/response pairs for acquiring immediate neigbhors' IP->MAC mappings. A centralized ARP server (what Stanford's Metricom driver uses) reduces the total message cost when a network is densely connected (i.e., most nodes can directly reach most others as neighbors), but results in network partition when a network is sparsely connected (i.e., there's a multi-hop path between nodes not in direct, single-hop range of one another, such that no central ARP server can be in direct range of all mobile nodes). In this latter case, non-centralized neighbor discovery (with its message cost) is essential, so that a higher-layer (e.g., IP routing) mechanism can provide multi-hop reachability. Another fact: Metricom's hardware itself can only track 400 neighbors, and that limit of theirs (as well as the cost of the low-level hardware's neighbor acquisition protocol) would be limiting long before my ARP protocol would be. > Some obscure questions, since you've seriously worked with the metricom > hardware: how intrinsically doppler tolerant is the communications > waveform? What modulation scheme? What chip rate? Metricom is very close-chested about the low-level details of the radio hardware, I'm afraid. Beyond the facts that they're a crude form of spread spectrum (i.e., frequency hopping, but way simpler and less robust than CDMA), that the theoretical max rate is 100 Kbps (unidirectional, without overhead for switching direction for ACKs), that they're half-duplex, that they use the unlicensed 900 MHz band, and a bit about the slot times and band widths in their frequency hopping scheme, I know nothing. If by doppler-tolerant you mean robust in the face of motion, I have used their radios in a car moving at ~20 mph with no noticeable throughput reduction, so long as a I remained within range of my peer. Metricom's radios are pretty much bimodal in signal quality: you're in-range and doing well, or out-of-range and getting nothing, in my experience (which their engineers have commented on as typical). I hope these answers are useful; please let me know if you have further questions, or if I've not answered the question you intended to ask. :-) -Brad, karp@eecs.harvard.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712090255.VAA28659>