Hi Myung-Ki, Please see my response below. Sorry for the late response.
On 3/21/07, Myung-Ki Shin <[EMAIL PROTECTED]> wrote:
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.
The requirements were not written having solutions in mind. But it may make sense to relieve burden from RFDs to involve in mobility signaling. But we have to be a little careful about making them completely dumb, because then FFDs will have to work harder and need to do more complex record keeping. PMIPv6 may work fine with relatively larger devices such as ASN-GW and local-HA, but that adds one more layer of tunneling overhead. At this point, I don't know whether 6lowpan compression is efficient enough to handle the tunnels that are often used as a solution in the telco space. Thus as a work-group we will have to decide whether we want to follow MIPv6 or PMIPv6 style algorithm or it should be someting different that blends more smoothly with MANET type of protocols. IMHO, if we have to do anchoring then the IPv6 router would be the best choice for anchoring.
In addition, we shoud consider MANEMO scenario and its solution for movement of 6lowpan networks.
Yes. it is there, but there are some comments in the list which says that this part belongs to scenario examples.
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)
Let's work on polishing the requirements first. Please let us know what we should add to clarify the requirements. Thanks, -Samita
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
