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
_______________________________________________
devel mailing list
[email protected]
http://lists.riot-os.org/mailman/listinfo/devel
