Hi Martine & Martin,
following a personal discussion, the approach of multiple FIB tables
(per IF / protocol) is off the table, now. There will and can be only
one FIB.
Important for the next steps are discussion and conclusion about a
viable (internal) data structure for the FIB ... it seems there are
trade-offs between memory and processing constraints. Marin shall
present proposals for a thorough review discussion soon.
Cheers,
Thomas
On 05.11.2014 15:10, Landsmann, Martin wrote:
Hi all,
I started a prototype implementation [1] under consideration of the
diagram on the wiki page [2].
- It provides a generic address handling and access
- a basic FIB table management (add, remove, update)
- collision detection for next_hops and resolving the conflict based on
a preference table
- reactive RP signalling using `msg_send_receive()`
This prototype is not included between any RP and the `get_next_hop()`
right now.
Best regards,
Martin
[1] git pull https://github.com/BytesGalore/RIOT add_fib
[2]
https://github.com/RIOT-OS/RIOT/wiki/Rough-sketch-of-a-possible-FIB-modularization
On 04.11.2014 11:05, Martin wrote:
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
--
Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 °
_______________________________________________
devel mailing list
[email protected]
http://lists.riot-os.org/mailman/listinfo/devel
