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

From: "Samita Chakrabarti" <[email-masked]>
Date: Sun, 11 Mar 2007 15:08:19 -0800

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-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: "Dominik Kaspar" <[email-masked]>
Date: Mon, 12 Mar 2007 15:31:50 +0900

Samita,

I think there is one requirement missing, which should state that 
"reduced-function devices" are not to be involved in any mobility related 
signaling.

Dominik.

----- Original Message ----- 
From: "Samita Chakrabarti" <[email-masked]>
To: <[email-masked]>
Sent: Monday, March 12, 2007 8:08 AM
Subject: [6lowpan] 6lowpan Mobility requirements draft updated

> draft : 
> http://www.ietf.org/internet-drafts/draft-chakrabarti-mobopts-lowpan-req-01.txt
>

---

From: Myung-Ki Shin <[email-masked]>
Date: Mon, 12 Mar 2007 18:18:18 +0900

Samita,

Good to see the requirements again.
I think mobility is one of the most important drivers for
6lowpan deployment.

Quick comments and questions -

Most of requirements seem to be related to scenarios, not to specific
mobility requirements.

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.

How about "reduced-function devices" ?

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 ?

 > 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 ?
In this case, handover-related signalling should be also involved in
mobile devices ?

 > 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.

 > 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 ?

 > 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.)

Regards,
Myung-Ki,

---

From: Tiago Camilo <[email-masked]>
Date: Mon, 12 Mar 2007 14:20:05 +0000

Hi,

I also agree that the mobility will be one of the drivers of 6lowpan 
integration.

By reading the draft I become confused by the term mobility, since there 
are several types of mobility. Are you referring to seamless mobility, 
the one that let us move one node from one network to another and still 
have a continuous session? Or the draft just considers nomadism, where 
every time a node moves it needs to establish a new session?

I think you could clarify this aspect in section 2 of the draft.

Another consideration that I would like to see clarified is the one 
regarding the concept of Home Network (HN). In normal IPv6, HN takes an 
important role in mobility since it’s the Home Agent that is responsible 
to keep track of the CoA of our MN. In the draft you named it as 
original IPv6 gateway (OIG). My issue is who defines the OIG? Since the 
lowpan nodes can be randomly placed in scenario, in my opinion there can 
not be a lowpan HA concept, due to the mobility and fault tolerance 
characterizes of such network.

So it would be interesting to insert in section 4 one example, where a 
mobile node, not located on its primary network, needs to contact a 
specific lowpan node, using its Home Address (IPv6).

I also agree that it’s important to refer the mobility role of 
reduced-function devices as suggested by previous replies.

Best Regards,

Tiago Camilo

University of Coimbra

---

From: "Daniel Park" <[email-masked]>
Date: Thu, 15 Mar 2007 23:16:49 +0900

> "reduced-function devices" are not to be involved in any mobility related

Why ? Should RFD be a stationary mode only in 6lowpan area ? Can you
elaborate on your concern again ?

Daniel Park

---

From: "Daniel Park" <[email-masked]>
Date: Thu, 15 Mar 2007 23:59:35 +0900

> Most of requirements seem to be related to scenarios, not to specific

Given the relevant scenarios and use cases, we can end up to any
specific requirements. That's my sense since 6lowpan mobility is
really peculiar issue in IETF due to its link characteristics.

> So, do we need two different mobility mechanisms ?

I guess further study should take place in here. This document is
trying to list up mobility concerns in terms of 6lowpan at this stage.
Solution space will be forthcoming if folks interest occurs in this
group.

> Are routing protocols enough to support this scenario ?

What you mean by routing protocols ?

> In this case, handover-related signalling should be also involved in

Well, addresses (I am saying both short address and long address)
needs to be binded. Otherwise, those who want to initiate its talk to
mobile device can't find out its changable location. So far, I don't
have any idea whether we should design a new signaling for that or
resue something optimized...

> this inter-6lowpan gateway protocol is not required.

It belongs to 6lowpan architectural issue. I know this group will
start working on 6lowpan architecture. Let's see what architecture
will stir up...

> Do you mean Binding Update - like signals with IPsec funcions ?

Well, we'd like to focus on mobility requirements as well as feasible
scenarios at this stage. Once spelling out those clearly, then we will
go to details especially solution spaces if allowed. But, yes we
should live up to those kinds of functions in IETF in my thought.

> (this is a kind of scenario, not requirement. move it to the sec 4.)

It will take place in manemo bof in Prague. I will speak about that in
there. Please join us if you are of interest.

Daniel Park

---

