Hi all,
I agree with Tiago.
I think mobility support might be also dependent on architecture and
scenarios of 6lowpan deployment, but in general, I also prefer
signalling (e.g., BU) in mobile RFD nodes shoud be avoided or reducing
signalling should be severely considered due to the RFD energy limitations.
Instead, I favor "FFD sending the (proxy) BU" like PMIPv6.
In addition, we shoud consider MANEMO scenario and its solution
for movement of 6lowpan networks.
At this time, I'm writing up a solution document for mobility support
and optimization for 6lowpan applications based on Samita's requirement
document (the requirements seem to be not clear with me yet, though)
I think we can work together on this topic.
Regards,
Myung-Ki,
Tiago Camilo wrote:
Hi Samita,
please see in-line comments,
Quoting Samita Chakrabarti <[EMAIL PROTECTED]>:
Hi Dominik and Tiago,
Sorry for the delay in replying. Some additional comments are in-line.
>
> In my opinion, RFD nodes should not have to detect their own movement.
> Their movement should *be detected* by more capable devices... what do
> you think?
>
I agree with this approach, it is important to reduce the network
activity of the RFD nodes. One possible solution of such *detect*
mechanism can be incorporated as one "LowPan Neighbor Discovery
Extension", in the Chakrabarti ID.
Tiago Camilo
Can you provide an example as to how the network or FFDs will detect new
nodes, that is more efficient than the RFDs doing it ?
If there is a 802.15.4 level presence detection, then the FFDs can
trigger some
messages to the new RFD for identification and address assignment.
But, it then
does not know if the RFD is in sleep mode or in awake mode. Thus, FFDs
will need
to send periodic messages in the network - the RFDs need to respond
anyway and
identify themselves. So, I don't see any advantages in network
initiated detection.
I think Dominik was talking about procedures such as Binding Updates,
Do you think RFD should send throughout their closest FFD periodical BUs?
or should be the FFD the one responsible for informing the Home Router
(Home PAN co-ordinator) about the new RFD CoA ?
I prefer the last approach, due to the RFD energy limitations .
On the other hand, if the RFD moves to a new 6lowpan network, it
should associate
with the new FFD at the L2 layer (association/dissociation is part of
802.15.4 spec).
Once it associates with a new FFD, the FFD then can send them cached
information on RA and prefix on the network ( this is not part of ND
draft yet, but
we can add it).
Nevertheless,by choosing the second approach (FFD sending the BU), we
need to warn somehow the FFD on the home address and the PAN co-ordinator
address of the RFD, maybe after receiving the RA.
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
