Hi Pascal, Pascal Thubert (pthubert) wrote: >> 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?
It is too bad that UDP needs only a few bits. But there are ways to utilize those extra bits :-). If you mean the hop limit compression resides in one of the freed HLIM bits, then that's correct. -- Jonathan Hui _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
