On Mon, Aug 23, 2010 at 5:34 AM, Dmitry Eremin-Solenikov <[email protected]> wrote: > Hello, > > On Sun, Aug 22, 2010 at 3:13 PM, Jon Smirl <[email protected]> wrote: >> 6lowpan spec provides a clue on how to handle this: >> >> A short IEEE 802.15.4 address is 16 bits in length. Short addresses >> are mapped into the restricted space of IEEE EUI-64 addresses by >> setting the middle 16 bits to 0xfffe, the bottom 16 bits to the short >> address, and all other bits to zero. As a result, an IID generated >> from a short address has the form: >> >> 0000:00ff:fe00:XXXX > > IIRC there should be also PAN ID somewhere
6lowpan has decided to put the entire net on a single PAN ID. If you need more than 64K nodes use long addressing. Since everyone is on the same PAN ID the lower layers will know it via associating and can fill the packets in. Traversing the 65K node mesh is handled by RPL in IPv6. That doesn't mean you can't have multiple PANs, you just can't generate inter-PAN packets from IPv6. To have multiple PANs you need two gateways and two different IPv6 prefixes. You could also have PANs that are not IPv6 addressable. For example a FFD could be the PAN coordinator for a remote control. The FFD could be on both PANs (local one for remote and IPv6 one). I don't fully understand, but the Zigbee extended PAN IDs are even a bigger mess and they have been totally dropped from 6lowpan. I may not have all of this sorted out correctly. If there are issues we should ask the 802.15.4 experts on the 6lowpan list. > >> >> where XXXX carries the short address. The universal/local bit is >> zero to indicate local scope. >> >> If we convert the short addresses to this format for the upper layers >> will have a fixed address format. On transmit look for this pattern >> and then convert back to short address mode. struct ieee802154_addr >> can be eliminated and replaced with u8[ALEN]. > > While it's possible to have this in 6lowpan, it looks like a hack for me > from the generic IEEE 802.15.4 POV. The problem is the conditional structure supporting multiple address forms. There are a lot of places in the upper layers of the Linux networking code that aren't expecting a conditional field in the address structure. All of those places will have to be changed. For example all of the ip tools, ifconfig, netstat, arp, etc, etc... You'll have to do a parser than can handle the two forms of input and covert them into the condition address structure. It is way easier to leave those tools as is and do what 6lowpan did. We could add multiple interfaces, one for each PAN. But that still wouldn't allow you to send an inter-PAN packet. How are you going to figure out the address of the nodes that are reached via inter-PAN hops? You need to know the address to put it into a packet. > > > -- > With best wishes > Dmitry > -- Jon Smirl [email protected] ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Linux-zigbee-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
