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