Hi Martine,
I will change the interface and protocol IDs to `kernel_type_t` as you
suggested.
For the FIB handling perspective this seems also to be the best (and
easiest) way to have the IDs unique on one RIOT/node.
> Shouldn't
https://github.com/BytesGalore/RIOT/blob/add_fib/sys/net/include/fib/fib.h#L119
return the iface_id too?...
absolutely. It just slipped through somehow.
thx for your input.
Best regards,
Martin
On 14.11.2014 14:29, Martine Lenders wrote:
Hi Martin,
now that I'm in the refactoring of IPv6 I have some
suggestions/considerations:
* considering the current refactoring of the network stack to
PID-based identification of a network layer / protocol shouldn't
iface_id in
https://github.com/BytesGalore/RIOT/blob/add_fib/sys/net/include/fib/fib.h#L80
et.al <http://et.al> be of type kernel_type_t?
Interface IDs as with the current net_if module will still be
available, since they are "useful waste" from my reworked ipv6_if
implementation (they are the indices of the buffer array where I
store the (mac_pid, IP addresses) tuples), but maybe we don't want
to use those in the future publicly anymore.
… On the other hand, if we find that a single-threaded network
stack is superior to our current approach (part of my master
thesis ;-)), we might have to rethink that again, hmmmm. Sorry,
this bullet point is more loud thinking than suggesting ^^"
* Shouldn't
https://github.com/BytesGalore/RIOT/blob/add_fib/sys/net/include/fib/fib.h#L119
return the iface_id too? The IP layer needs to now which MAC layer
it has to give the packet and this information is not encoded in
the address.
If I find more, I'll let you know
Cheers,
Martine
2014-11-06 20:45 GMT+01:00 Thomas C. Schmidt
<[email protected]
<mailto:[email protected]>>:
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] <mailto:[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 <tel:%2B49-40-42875-8452> °
° http://www.informatik.haw-hamburg.de/~schmidt
<http://www.informatik.haw-hamburg.de/%7Eschmidt> Fax:
+49-40-42875-8409 <tel:%2B49-40-42875-8409> °
_______________________________________________
devel mailing list
[email protected] <mailto:[email protected]>
http://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
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
