Hi Martine,
thx for the input :)
> Are you planning to only consider stateless compression (Prefix is
assumed link-local) or also stateful compression (Prefix is determined
by a 4-bit context ID [1] ...
I plan to make it more generic, e.g. allow for providing even
proprietary "solutions" for FIB table entry compression. LOWPAN_IPHC
provides wonderful mechanisms to save bytes in transmissions, but there
are probably (most likely) more possibilities to save bytes on the
individual nodes RAM when maintaining a FIB table.
Eventually the FIB will "resolve" the applied compression to provide the
type required by a `get_next_hop()` request.
>... we might want to consider to put those information into the same
data structure (so the later of my 2 suggestions above would be)
Indeed, that would by great. That's the reason I want to outsource the
"Generic address" from the FIB table entry. These blobs can be shared
among processes, e.g. FIB, routing protocol and ND.
Liftime invalidation and such is controlled by the individual process.
For instance, an expired FIB table entry would mark its internal
structure as invalid and decrease the usecount of the "Generic address".
> Also: have you considered Mesh-under routing [5]? (Do we have to
consider this here I wonder myself? We don't have support for it
anyways, so far.) [6] states some requirements for this.
No, I only considered to "play" at the network layer level for now. But
I will have a look.
Best Regards,
Martin
Hi,
I finally came to it to read your suggestions, too. Regarding the fact
that you keep 6LoWPAN header compression in mind, too: Are you planning
to only consider stateless compression (Prefix is assumed link-local) or
also stateful compression (Prefix is determined by a 4-bit context ID
[1], disseminated through the PAN via the context identifier option in
RS [2]). Since Neighbor Cache [3], Prefix Information [4], Forwarding
information, and Context Information are all very related, and we may
want to save memory, we might want to consider to put those information
into the same data structure (so the later of my 2 suggestions above
would be). Keep in mind though, that both Prefix Information Base and
Context information Base have their own lifecycles (see regarding RFCs).
Also: have you considered Mesh-under routing [5]? (Do we have to
consider this here I wonder myself? We don't have support for it
anyways, so far.) [6] states some requirements for this.
Hope this was more helpful, than confusing ;-).
Cheers,
Martine
[1] https://tools.ietf.org/html/rfc6282#section-3.1.2
[2] https://tools.ietf.org/html/rfc6775#section-4.2
[3] http://tools.ietf.org/html/rfc4861#section-5.1
[4] https://tools.ietf.org/html/rfc4861#section-4.6.2
[5] https://tools.ietf.org/html/rfc4944#section-11
[6] http://tools.ietf.org/html/rfc6606
_______________________________________________
devel mailing list
[email protected]
http://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
[email protected]
http://lists.riot-os.org/mailman/listinfo/devel
