Hello Cenk Superb!
This leaves unallocated space for future work. We can still write somewhere that this page is reserved for NDN so you can add stuff in the future with no page switch. Very cool. Pascal Le 23 sept. 2021 à 12:42, Cenk Gündoğan <[email protected]> a écrit : Hello Pascal, thanks for your helpful input. I was able to squeeze out a bit for CCNx messages by not encoding the version field and always relying on the version number to be "1" (as mandated by RFC8609 [1]). 6LoWPAN follows a similar philosophy [2]. I guess any serious protocol update may require big changes on the compression scheme anyways. If you are okay with the current allocations (diff: [3]), then I would carry this change back to the icnrg mail list and initiate a version update on positive feedback. Cheers, Cenk [1] https://datatracker.ietf.org/doc/html/rfc8609#section-3.2 [2] https://datatracker.ietf.org/doc/html/rfc6282#section-3 [3] https://tools.ietf.org//rfcdiff?url1=draft-irtf-icnrg-icnlowpan-10&url2=https://inet.haw-hamburg.de/tmp/draft-irtf-icnrg-icnlowpan-11.txt/@@download/file/draft-irtf-icnrg-icnlowpan-11.txt On Thu, Sep 23 2021 at 10:19 +0200, Cenk Gündoğan wrote: [[PGP Signed Part:Undecided]] Hello Pascal, the compressed NDN Interest + compressed NDN Data message dispatches have a few RSV bits. Fixing the prefix on 4 bits might work for them. For the compressed CCNx Content Object message it already works since we removed the RSV bit in the proposed solution. Currently, the compressed CCNx Interest message dispatch consumes two full octets and has no RSV bits left. That's the source of the asymmetry. I'll have a look at that particular section to see if we can optimize something there and will report again. Thanks, Cenk On Thu, Sep 23 2021 at 07:31 +0000, Pascal Thubert (pthubert) wrote: Hello Amanda; The current draft has this: +-------------+------+-------------------------------------------+ | Bit Pattern | Page | Header Type | +-------------+------+-------------------------------------------+ | 00 000000 | TBD1 | Uncompressed NDN Interest messages | | 00 100000 | TBD1 | Uncompressed NDN Data messages | | 01 000000 | TBD1 | Uncompressed CCNx Interest messages | | 01 100000 | TBD1 | Uncompressed CCNx Content Object messages | | 10 0xxxxx | TBD1 | Compressed NDN Interest messages | | 10 1xxxxx | TBD1 | Compressed NDN Data messages | | 11 0xxxxx | TBD1 | Compressed CCNx Interest messages | | 11 1xxxxx | TBD1 | Compressed CCNx Content Object messages | +-------------+------+-------------------------------------------+ The Uncompressed form has the 4 rightmost bits set to 0 while the compressed has them xxxxx. Which leaves lots of unassigned space un the Uncompressed range. This simple proposal seems to break the symmetry of compressed forms. | 10 0xxxxx | TBD1 | Compressed NDN Interest messages | | 10 1xxxxx | TBD1 | Compressed NDN Data messages | | 10 0xxxxx | TBD1 | Compressed CCNx Interest messages | | 11 10xxxx | TBD1 | Compressed CCNx Content Object messages | Maybe 4 bits is sufficient in all compressed forms? If so we can do better: +-------------+------+-------------------------------------------+ | Bit Pattern | Page | Header Type | +-------------+------+-------------------------------------------+ | 00 000000 | TBD1 | Uncompressed NDN Interest messages | | 00 000001 | | | | ... | | Unassigned | | 00 001111 | | | | 00 01xxxx | TBD1 | Compressed NDN Interest messages | | 00 100000 | TBD1 | Uncompressed NDN Data messages | | 00 100001 | | | | ... | | Unassigned | | 00 101111 | | | | 00 11xxxx | TBD1 | Compressed NDN Data messages | | 01 000000 | TBD1 | Uncompressed CCNx Interest messages | | 01 000001 | | | | ... | | Unassigned | | 01 001111 | | | | 01 01xxxx | TBD1 | Compressed CCNx Interest messages | | 01 100000 | TBD1 | Uncompressed CCNx Content Object messages | | 01 100001 | | | | ... | | Unassigned | | 01 101111 | | | | 01 11xxxx | TBD1 | Compressed CCNx Content Object messages | +-------------+------+-------------------------------------------+ Works? Pascal This leaves unassigned space -----Original Message----- From: Amanda Baber via RT <[email protected]> Sent: mercredi 22 septembre 2021 19:30 Cc: Eric Vyncke (evyncke) <[email protected]>; [email protected]; [email protected]; [email protected]; Pascal Thubert (pthubert) <[email protected]>; [email protected]; [email protected] Subject: [IANA #1200929] expert review for draft-irtf-icnrg-icnlowpan-10 Hi, IANA has been asked to notify the 6lo group and the authors of RFC 8025 as well as the IESG-designated experts that the authors of draft-irtf-icnrg- icnlowpan-10 (and the RG) have accepted a proposed change to an assignment in that document. Carles and Shwetha, can you confirm that we can move forward with this registry update? The issue is that Table 2 in https://datatracker.ietf.org/doc/html/draft- irtf-icnrg-icnlowpan is currently instructing IANA to make this registration in the Dispatch Type Field registry (we understand that this "TBD1" should be page 14): 11 1xxxxx | TBD1 | Compressed CCNx Content Object messages However, 11 11xxxx has already been assigned to "Page switch" for pages 0- 15: https://www.iana.org/assignments/_6lowpan-parameters This is the solution suggested by the experts and accepted by the authors: ===== One simple solution could be as follows: OLD: 11 1xxxxx | TBD1 | Compressed CCNx Content Object messages NEW: 11 10xxxx | TBD1 | Compressed CCNx Content Object messages A drawback of this solution is that it reduces the space of this type of messages (from 32 options to 16 options, for this specific type of messages), but perhaps it could be sufficient. ===== The authors write, "The simple solution provided by the designated experts is sufficient. The drawback does not affect the option space, since that particular dispatch also contains a 'Reserved' bit. We can trade this for the longer prefix '11 10xxxx' (instead of '11 1xxxxx')." Best regards, Amanda Baber IANA Operations Manager _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
signature.asc
Description: signature.asc
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
