[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [DNA] Model: how to treat "link down" events



 
 
>
>> The above case may not be an abnormal case. The "Link UP" 
>event needs 
>> to be processed even though it has been generated by the 
>lower layer. 
>> This may take some time. It is not atomic in the sense that when the 
>> event happens,  no packets are allowed till the event is 
>processed. Do 
>> you think that this case is a pathological case ?
>
>My simple model assumes the whole IP layer (including Neighbor 
>Discovery and DNA) is a single event-driven loop, i.e. the 
>link up event and receives NS packets would be processed in 
>the order the device driver passes them up.
>
>If the implementation separates things, e.g., handling NS in 
>the kernel and the 'link up' events in a daemon, then it needs 
>to take care to preserve the ordering in this case.
>
>I don't think using 'link down' helps here, because we have 
>the common case of AP handover, where the change from using 
>one AP to another is more or less instantaneous. Even if we 
>mandate a 'link down' in that case, it would be immediately be 
>followed by a 'link up', thus a split implementation would 
>still need to handle the ordering issue.
>

Yes, the ordering issue is just not between the control events
but with respect to the packets received. I agree that setting
optimistic on receiving Link down will not work because even
that is not atomic.

>I suspect it's not that hard to have a split implementation do 
>the right thing. The 'link up' event can be used by the kernel 
>to immediately set the optimistic DAD state, and then pass the 
>event to the daemon that does DNA/RS/RA. That daemon will 
>later tell the kernel when to turn off the optimistic state.
>
I agree that this is the only way it can work for maintaining the
ordering. 

>But it sure is worth-while to list this as an implementation 
>consideration, in addition to making a clear statement about 
>the ordering/atomic behavior of the host as a whole for this issue.
>
Yes. Depending on the OS implementations, this is a very important
issue to consider.

>Do we put that in CPL or in draft-pentland? They both need the 
>same thing.
>
Agreed.

thanks
mohan

>    Erik
>