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

From: Jonathan Hui <[email-masked]>
Date: Mon, 28 Jul 2008 03:07:23 -0700

Feedback/suggestions welcome.

Thanks.

--
Jonathan Hui

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: July 28, 2008 2:15:48 AM PDT
> To: [email-masked]
> 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-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Anthony Schoofs <[email-masked]>
Date: Mon, 28 Jul 2008 13:39:39 +0200

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!

- 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?

-  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,..)?

- 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?

- 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.

Thanks!
Best regards,
Anthony

--
Anthony Schoofs
Research Scientist
Philips Research
High Tech Campus 34 , 5656 AE Eindhoven, The Netherlands
Email: [email-masked]

                                                                        To 
                                       6lowpan <[email-masked]>          
                                                                        cc 
     Jonathan Hui                                                          
     <[email-masked]>                                           Subject 
                                       [6lowpan] Fwd: New Version          
     Sent by:                          Notification for                    
     6lowpan-bounces@ietf              draft-hui-6lowpan-nd-00             
     .org                                                   Classification 
                                                                           
     28-07-2008 12:07                                                      

Thanks.

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 28 Jul 2008 04:54:05 -0700

Hi Anthony,

Thanks for the quick feedback! See below:

> 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

> Jonathan Hui <[email-masked]>
>
>
> Jonathan Hui <[email-masked]>
> Sent by:
> [email-masked]
>
> 28-07-2008 12:07
>
> To
> Subject
> [6lowpan] Fwd: New Version Notification for draft-hui-6lowpan-nd-00
> Classification
>
>

---

From: IGARASHI Yuichi <[email-masked]>
Date: Tue, 29 Jul 2008 03:52:40 +0900

Hi Jonathan,

I have two simple questions in draft-hui-6lowpan-nd-01.

 -Terminology
   Why do you use "Next Hop" in LOWPAN_IPHC?
   Why do not you use "Next Header"?

 -Order
   Why do you set "TVF"?  
   Why do not you set "VTF"like as IPv6 packet format?

Best regards,
Yuichi

--
 Hitachi, Ltd., Systems Development Laboratory
 IGARASHI Yuichi
 Mail： yuichi.igarashi.hb@.hitachi.com
 Tel ： +81-(0)45-860-3080
 FAX ： +81-(0)45-860-1674
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 29 Jul 2008 00:04:01 -0700

Hi Yuichi:

>   Why do not you use "Next Header"?

Oops, typo. Thanks for catching that. I'll fix it in the next revision.

>   Why do not you set "VTF"like as IPv6 packet format?

One of the changes is that I split out Traffic Class from Flow Label,  
allowing you to carry one inline without having to carry the other.  
I'm keeping Version with Flow Label simply to maintain byte alignment.  
But since Version and Flow Label span Traffic Class, there's no real  
ordering that can be had there.

Thanks.

--
Jonathan Hui