Subject: Re: [6lowpan] ND-10 Status

From: Erik Nordmark <[email-masked]>
Date: Tue, 06 Jul 2010 18:01:55 -0700

On 06/28/10 09:04 AM, Pascal Thubert (pthubert) wrote:

> The sequence number, that was provided in earlier versions of the ND
> spec,  is required to resolve movement from double registration in both
> RPL and the backbone router spec. It makes more sense to me to have the
> sequence number in the ARO right away than to have to make it an option
> in case the network grows past what's acceptable without coordinated
> LBRs.
>
> What do you think?

The issue with requiring hosts to send a sequence number in ARO is that 
it also means requiring the hosts to have some stable storage such as 
flash where they can store the most recently used sequence number.

Otherwise, if a host registered with sequence number 0x12345678 and then 
power cycles and looses that state, it might try to register with 
0x00001234, which will be ignored by the routers since it would be 
considered too old.

I know earlier versions of the draft had this initial set of numbers 
that were reserved for "I've lost state - please accept this". But that 
doesn't seem to be robust.
Suppose a host registers using sequence number 1. Then it moves and 
re-registers using sequence number 2. However, a delayed registration 
packet with sequence number 1 is propagating through the network. When 
it reaches the 6LBR it will win over the current #2, because it it is in 
the "I've lost state" range of sequence numbers.

I don't know of a robust way to handle this *without stable storage on 
each host*, using a single packet. It could be done with a 3-way 
exchange where the router would send back "is 1 your current sequence 
number", and get back an ACK/NAK from the host. But that is a fair bit 
more complicated, especially if we apply this to multi-hop DAD.

    Erik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 7 Jul 2010 09:21:38 +0200

> > spec,  is required to resolve movement from double registration in
> > both RPL and the backbone router spec. It makes more sense to me to
> > have the sequence number in the ARO right away than to have to make
it
> > an option in case the network grows past what's acceptable without
> > coordinated LBRs.
> >
> > What do you think?
> 
> The issue with requiring hosts to send a sequence number in ARO is
that it
> also means requiring the hosts to have some stable storage such as
flash
> where they can store the most recently used sequence number.
> 
0x00001234,
> which will be ignored by the routers since it would be considered too
old.
> I know earlier versions of the draft had this initial set of numbers
that were
> reserved for "I've lost state - please accept this". But that doesn't
seem to be
> robust.

 [Pascal] This is a very classical issue. RPL handles it with the also
classical
lollipop algorithm. And yes, 2 reboots in row will take a bit more time
to 
settle than just one, but it ends up working after the second reboot nb 
reaches the previous watermark. More on the RPL version at:
http://tools.ietf.org/html/draft-ietf-roll-rpl-10#section-6 

> Suppose a host registers using sequence number 1. Then it moves and
re-
> registers using sequence number 2. However, a delayed registration
packet
> with sequence number 1 is propagating through the network. When it
> reaches the 6LBR it will win over the current #2, because it it is in
the "I've lost
> state" range of sequence numbers.
> 
each
> host*, using a single packet. It could be done with a 3-way exchange
where
> the router would send back "is 1 your current sequence number", and
get
> back an ACK/NAK from the host. But that is a fair bit more
complicated,
> especially if we apply this to multi-hop DAD.
> 

[Pascal] This is basically what the HA does in MIP.  This has an added
value for 
the HA to be able to ensure bidir reachability by using a new seq num as
a 
challenge, though it is not officially used in the protocol.

I agree with all the above and favor the lollipop for those reasons.

Pascal

---

From: Ralph Droms <[email-masked]>
Date: Wed, 7 Jul 2010 15:00:35 -0400

There has been some discussion on this thread about the readiness of nd-10 for WG last call.  I have not seen any comment from the chairs.  Can you give me a schedule for when this document will go to WG last call and when it will be ready for IESG review?

- Ralph

On Jun 25, 2010, at 12:45 PM 6/25/10, Don Sturek wrote:

> I am sending this note on behalf of the ZigBee IP team to ask about the status of ND-10.  Here is what we have planned:
> 1)       There is a ZigBee IP interop event scheduled for next week.  We plan to have at least 5 implementations and to test ND-10. 
> 2)      We will create a report and send to the 6LowPAN reflector highlighting any issues we see.
>  
> However, we would like to see some commitment on bringing this topic to closure in the WG.
>  
> I have not seen too many e-mail threads on ND-10 other than the header option ordering.  Are there other issues?  Assuming implementations go well, what does everyone see the time to LC as?
> 
> Don
>  
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Ralph Droms <[email-masked]>
Date: Wed, 7 Jul 2010 15:01:06 -0400

Don - sorry if I missed it; have you posted the interoperability report from the interop event?

- Ralph

---

From: [email-masked]
Date: Wed, 7 Jul 2010 19:08:20 +0000

Not quite.  There is any internal copy but we need to remove vendor names to publish.

Don
Sent via BlackBerry from T-Mobile

