Re: [6lowpan] Fwd: New Version Notification for draft-hui-6lowpan-nd-00

[Jonathan Hui <[e-mail]>]

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: [e-mail]
>
> <graycol.gif>Jonathan Hui <[e-mail]>
>
>
> Jonathan Hui <[e-mail]>
> Sent by:
> [e-mail]
>
> 28-07-2008 12:07
>
> <ecblank.gif>
> To
> <ecblank.gif>
> 6lowpan <[e-mail]>
> <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 <[e-mail]>
> > Date: July 28, 2008 2:15:48 AM PDT
> > To: [e-mail]
> > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lowpan
>

_______________________________________________
6lowpan mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6lowpan