Subject: RE: Re: [Mobopts] New topics for the RG

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 12 Jul 2005 09:12:51 +0200

Yes, we have scenarios like that in NEMO and NEMO-Route Optimization to
enable the backhaul if the traffic from the sensors. The Sensors could
be dumb IPv6 nodes and all the routing/backhaul would be handled by the
mobile routers. MRs could be collocated with the sensors or flying
drones gathering data.

When MRs attach to other MRs to provide the service, we get into a
hybrid case where NEMO and MANET could collaborate so that a specific
instance of MANET is used to support Route Optimization for NEMO. And
NEMO would transport the sensors data, back to the central office where
they can be analyzed. 

In fact, some of us created a mailing list around that issue and called
it MANEMO, MANET for NEMO. The idea is to define the MANET that would
best help NEMO considering the NEMO RO requirements.

MANEMO did not have a BOF yet. Maybe in Canada for IETF 64?

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf
>Of Syam Madanapalli
>Sent: Tuesday, July 12, 2005 8:41 AM
>To: [email-masked]; Thierry Ernst
>Cc: [email-masked]
>Subject: Re: Re: [Mobopts] New topics for the RG
>
>Hi Daniel,
>
>I think what Thierry has said is NEMO runs on a mobile router behind
which
>the sensor devices are located. So Mobility is supported for the sensor
>devices
>without implementing the mobility protocols on memory constrained
sensor
>devices.
>
>But I think there can be a wireless sensor devices which may need MANET
>support.
>
>-Syam
>
>
>----- Original Message -----
>From: "Daniel Park" <[email-masked]>
>To: "Thierry Ernst" <[email-masked]>
>Cc: <[email-masked]>
>Sent: Tuesday, July 12, 2005 11:58 AM
>Subject: Re: Re: [Mobopts] New topics for the RG
>
>
>> Samsung Enterprise Portal mySingle(I think this thread should be
moved
>> into 6lowpan w.g., not mobopts)
>>
>>
>>
>>>Well, once sensors are IP-enabled, NEMO is likely more appropriate
than
>>>MANET, from a complexity point of view:
>>>- no need to manage mobiility: MR does everything
>>>- sensors may not be wireless nodes: MANET is pointless
>>>- MR can deals with security aspects on behalf of sensors
>>
>>
>>
>>
>> Are you saying that NEMO protocols are be able to be applied for
>>
>> 6lowpan node which has very severe  limited code and resource ?
>>
>> Or are you assuming any NEMO lightweight version ?
>>
>>
>>
>> Regarding MANET protocol, it is already enabled on lowpan
>>
>> network (802.15.4) such as ZigBee. Also, as far as I am
>>
>> concern, 6lowpan does not have any NEMO issues.
>>
>>
>>
>>
>> Regards
>>
>>
>>
>> Daniel (Soohong Daniel Park)
>>
>> Mobile Platform Laboratory. SAMSUNG Electronics
>>
>>
>>
>>
>>
>>
>
>
>-----------------------------------------------------------------------
----
>-----
>
>
>> _______________________________________________
>> Mobopts mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/mobopts
>>
>
>
>_______________________________________________
>Mobopts mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/mobopts

_______________________________________________
Mobopts mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mobopts

---

From: Daniel Park <[email-masked]>
Date: Tue, 12 Jul 2005 07:53:42 +0000 (GMT)

Thierry, sorry for my misunderstanding...:-)

>The Sensors could be dumb IPv6 nodes and all the

>routing/backhaul would be handled by the mobile

>routers. MRs could be collocated with the sensors or

>flying drones gathering data.

Above mention seems like an interoperability issue

of 6lowpan except adding NEMO into our  gateway.

http://www.ietf.org/internet-drafts/draft-daniel-6lowpan-interoperability-00.txt

Let me know your view on this.

Regards

---

From: [email-masked]
Date: Wed, 13 Jul 2005 11:46:07 -0700

Colleagues,
 
The following draft is of interest to the IEEE 802.21 community and I
encourage everyone to be familiar with the concepts.
 
http://www.ietf.org/internet-drafts/draft-daniel-mip-link-characteristic
-02.txt
 
Please notice in particular the implications of defining IEEE 802.21
parameterization of link change events and possible re-parameterization
of them in another layer. Coordination between groups and goals would be
useful here.
 
Also, the suggestion of combining link event reporting with a MIP-based
protocol has been discussed in our forum.
 
Best Regards,
Michael G. Williams, IEEE 802.21 Vice Chair

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Rajeev Koodli
Sent: Wednesday, July 13, 2005 10:52 AM
To: Ji Zhang
Cc: Soohong Daniel Park; [email-masked]
Subject: Re: [Mobopts] New topics for the RG