-----Original Message-----
From: Ralph Droms <[email-masked]>
Date: Wed, 7 Jul 2010 15:01:06 
To: <[email-masked]>
Cc: 6lowpan 6lowpan<[email-masked]>
Subject: Re: [6lowpan] ND-10 Status

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Wed, 7 Jul 2010 15:12:53 -0400

OK, thanks, Don.

- Ralph

---

From: Zach Shelby <[email-masked]>
Date: Wed, 7 Jul 2010 22:47:54 +0300

Ralph,

The ND authors recently got a summarized list of things to clarify/solve based on the ZigBee IP interop from Robert (thanks!). We have been discussing those and tomorrow I will be making tickets for them with some proposals to solve them. Already there is a ticket regarding an interop comment from Daniel. 

In addition to that it would be great to have a report on the list too as these tickets will just be a summary of the TODOs.

Overall the feedback was helpful, and we don't see anything that can't be either clarified or fixed before the -11 submission Monday. 

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 07 Jul 2010 16:24:49 -0700

> http://tools.ietf.org/html/draft-ietf-roll-rpl-10#section-6

Seems like the non-deployed OSPFv1 used lollipop, but since that was 
still subject to the S1 < S2 < S3 < S1 issue, this was removed in OSPFv2.

That might be an issue for Roll; I haven't looked at it closely.

In any case, OSPFv1 includes the feature where using a number on the 
stick of the lollipop will result in other routers telling you the last 
sequence number they they have for your LSA. The message flow for 
6lowpan-nd doesn't have such a mechanism, and given that we don't 
require flooding all the information to all the routers, it isn't clear 
that we can actually add such a thing to 6lowpan-nd. (Without requiring 
that the AROs be flooded to all of the 6LRs.)

Thus I think there is some work needed before we can consider applying 
lollipop or any other sequence numbers to 6lowpan-nd.

> challenge, though it is not officially used in the protocol.

I HA in MIP is a centralized solution.
A distributed protocol is q very different beast.

    Erik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 8 Jul 2010 13:11:08 +0200

Hi Erik

> Seems like the non-deployed OSPFv1 used lollipop, but since that was
still
> subject to the S1 < S2 < S3 < S1 issue, this was removed in OSPFv2.
> 
stick
> of the lollipop will result in other routers telling you the last
sequence
> number they they have for your LSA. The message flow for 6lowpan-nd
> doesn't have such a mechanism, and given that we don't require
flooding all
> the information to all the routers, it isn't clear that we can
actually add such a
> thing to 6lowpan-nd. (Without requiring that the AROs be flooded to
all of
> the 6LRs.)

[Pascal] Let's do it then. You'll find that RPL:

1) uses simple increments (by 1 I mean)
2) emulates OSPFv2 in that it uses the odd space as a straight part.
3) avoids the S1<s2<s3<S1 pb with a window of consistency check

Sequences are comparable if they are not too far apart, and when that's 
so the higher number wins.

If we are still wrong, then the stale information will win until the
correct 
information eventually catches up, which happens sooner if the window
of consistency is smaller.

RPL has a lifetime associates to most resources and the idea is that the

lifetime should be smaller than the time it takes to increments the
seqnb 
outside the window of consistency. Sadly the lifetime is not there for
the 
DIO version nb, but that's another story and probably an issue.

Neither RPL nor BR is synchronizing dbs. They are merely trying to
identify
the freshest information. the consequence of being wrong is a temporary 
outage for the resource associated to the seqnb.

> > value for the HA to be able to ensure bidir reachability by using a
> > new seq num as a challenge, though it is not officially used in the
> > protocol.
> 

[Pascal] Exactly. So getting the previously used seq nb from the wrong
node in the distributed world is probably the wrong idea :) RPL did not 
takes that path.

Pascal

---

From: JP Vasseur <[email-masked]>
Date: Thu, 8 Jul 2010 13:52:11 +0200

Hi,

On Jul 7, 2010, at 9:47 PM, Zach Shelby wrote:

> Ralph,
>
> The ND authors recently got a summarized list of things to clarify/ 
> solve based on the ZigBee IP interop from Robert (thanks!). We have  
> been discussing those and tomorrow I will be making tickets for them  
> with some proposals to solve them. Already there is a ticket  
> regarding an interop comment from Daniel.
>
> In addition to that it would be great to have a report on the list  
> too as these tickets will just be a summary of the TODOs.
>
> Overall the feedback was helpful, and we don't see anything that  
> can't be either clarified or fixed before the -11 submission Monday.
>

That would be excellent.

JP.

>>> I am sending this note on behalf of the ZigBee IP team to ask  
>>> about the status of ND-10.  Here is what we have planned:
>>> 1)       There is a ZigBee IP interop event scheduled for next  
>>> week.  We plan to have at least 5 implementations and to test ND-10.
>>> I have not seen too many e-mail threads on ND-10 other than the  
>>> header option ordering.  Are there other issues?  Assuming  
>>> implementations go well, what does everyone see the time to LC as?
>>>
>>> Don
>>>