From: "Daniel Park" <[email-masked]>
Date: Fri, 16 Mar 2007 00:23:17 +0900

> I think you could clarify this aspect in section 2 of the draft.

Mobility in this document does not have any restricted meaning. As
long as we work for 6lowpan mobility, we'd like to glance at all of
possibility described above. Further texts need to be added in the
next version following your input of course.

> important role in mobility since it's the Home Agent that is responsible

802.15.4 has a PAN Coordinator to manage to its child nodes. It can be
used for HN. Or as pointed out at the previous reply, it depends on
how to design 6lowpan architecture especially hierarchical routing
architecture.

> specific lowpan node, using its Home Address (IPv6).

A bit confused. Are you indicating that mobile node located in away
needs to talk with any lowpan node using its Home Address ? Why not
swapping its new address allocated by a new location for the old Home
Address ? Am I missing anything ?

> I also agree that it's important to refer the mobility role of

Ok,

Daniel Park

---

From: "Dominik Kaspar" <[email-masked]>
Date: Fri, 16 Mar 2007 09:36:32 +0900

Daniel,

> elaborate on your concern again ?

What I meant is that reduced-function devices should be able to move without 
having to involve actively in any mobility protocol. Even though the 
separation between RFDs and FFDs is pointed out in the draft, I could not 
see whether different mobility-related requirements apply to them or not.

For example the draft makes these two statements:
- "The lowpan nodes must be able to detect its movement from one wireless 
LowPan to another correctly."
- "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."

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?

Best regards,
Dominik

---

From: Tiago Camilo <[email-masked]>
Date: Fri, 16 Mar 2007 12:00:03 +0000

Daniel,

> how to design 6lowpan architecture especially hierarchical routing
I agree with your approach, since its the normal IPv6 behavior, my only 
concern is regarding the energy requirements of the PAN Coordinator in 
order to manage mobility of all its devices. Moreover this means that if 
the PAN Coordinator for some reason dies, the MN can not be reached?
> Address ? Am I missing anything ?
I also agree, a bit confused... moreover my example can be considered in 
the " Mobility across two different 6lowPan networks", so you can ignore 
my comment.

Tiago Camilo

---

From: Tiago Camilo <[email-masked]>
Date: Fri, 16 Mar 2007 12:10:30 +0000

Dominik Kaspar wrote:
> What I meant is that reduced-function devices should be able to move 
> without having to involve actively in any mobility protocol. Even 
> though the separation between RFDs and FFDs is pointed out in the 
> draft, I could not see whether different mobility-related requirements 
> apply to them or not.
>
> - "The lowpan nodes must be able to detect its movement from one 
> wireless LowPan to another correctly."
> another, it should immediately inform the new PAN co-ordinator about 
> its presence."
>
> 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

University of Coimbra

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Sun, 18 Mar 2007 23:08:34 -0800

Hi Dominik,

Why do you think that RFD's will not be involved with mobility related
signalling? Do you assume that RFDs will not move ?

Thanks,
-Samita

On 3/11/07, Dominik Kaspar <[email-masked]> wrote:
> Wrom: OYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDO
> To: <[email-masked]>

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Sun, 18 Mar 2007 23:36:12 -0800

Hi Dominik and Tiago,

Sorry for the delay in replying. Some additional comments are in-line.

> Extension", in the Chakrabarti ID.

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.

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).

But, I agree with you folks that we should specifically talk about RFD
function in  the requirement document.

Thanks,
-Samita

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Mon, 19 Mar 2007 00:22:24 -0800

Hi Myung-Ki,

> I think mobility is one of the most important drivers for

Thanks for your input.

> Most of requirements seem to be related to scenarios, not to specific
There might be one or two scenarios that are listed as part of requirements.
We will check.

> handover-related signaling should be also considered as one of

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.

> 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.
> 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

Should be. But we are not thinking about the solution details.

> 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.

> 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.

> (this is a kind of scenario, not requirement. move it to the sec 4.)
Yes.  Will move to the appropriate section.

-Samita

---

From: Tiago Camilo <[email-masked]>
Date: Tue, 20 Mar 2007 23:48:10 +0000

Hi Samita,
please see in-line comments,

> identify themselves. So, I don't see any advantages in network

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 .

> information on RA and prefix on the network ( this is not part of ND

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.
-- 
Tiago Camilo
PhD student
Laboratory of Communication and Telematics
University of Coimbra

> function in  the requirement document.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---

From: Myung-Ki Shin <[email-masked]>
Date: Wed, 21 Mar 2007 17:38:04 +0900

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,

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 21 Mar 2007 21:33:17 +0100

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

(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