Subject: Re: [6lowpan] 6lowpan Mobility requirements draft updated

From: "Samita Chakrabarti" <[email-masked]>
Date: Mon, 16 Apr 2007 09:42:29 -0700

Hi Myung-Ki,

Please see my response below. Sorry for the late response.

On 3/21/07, Myung-Ki Shin <[email-masked]> 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-masked]>:
> >
> >> 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-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Mon, 16 Apr 2007 09:57:02 -0700

I agree with Carsten's comments below.  When do you think that we will
have a defined 6lowpan architecture document ready ?  IMHO, the
mobility requirement discussions can proceed parallely, but the
concrete solution requires to follow the architecture model(s).

Thanks,
-Samita

On 3/21/07, Carsten Bormann <[email-masked]> wrote:
> On Mar 16 2007, at 01:36, Dominik Kaspar wrote:
>
> > RFD nodes should not have to detect their own movement. Their
> > movement should *be detected* by more capable devices
>
> RFD nodes, if relying on that, don't want to fall into the hands of
> the "more capable devices" of the adversary.
> So they at least may have to be able to find out whether they are
> still (or newly) connected to a friendly FFD or in one of the two
> (not necessarily distinguishable) states "isolated" or "surrounded by
> adversaries only".
> We probably need the scenarios fleshed out with some more details
> before we can see which role(s) calls for RFDs and in which way these
> particular roles are "mobile" with respect to their FFD friends.
>
> On Mar 19 2007, at 09:22, Samita Chakrabarti wrote:
>
> > 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).
>
> (Putting WG chair hat on:)
> This is correct.
> We just have to be careful not to refer to this mental model as "the
> 6lowpan architecture", as we the WG haven't agreed on one yet.
> (Hat off again:)
> I personally think this structure would be good as one, but not
> necessarily the only structure supported by the 6lowpan protocols.
> But we aren't there yet: As we said during the meeting, we need to
> understand a reasonable set of 6lowpan scenarios and the (qualitative
> and quantitative) workloads generated by them.  And then we need to
> work on those we want to support, together with the structural models
> ("architectures") that will be used to support them.
>
> So, if you want to continue this discussion, please be concrete (as
> in "I have this airport with several 100 m of hallways that have RFD
> temp sensors that are each within 8 m of FFD light controllers spaced
> 12 m apart and a maintenance guy with a set of mutually connected FFD
> maintenance devices roaming in these hallways").
>
> Gruesse, Carsten
>
>

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Mon, 16 Apr 2007 09:52:54 -0700

Hi Dominik,

Let's first think whether BU and MIPv6 and PMIPv6 etc are applicable
for 6lowpan networks in general. IMHO, they are not directly
applicable to the 6lowpan network, but a variation of that. It depends
on how simple are the BUs - if they are small and simple enough then
it could be applied to FFDs and may be on RFDs as well.
If we think we want exclude the RFDs from mobility signaling, then our
solutions will have to support that.
It sounds like many people want RFDs to not worry about mobility
signaling. I am OK with that modification if majority agrees.

Thanks,
-Samita
> --
> PhD student
> Laboratory of Communication and Telematics
> University of Coimbra
>
> > But, I agree with you folks that we should specifically talk about RFD
> > function in  the requirement document.
> >
> > Thanks,
> > -Samita
> >
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>