Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO]

[Erik Nordmark <[e-mail]>]

On 4/18/11 1:37 AM, Pascal Thubert (pthubert) wrote:
 > Hi Esko, Erik
 >
 > The discussion on RPL and hosts should happen on the RPL list under a
 > different topic. The point being discussed here is this:

But it is hard to have that discussion if we don't know whether the 
'hosts' are participating in RPL or not.
For this email I assume they are not.

 > The reality is also that those (LLN) networks will need to scale to
 > large subnets in plants, building, etc... (see the requirement drafts in
 > ROLL). Registering to all LBRS is totally impractical. 6LoWPAN ND
 > requires a coordination between LBRs but does not say how it happens.
 > This problem was discussed in 6LoWPAN; the answer was in ND-01to07; and
 > it requires a TID, for the same reason as RPL. Removing the backbone
 > operation and the TID from the draft is ostrich policy.

Clearly the backend of the network needs to be able to handle changes in 
terms of the host's location, whether the backend is a set of LBRs or a 
set of RPL speakers. But that doesn't mean that the hosts need to be 
burdened with carrying a TID around. Different backends might use 
different mechanisms to serialize the changes to the host's location.

For example, when I go to an ATM machine to take out some money from my 
bank, there might be transaction IDs, timestamps, and many other 
wonderful things happening in the backend ATM network and the bank's 
database.

But that doesn't mean that I as a user of the ATM has to retain a 
transaction ID that I key into the ATM.

I think we can have the same degree of decoupling between 6lowpan and 
the routing protocols, and we do between the ATM user and the bank's 
database.

 > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all other
 > registrations do when strict ordering is not guaranteed (MIP being an
 > example). Say that due to some config, a node registers a lifetime of X,
 > then deregisters (lifetime 0), then reregisters (lifetime X) in a rapid
 > sequence, but does not get an answer yet. Then it finally gets 2 AROs
 > back, lifetime X and 0. What's the final state in the router?

If the host changes its mind, then it would make sense for it to first 
listen to the ack/nak of its previous instructions before issuing a new 
registration.

I don't see this as a difficult restriction, because I think that it 
will be rare that a host can't decide whether it will register or 
unregister.

    Erik