What Kris was proposing achieves the goals of both (i) and (ii) networks. The MIC has become a standard parameter for a variety of different networking standards. By including it at layer 2, you're promoting co-existence with other protocols of the same layer 2 implementation while permitting flexibility in the network protocol selection (pick from the alphabet soup of IPv6, SP100.11a, Zigbee Pro, or Wireless HART).
Quite frankly, LLC/802.2 has been ineffective at best in promoting different protocols to coexist. Most major operating systems build their own abstraction, or do implement 802.2 but bypass it for quite a few instances. Linux, for example, implements case statements in its IP implementation that changes the behavior of IP based on the type of underlying link. Given that this is an IP-based standards group, the only clear existing abstraction that has effectively decoupled the lower layers and permitted coexistence is IP and not 802.2 or LLC. That doesn't mean it should be ignored; however, it does not achieve the goals that you outline in your email. -Joe On 6/3/07, Jonathan Hui <[EMAIL PROTECTED]> wrote:
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
_______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
