--- gabriel montenegro <[EMAIL PROTECTED]> wrote: > bla, bla, ... > ... > Format 1: > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LF|Ver| prot_type |M| rsv |Payload (or Mesh Delivery Hdr)... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Actually, the Ver(sion) field would probably preced the LF field. Something that bothers me is the question of co-existence with, say, Zigbee, which also layers itself on top of 15.4 directly. In a LoWPAN network, when looking into the 15.4 payload, the first bits one would see would be the 'Ver' bits (presumably 0 for this first version). If a Zigbee network were to overlap (perhaps on purpose for dual-stack devices), I don't know what those first bits would be. So, while 'Ver' bits are fine in that they allow us to multiplex among the different versions of the lowpan encapsulation, it would be good to also be able to multiplex among the different types of 15.4 payloads (e.g., zigbee vs. lowpan). I don't include proprietary schemes, cuz they are so for a reason, and are definitely the majority now, and perhaps will remain so. Impossible to coordinate with all of them. But do folks see how one might be able to coordinate with zigbee? -gabriel _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
