There are two cases when we talk about coexistence of protocols: (i)
protocols that run on logically distinct networks and (ii) protocols
that run on the same network. In the former case, I agree that computing
MICs is the answer to keep the logically distinct networks separate, and
should not rely on a few defined bits in the message payload. Using MICs
is simply common sense when building a robust network. However, allowing
multiple protocols to coexist on the same network is an important notion
to keep when moving forward. LLC/SNAP allows different protocols to
coexist above 802.3 and 802.11. IPv4 networks rely on a some of these
protocols (e.g. ARP). While IPv6 has essentially moved ARP into ND,
there may be other (possibly yet unforeseen) cases where we want one or
more protocols operating directly on top of L2 to coexist with 6lowpan.
--
Jonathan Hui
[EMAIL PROTECTED]
Kris Pister wrote:
David – nice tutorial. That’s very helpful.
Regarding the dispatch discussion, I’m still concerned that this appears
to be leading people to draw the wrong conclusions, or worse, carry
forward the wrong assumptions.
Successful coexistence has nothing to do with the first two bits of the
network header. Any implementations that make that assumption are
doomed. Even if we could get the whole world to agree on dispatch
values, those bits (and others) are still going to get flipped
undetected every now and then between TX and RX. None of the
proprietary protocols and international standards with which I’ve been
associated have ignored the issue of coexistence. Quite the contrary,
we’ve spent countless hours in discussion and debate on the topic.
The conclusion is that without a message integrity check above and
beyond the 802.15.4 FCS, you’re doomed. With the CRC16, you can
probably get away with a 2 byte MIC, but 4 is safer and in any case
that’s what the 15.4 standard supports. So if you’ve got to have MIC,
then coexistence is simple. We can choose a default 6lowPAN key
(0x495056366F766572366C6F7750414E21 encodes “IPv6over6lowPAN” nicely in
128 bits J ), and unless someone intentionally uses that same key, then
the chances of 6lowPAN networks having coexistence problems with
SmartMesh or HART or sp100 (or zigbee with security turned on) are
effectively zero. The only coexistence problems then are for people who
**don’t** use a MIC (e.g. zigbee with security turned off), and the
problem is for them, not for us.
Once the MAC layer has signed off on the MIC, then your network layer
knows with confidence that this is in fact a valid packet, and **then**
it can look at the first two bits of the network header and do its job.
This seems really simple and obvious to me. Am I missing something?
ksjp
Kristofer S.J.Pister, Founder & CTO
Dust Networks, 30695 Huntwood Ave.
Hayward, CA 94544
510-548-DUST
------------------------------------------------------------------------
*From:* David Culler [mailto:[EMAIL PROTECTED]
*Sent:* Wednesday, May 30, 2007 4:39 PM
*To:* [email protected]; [EMAIL PROTECTED]
*Subject:* [6lowpan] Dispatch value bit pattern for 6lowPAN
Anthony,
There was a good bit of discussion on the partitioning of the
dispatch field following the San Diego meeting. Many felt that ideally,
the protocol identifier would have been carried in the 15.4 header, so
we were back filling. There was discussion about utilizing only a small
fraction of the initial dispatch address space, so there would be more
room for coexistence with other protocols. There was not a lot of
discussion about whether we could define the initial dispatch in such a
way that it would provide backward-going coexistence pre-existing
protocols, since none of the proprietary or industry forum protocols
seemed to have considered leaving room for others to fit alongside.
Perhaps the forward-going hope was that new efforts would at least live
along side of 6LoWPAN and all the protocols built on top of it.
------------------------------------------------------------------------
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
