lwIP - A Lightweight TCP/IP stack - Tasks: task #13455, Extend neighbhor discovery to...
You are not allowed to post comments on this tracker with your current authentication level.
task #13455: Extend neighbhor discovery to support 6LoWPAN better.
Submitter: | Krishna Shingala <kshingala> | ||
Submitted: | Sat 24 Jan 2015 12:44:21 PM UTC | ||
Category: | IPv6 | Should Start On: | Sat 24 Jan 2015 12:00:00 AM UTC |
Should be Finished on: | Tue 24 Feb 2015 12:00:00 AM UTC | Priority: | 5 - Normal |
Status: | None | Privacy: | Public |
Assigned to: | None | Percent Complete: | 0% |
Open/Closed: | Open | Planned Release: | None |
Effort: | 0.00 |
Jump to the original submission
Tue 28 Jul 2015 03:18:07 PM UTC, comment #12: |
Ivan Delamer <idelamer> |
Tue 28 Jul 2015 11:13:52 AM UTC, comment #11: Hi Ivan,
|
April M <april_m> |
Fri 24 Jul 2015 03:05:52 PM UTC, comment #10: Netif goes below layer 3, and can have many functions. Adaptation and Layer 2 definitely fit there. You could split it more, but in a Light-weight system it fits well in a single layer.
|
Ivan Delamer <idelamer> |
Fri 24 Jul 2015 06:44:53 AM UTC, comment #9: Hi Ivan,
|
April M <april_m> |
Fri 24 Jul 2015 06:25:30 AM UTC, comment #8: 6LoWPAN compresses/decompresses the IPv6 header and adds new features for ND. I don't know why it is placed below netif. In fact, it should be the adaption layer between layer 3 and layer 2, I think. |
April M <april_m> |
Mon 23 Feb 2015 07:26:44 PM UTC, comment #7: Just if anyone is interested in my opinion: I fully agree with Sylvain here that RAM/ROM size (and execution speed maybe) are more important than layer separation. There are other layer separation violations in lwIP and I haven't seen a problem with that, yet.
|
Simon Goldschmidt <goldsimon> |
Mon 23 Feb 2015 07:04:01 PM UTC, comment #6: I don't think strict layer isolation is a must-have in a tiny embedded stack like lwIP where the smallest code size and memory requirements is the main goal (after basic security about input of course). We know what we are doing everywhere and reading the whole source code to understand how it works is not out of the question. |
Sylvain Rochet <gradator> |
Mon 23 Feb 2015 06:51:07 PM UTC, comment #5: hi Ivan!
|
Sergio R. Caprile <scaprile> |
Mon 23 Feb 2015 04:16:23 PM UTC, comment #4: FYI I'm starting work on adding 6LowPAN support.
|
Ivan Delamer <idelamer> |
Sat 21 Feb 2015 08:35:01 PM UTC, comment #3: Well, to me processing level 3 information in a level 2 netif violates layer independence.
Yes, tables will probably be duplicated, that depends on the capacity each module assigns for them (some info WILL be duplicated anyway, and its part of the module independence. The only options to not duplicate tables are:
Unfortunately both require 6LoWPAN to be "made by lwIP", and I guess the most likely solution to have this implemented is getting a third-party 6LoWPAN module to interface to. So, I still vote the same.
|
Sergio R. Caprile <scaprile> |
Fri 20 Feb 2015 04:32:55 PM UTC, comment #2: My best guess is that the info gathered by nd6/mld6 should be available, probably (desirable) by a callback function, so link-level protocols could use it. Some way to detect changes is also desirable.
|
Sergio R. Caprile <scaprile> |
Wed 28 Jan 2015 07:37:45 PM UTC, comment #1: Could you provide a patch or at least and idea of how to implement this? That would greatly raise the chances of this being integrated. |
Simon Goldschmidt <goldsimon> |
Sat 24 Jan 2015 12:44:21 PM UTC, original submission:
For use cases that implement a 6LoWPAN inerface, the context identifiers and prefixes distributed as a part of neighbor discovery procedures need to be provide to the 6LoWPAN layer to enable efficient compression and decompression of the IP header. This interface today does not exist in lwIP as lWIP does not accound for the 6LoWPAN. It will be extremly useful to enable notifying new prefixes and context identifier to the netif which can set these for the 6LoWPAN layer. Below is a short diagram to depict position of 6LoWPAN when using lwIP stack.
|
Krishna Shingala <kshingala> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follows 1 latest change.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2015-03-24 | goldsimon | Summary | Extend neighbhor discovery ti support 6LoWPAN better. | Extend neighbhor discovery to support 6LoWPAN better. |
Powered by Savane 3.13-f8d8.
Corresponding source code
Hi, please note that this is for discussing a specific task: "Extend neighbhor discovery to support 6LoWPAN", this discussion should be on a separate thread on lwip-devel list.
Short answer: as always we'll do our best to support RFCs, but since this is a lightweight stack we may limit some functionality.
If you have any comments/suggestions/questions regarding 6LowPAN, please send them to the lwip-devel list, I'd be very happy to discuss more there.