Hi Myung-Ki,
Good to see the requirements again. I think mobility is one of the most important drivers for 6lowpan deployment.
Thanks for your input.
Quick comments and questions - Most of requirements seem to be related to scenarios, not to specific mobility requirements.
There might be one or two scenarios that are listed as part of requirements. We will check.
Do you think handover-related signaling should be involved in 6lowpan devices (e.g., "full-function devices")? if so, reduction in handover-related signaling should be also considered as one of requirements.
As it was pointed out by Daniel that mobility solution will depend on the 6lowpan final architecture. Currently our architecture ( as discussed in the wg so far) is hierarchical with bunch FFDs and RFDs hanging off of FFDs and there is one IPv6 router at the top ( please see the 6lowpan-ipv6-nd draft for that assumption). But, yes, we should make it a requirement that the solution should contain minimum number of handover messages.
How about "reduced-function devices" ?
Yes, we need more text on RFDs.
So, do we need two different mobility mechanisms ? > o A lowpan node in a isolated IEEE802.15.4 network that has no > connectivity outside itself, does not require to have global IPv6 > address configuration.If the routing of packets are performed at > the lowpan layer using M bit, then only link-local address > configuration is sufficient. Are routing protocols enough to support this scenario ?
Please see the 6lowpan-ipv6-nd draft. 6lowpan current architecture assumes that there is one IPv6 subnet per 6lowpan network. Thus when a RFD moves within a 6lowpan network, its mobility happens at the L2 layer - but no change in L3 layer or IPv6 address. Since packets are routed using L2-layer mesh routing, thus there should be some signaling mechansim between old and new FFDs in this case.
> o When a lowpan node moves from one personal area network(6lowpan) > to another, it should immediately inform the new PAN co-ordinator > about its presence. The PAN co-ordinator through its IPv6 router > should inform the previous IPv6 router about the new IPv6 address > of the new node that was present in the old-lowpan network. Thus > it is possible that the roaming node can still talk to its > corresponder at the old-lowpan network. Mapping from old address to new address is required ?
Yes, in this scenario, the node's movement affects the L3 layer, as it moves from one 6lowpan to another and it's global IPv6 address changes. It also depends on the application. If one periodically sends data to another node's IPv6 addr, and the destination node moves to a different 6lowpan network, then the sender node's IPv6-router needs to know where to send the data that was addressed to the destination node's old ipv6 address.
In this case, handover-related signalling should be also involved in mobile devices ?
Should be. But we are not thinking about the solution details.
> o A inter-6lowpan gateway protocol is needed to comunicate the new > location (IPv6 global prefixes) of the roaming 6lowpan node which > moves across different 6lowpan networks I think if mobile lowpan nodes inform home network of its new address, this inter-6lowpan gateway protocol is not required.
I don't know whether we can hold the traditional home network concept here. I am not sure continuous mobility is important in 6lowpan scenarios.
> o As with any network, the movement of a lowpan node may introduce > security threats in the old and new LowPan Networks. Thus, > authentication of mobile lowpan node is required when it updates > the movement information to the new and old IPv6 6lowpan routers. Do you mean Binding Update - like signals with IPsec funcions ?
We mean some sort of authentication. It can be some group key exchange or certificate exchange.
> o A 6lowpan network may be attached to a mobile network through a > IPv6 router. For example, in a vehicle, a few 6lowpan networks > are connected through some Wifi access points to the operator's > network or Internet. The vehicle transmits data to a central > location via Internet or operator's network. In this case, there > could be 2 scenarios - 1) the 6lowpan nodes are always inside the > vehicle and they are stationary. 2) the 6lowpan nodes move and > join/detatch different 6lowpan networks within the vehicle 3) A > 6lowpan network may step out of the vehicle and find a different > wireless access point to talk to the Internet. This is one of scenarios for MANEMO. I think many folks are interested in this scenario. (this is a kind of scenario, not requirement. move it to the sec 4.)
Yes. Will move to the appropriate section. -Samita
Samita Chakrabarti wrote: > Hello All: > > We have published an updated version of 6lowpan mobility goals and > requirements > draft : > http://www.ietf.org/internet-drafts/draft-chakrabarti-mobopts-lowpan-req-01.txt > > > The draftname still reflects mobopts wg. We can change name to > publish under 6lowpan flag next time. > > Please read the draft and provide comments in the mailing list. > > Thanks, > -Samita > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/6lowpan >
_______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
