Joe Polastre wrote:
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).
So lets take a concrete example: your favorite networking protocol (YFNP) and a over-the-air programming protocol (OTAP). One could argue that OTAP should not depend on YFNP in the case where you want to upgrade YFNP to YFNPng. Such incompatibility already exists with ZigBee 2006 and Pro. So for them to coexist in my network, I'll need to have two different keys, one for each protocol. When decoding a packet, I'll either need to try both keys and pick the one that works or rely on some common understanding of 802.15.4's key-identifier. The former is fairly inefficient. Maybe the argument is with appropriate hardware, we can efficiently apply a set of keys and have it return the one that worked, or none at all. Are there protocols operating on 802.15.4 that have scoped out more efficient ways of selecting the key to use? Or are you satisfied with the trial-and-error approach?
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.
While LLC/802.2 may have been ineffective at promoting different protocols to coexist in general, it does allow IPv4 and ARP to coexist by adapting EtherType values. Try running an IP box without one of these services. Maybe it would have been better to say that 802.15.4 lacks the upper-layer protocol type field of 802.3. Remember that 6lowpan is not about trying to run IPv6 on link-layers other than 802.15.4, so I wasn't trying to propose LLC as a useful abstraction to link layers.
This of this discussion is probably best left to the IEEE. Just trying to shed some light on why NALP exists in the first place.
-- Jonathan Hui [EMAIL PROTECTED] _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
