Hi Anthony,
Thanks for the quick feedback! See below:
On Jul 28, 2008, at 4:39 AM, Anthony Schoofs wrote: Hi Jonathan,
I just had a quick look at your draft about Neighbor Discovery and Autoconfiguration for Route-Over 6LoWPAN Networks. It seems very good!
Thanks! It was an initial draft written last minute, so it is missing details as you point out below. I just wanted to get the basic idea out there. - A general question: as you recall it, either the IEEE EUI-64 or short address combined with the PAN ID may be used to generate an IID, as specified in [RFC4944].
Later you mention that appropriate link-layer address can be regenerated from the IID.
When a node from network A receives a packet from network B, how does it know whether the source node has used the short adress or the EUI-64 address to form the IID? I understand that you can use the U/L bit to separate EUI-64 from short addressing usage, but will destination nodes always have to check this U/L bit when receiving packets?
The text isn't very clear about this. The assumption is that the u/l-bit in the IID will tell you if it's global or local scope. The former implies an IEEE EUI-64, while the latter implies a short address. - About the Router Advertisements, we need to make sure that they are received by all the nodes. With respect to sensor networks constraints, nodes may not always be able to be awake when they are multicasted. Do you leave this issue to be solved by other means (global network time synchro, local buffering of RAs for transmission when nodes are awake,..)?
The exact implementation of ND will depend on whether or not the link protocol provides a multicast mechanism. If not, sleeping nodes can periodically wake up and send unicast Router Solicitations to routers and router will respond with unicast Router Advertisements. There was a brief statement in the Router Advertisement specification saying that the destination address can be the source address of a received Router Solicitation. This functionality is supported by IPv6 ND, so I'm not inventing anything new here. - It is mentionned that the RAs transmission period must use the trickle algorithm. I am not familiar with it, but it seems to me that it is not appropriate for networks with mobile nodes. I am looking at networks where nodes can move anytime, and we would go for short RAs periods. Is mobility out of your document scope?
Mobility is not intended to be out of scope. The Trickle algorithm just says that the transmission period increases over time but that there are one or more triggers that may reset the period back to something small. The exact triggers that reset the transmission period are not constrained by those mentioned in the document. I should make that more clear. - Finally, you wrote that all 6LoWPAN nodes MUST accept the newest prefix information. Is this a requirement? Again, I am interested in mobile nodes and we may want to use other metrics for choosing the prefix information.
I think I see your point, but I'd also like to hear what you had in mind. For context-based header compression to work, neighboring nodes have to agree on the prefix information for each context. That's why I tried to make sure nodes were consistent rather than not. If you're talking about address autoconfiguration, that's a different story. Just because the 'A' bit is set doesn't mean that a node must configure an IPv6 address using that prefix information. The 'A' bit only indicates that it can, at least that's my interpretation of it.
Again. Thanks for the quick feedback.
-- Jonathan Hui
Thanks!
Best regards,
Anthony
--
Anthony Schoofs
Research Scientist
Philips Research
High Tech Campus 34 , 5656 AE Eindhoven, The Netherlands
Email: [EMAIL PROTECTED]
<graycol.gif>Jonathan Hui <[EMAIL PROTECTED]>
| | <ecblank.gif>
To | <ecblank.gif>
6lowpan <[email protected]> | <ecblank.gif>
cc | <ecblank.gif>
| <ecblank.gif>
Subject | <ecblank.gif>
[6lowpan] Fwd: New Version Notification for draft-hui-6lowpan-nd-00 | <ecblank.gif>
Classification | <ecblank.gif>
| | <ecblank.gif> | <ecblank.gif> | |
Feedback/suggestions welcome.
Thanks.
--
Jonathan Hui
Begin forwarded message:
> From: IETF I-D Submission Tool <[EMAIL PROTECTED]>
> Date: July 28, 2008 2:15:48 AM PDT
> To: [EMAIL PROTECTED]
> Subject: New Version Notification for draft-hui-6lowpan-nd-00
>
>
> A new version of I-D, draft-hui-6lowpan-nd-00.txt has been
> successfuly submitted by Jonathan Hui and posted to the IETF
> repository.
>
> Filename: draft-hui-6lowpan-nd
> Revision: 00
> Title: Neighbor Discovery and Autoconfiguration for Route-Over
> 6LoWPAN Networks
> Creation_date: 2008-07-28
> WG ID: Independent Submission
> Number_of_pages: 24
>
> Abstract:
> This document specifies a simple version of IPv6 Neighbor Discovery
> for route-over 6LoWPAN networks. 6LoWPAN ND allows nodes to discover
> routers, discover network configuration parameters, and IPv6 prefixes
> for use with stateless address autoconfiguration and context-based
> 6LoWPAN compression for IPv6 headers. This document also specifies
> autoconfiguration mechanism for use in 6LoWPAN networks.
>
>
>
> The IETF Secretariat.
>
>
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
|