Hi,

I have seen interest in this topic. However, I think the topic is
more than just end-to-end event notification (Disclaimer: I have not
read the latest version). It could affect traffic on the Internet. 
So, before we could go ahead with the solution(s), we need to
carefully look into the broader problem, including "cross-layer
design" implications, congestion-control etc. Would you be 
interested in looking into those first? 

Regards,

-Rajeev

ps: A while ago, MIP group looked into the problem of end-to-end
     QoS problem definition and requirements. I feel the problems are
     similar.

Ji Zhang wrote:

	Hi Rajeev,
	
	Thanks a lot for your summary.
	
	We would like to recommend the following topic to be considered
for the
	charter:
	
	Deliver link layer characteristic information (e.g.
bandwidth...) to a
	mobile node's communication peers using mobility control
messages  (i.e.
	binding updates or registration requests), so that the
communication peers
	of the mobile node can control their traffic flows accordingly.
The idea is
	based on the draft
	
http://www.ietf.org/internet-drafts/draft-daniel-mip-link-characteristic
-02.txt.
	With this approach, the potential problems (i.e. capacity
overspending or
	underutilization) on access link capacity changes (especially on
vertical
	handovers) can be solved. The proposal is suitable for both
MIPv4 and MIPv6,
	regardless of the type of the transport protocol used.
Simulations will be
	done in the near future to test its performance.
	
	Any comments and questions are welcome.
	
	Regards,
	Ji

		Now, it is time to re-consider our charter items. What
sorts of topics
		are folks interested in working on?  I would like to
broaden our scope to
		consider Mobility on the Internet in general. Some
possible topics for
		discussion below in no preference order. Please comment,
suggest your
		topics and provide a brief justification.
		
		- multicast and mobility. A specific problem is what
address should the MN
		  use as its source IP address so that its packets are
not discarded due
		to a) RPF checks,
		  and b) source-specific multicast. To pass a), you need
the MN to use
		CoA, but to
		  pass b), you need HoA. How to convice multiple
receivers about CoA and
		HoA binding?
		  Is RR even an option? :-)
		
		- mobility (and traffic) patterns in a WLAN (e.g., a
campus network).
		This should provide
		  a better sense of traffic for admission control as
well as
		network-controlled handovers.
		
		- what is the scope of IP paging in a converged WLAN -
WWAN environment?
		  Is it a real problem? Worthwhile documenting in any
case?
		
		- architectural barriers to optimizing inter-domain
handovers. Although
		we have
		   some understanding of improving delay and packet loss
during
		handovers across
		   IP networks, how applicable are they across different
autonomous
		systems? Would
		   the policy barriers allow optimizations? Is this an
example of
		"tussle in cyberspace"?
		
		- privacy topics related to mobility
		
		- Others
		
		-Rajeev

	

------------------------------------------------------------------------
----
	----

---

From: "Yong" <[email-masked]>
Date: Sun, 17 Jul 2005 11:52:18 +0800

Hi, Rajeev,

We think that this topic is very interesting for current Mobile 
IPv6 deployment.

Currently, we are working on mobile ipv6 deployment based on network 
controlled handover solution in the area of nation-wide campus network.
In the first stage, we are going to build 100 experimental campus 
networks by the end of this year. In the second stage, we plan to 
expand to 1000 universities in the following two or three years.

Please kindly check the following draft:
http://www.ietf.org/internet-drafts/draft-cui-mobopts-hcf-wlan-00.txt

cheers

-Yong

======= 2005-07-12 16:30:53 You wrote =======

>Hi Rajeev,
>
>of course we are interested  to provide input on the network initiated 
>handover topic.
>We are currently revising the draft and we should be able to submit 
>version 01 by the end of the week.
>In the meanwhile I would like to trigger the discussion on the mailing 
>list based on version 00.
>
>regards,
>Telemaco
>
>>
>> - mobility (and traffic) patterns in a WLAN (e.g., a campus network). 
>> This should provide
>>   a better sense of traffic for admission control as well as 
>-- 
>Telemaco Melia			[email-masked]
>Research Staff Member		Tel: +49 (0) 6221 90511-42
>Network Laboratories		Fax: +49 (0) 6221 90511-55
>NEC Europe Ltd.			Web: http://www.netlab.nec.de
>Kurfrsten-Anlage 36
>D-69115 Heidelberg
>Germany
>
>
>

=======================================

Best regards,
11:36:45 2005-07-17
********************************************************
*    Yong Cui                                          *
*    Ph.D, Department of Computer Science & Technology *
*    Tsinghua University, Beijing, P.R.China(100084)   *
*    Tel: (8610)-62795818-6859                         *
*    Email: [email-masked]             *
********************************************************