> Rather than having the Next >Hop field be in potentially three different places, how about this idea: >Leave the L4C bit in HC1 as before, but rename it to NHC for next-header >compression (if NHC is 0, then the Next Header field is carried inline >and no HC2 header appears; if NHC is 1, then an HC2 header follows). >Then we define a HC2_UDP as follows: > > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |0|S|P|C| rsv | > +-+-+-+-+-+-+-+-+ > >The difference here is that we fix the first bit as '0' for UDP and >leave compression mechanisms for other Next Header values undefined for >now. As we define new NHC compression mechanisms, they can be added by >setting the first bit to '1' and some other bit-pattern following. It's >a huffman-style encoding, but we're just assuming that UDP is going to >be the most common case, so we give it the best case. > >I've also taken out the 'L' option, opting to say that UDP length should >always be elided and derived from lower layers, just as we've done with >the IP header.
[Pascal] I love it. Note that it's too bad that UDP comes first in this encoding though it needs few bits... So the hop limit compression now resides in one of the 2 freed NH bits and the other one is reserved, right? Pascal _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
