Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001

From: Kulwinder Atwal <[email-masked]>
Date: Wed, 3 Jan 2001 18:44:20 -0500

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Wednesday, January 03, 2001 6:29 PM
To: 'Kulwinder Atwal'; 'James Kempf'; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001

Kulwinder: 

   An IP handover solution for real time signals over a wireless link can be

designed, if the link is designed to support IP packet communications
(versus 
CBR voice communications), and if the access network is designed to support 
handover. 

   I am not sure what Bluetooth is or isn't capable of, but my 
point was, if Bluetooth has limitations, then so be it. This is not the
concern 
of SeaMoby, and I do not understand why you bring up the issue here. 

I don't think we should be designing some idealized protocol to be used "in
the future".

We have real problems here today.  I don't see why it can't have optional
features that 

are left up each network type to choose to implement.  It sounds like you
already have a 'future" network in mind.  And, are trying push a particular
agenda by not considering flexibility.  I should not be forced to implement
over the air Seamoby, just to be compliant so that I can use wired side
Seamoby.

Are we not trying to get the widest number of cases?

    As a general observation, people familiar with individual wireless
technologies 
have offered up reasons why SeaMoby should not perform one function or
another.  
As far as I see it, SeaMoby must work with pretty well any access network, 
which probably means it will have more capabilities then any particular
access 
network actually requires. This is usually part of the cost of providing an 
"internetworking" solution. Internetworking either for internetwork
mobility, 
or for intranetwork mobility across a variety of access network solutions. 

Gary 

-----Original Message----- 
From: Kulwinder Atwal [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wednesday, January 03, 2001 6:01 PM 
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf';
[email-masked]; [email-masked];
[email-masked]

Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001 

1. I can't do it with IP over a wireless link. 
2. I can do it without IP over a wireless link. 
3. Therefore, I would like to do the hand over with IP over a wired link to
other types of networks. 
4. And with L2 over the Bluetooth wireless link. 
  
- Kulwinder. 
-----Original Message----- 
From: Gary Kenward [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wednesday, January 03, 2001 5:40 PM 
To: 'Kulwinder Atwal'; 'James Kempf'; [email-masked];
[email-masked]; [email-masked]

Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001 

If it is true that you cannot perform "real time" seamless handover with 
Bluetooth because of the link protocol definition, then this is a problem
with 
the Bluetooth design, and naturally SeaMob cannot undo limitations of the 
wireless subnetwork or link layer design. 
I suspect there is an approach involving simulcast that would get around 
the problem, Kulwinder, but discussion of link layer problems and solutions 
do not belong on this list. 
This does, however, bring up the issue of n-casting (where n > 1 and n <=
all APs), 
as possible solution to be addressed when we around to working on solutions.

Gary 
> You can do SAR. 
> 
> But, you CANNOT fit a whole IPv6 packet in one slot when you 
> have seven 
> slaves.  Each slave gets one packet per one slot per 10 mSec. 
>  It will take 
> several slots per slave to do one IPv6 packet.  Therefore, it 
> will take 
> longer that 10 mSec.  For real-time the limit is 10 mSec.  
> Therefore, within 
> 10 mSec the max packet payload is 28 bytes. 
> 
> So if you want to do real-time seamless mobility using IPv6 ( 
> meaning you 
> want to use an IPv6 packet to switch a slave) it cannot be 
> done because you 
> will go well over the 10 mSec time limit. 
> 
> To summerize, SAR yes. 
> Real-time Seamless Mobility (switch slaves using IPv6 in 10 mSec) 
> mathematically not possible. 
> 
> Also, read my email to follow regarding what you saw in the 
> June IETF BOF 
> for Bluetooth. 
> 
> - Kulwinder. 
>

---

From: Michael Thomas <[email-masked]>
Date: Wed, 3 Jan 2001 16:30:40 -0800 (PST)

I really don't think it's unreasaonble for an IETF
working group to expect that a particular L2 is
capable of running IP with an MTU larger than 28
bytes. If a particular L2 has problems
accommodating that, there's not much we can do
about that. Taken to its logical ends, we'd be
saddled with having to support seamoby over the
original mobile IP: RFC 1149.

	Mike, though the thought of context
         transfer is an interesting prospect...

Kulwinder Atwal writes:
 > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
 > <HTML><HEAD>
 > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
 > <TITLE>RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001</TITLE>
 > 
 > <META content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD>
 > <BODY>
 > <DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
 > <BLOCKQUOTE dir=ltr 
 > style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
 >   <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
 >   size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
 >   [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, January 03, 
 >   2001 6:29 PM<BR><B>To:</B> 'Kulwinder Atwal'; 'James Kempf'; 
 >   [email-masked]<BR><B>Subject:</B> RE: [seamoby] MicroMobility Algorithm 
 >   Outline Revision 0.0001<BR><BR></FONT></DIV>
 >   <P><FONT size=2>Kulwinder:</FONT> </P>
 >   <P><FONT size=2>&nbsp;&nbsp; An IP handover solution for real time signals 
 >   over a wireless link can be</FONT> <BR><FONT size=2>designed, if the link is 
 >   designed to support IP packet communications (versus</FONT> <BR><FONT 
 >   size=2>CBR voice communications), and if the access network is designed to 
 >   support</FONT> <BR><FONT size=2>handover.</FONT> </P>
 >   <P><FONT size=2>&nbsp;&nbsp; I am not sure what Bluetooth is or isn't capable 
 >   of, but my</FONT> <BR><FONT size=2>point was, if Bluetooth has limitations, 
 >   then so be it. This is not the concern</FONT> <BR><FONT size=2>of SeaMoby, and 
 >   I do not understand why you bring up the issue here. </FONT></P>
 >   <P><FONT size=2><SPAN class=623133623-03012001><FONT face=Arial 
 >   color=#0000ff>I don't think we should be designing some idealized protocol to 
 >   be used "in the future".</FONT></SPAN></FONT></P>
 >   <P><FONT size=2><SPAN class=623133623-03012001><FONT face=Arial 
 >   color=#0000ff>We have real problems here today.&nbsp; I don't see why it can't 
 >   have optional features that </FONT></SPAN></FONT></P>
 >   <P><FONT face=Arial color=#0000ff size=2><SPAN class=623133623-03012001>are 
 >   left up each network type to choose to implement.&nbsp; It sounds like you 
 >   already have a 'future" network in mind.&nbsp; And, are trying push a 
 >   particular agenda by not considering flexibility.&nbsp; I should not be forced 
 >   to implement over the air Seamoby, just to be compliant so that I can use 
 >   wired side Seamoby.</SPAN></FONT></P>
 >   <P><FONT face=Arial color=#0000ff size=2><SPAN class=623133623-03012001>Are we 
 >   not trying to get the widest number of cases?</SPAN></FONT></P>
 >   <P><FONT size=2><SPAN class=623133623-03012001>&nbsp;</SPAN>&nbsp;&nbsp; As a 
 >   general observation, people familiar with individual wireless 
 >   technologies</FONT> <BR><FONT size=2>have offered up reasons why SeaMoby 
 >   should not perform one function or another.<SPAN 
 >   class=623133623-03012001><FONT face=Arial 
 >   color=#0000ff>&nbsp;</FONT></SPAN></FONT>&nbsp;<BR><FONT size=2>As far as I 
 >   see it, SeaMoby must work with pretty well any access network, 
 >   </FONT><BR><FONT size=2>which probably means it will have more capabilities 
 >   then any particular access</FONT> <BR><FONT size=2>network actually requires. 
 >   This is usually part of the cost of providing an </FONT><BR><FONT 
 >   size=2>"internetworking" solution. Internetworking either for internetwork 
 >   mobility,</FONT> <BR><FONT size=2>or for intranetwork mobility across a 
 >   variety of access network solutions.</FONT> </P>
 >   <P><FONT size=2>Gary</FONT> </P><BR>
 >   <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: 
 >   Kulwinder Atwal [<A 
 >   href="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> 
 >   <BR><FONT size=2>Sent: Wednesday, January 03, 2001 6:01 PM</FONT> <BR><FONT 
 >   size=2>To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf'; 
 >   [email-masked]</FONT></P>
 >   <P><FONT size=2>Subject: RE: [seamoby] MicroMobility Algorithm Outline 
 >   Revision 0.0001</FONT> </P><BR>
 >   <P><FONT size=2>1. I can't do it with IP over a wireless link.</FONT> 
 >   <BR><FONT size=2>2. I can do it without IP over a wireless link. 
 >   </FONT><BR><FONT size=2>3. Therefore, I would like to do the hand over with IP 
 >   over a wired link to other types of networks.</FONT> <BR><FONT size=2>4. And 
 >   with L2 over the Bluetooth wireless link.</FONT> <BR><FONT 
 >   size=2>&nbsp;</FONT> <BR><FONT size=2>- Kulwinder.</FONT> <BR><FONT 
 >   size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: Gary Kenward 
 >   [<A 
 >   href="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> 
 >   <BR><FONT size=2>Sent: Wednesday, January 03, 2001 5:40 PM</FONT> <BR><FONT 
 >   size=2>To: 'Kulwinder Atwal'; 'James Kempf'; [email-masked]; 
 >   [email-masked]; [email-masked]</FONT></P>
 >   <P><FONT size=2>Subject: RE: [seamoby] MicroMobility Algorithm Outline 
 >   Revision 0.0001</FONT> </P><BR>
 >   <P><FONT size=2>If it is true that you cannot perform "real time" seamless 
 >   handover with </FONT><BR><FONT size=2>Bluetooth because of the link protocol 
 >   definition, then this is a problem with </FONT><BR><FONT size=2>the Bluetooth 
 >   design, and naturally SeaMob cannot undo limitations of the </FONT><BR><FONT 
 >   size=2>wireless subnetwork or link layer design. </FONT><BR><FONT size=2>I 
 >   suspect there is an approach involving simulcast that would get around 
 >   </FONT><BR><FONT size=2>the problem, Kulwinder, but discussion of link layer 
 >   problems and solutions </FONT><BR><FONT size=2>do not belong on this list. 
 >   </FONT><BR><FONT size=2>This does, however, bring up the issue of n-casting 
 >   (where n &gt; 1 and n &lt;= all APs), </FONT><BR><FONT size=2>as possible 
 >   solution to be addressed when we around to working on solutions. 
 >   </FONT><BR><FONT size=2>Gary </FONT><BR><FONT size=2>&gt; You can do SAR. 
 >   </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; But, you CANNOT fit 
 >   a whole IPv6 packet in one slot when you </FONT><BR><FONT size=2>&gt; have 
 >   seven </FONT><BR><FONT size=2>&gt; slaves.&nbsp; Each slave gets one packet 
 >   per one slot per 10 mSec. </FONT><BR><FONT size=2>&gt;&nbsp; It will take 
 >   </FONT><BR><FONT size=2>&gt; several slots per slave to do one IPv6 
 >   packet.&nbsp; Therefore, it </FONT><BR><FONT size=2>&gt; will take 
 >   </FONT><BR><FONT size=2>&gt; longer that 10 mSec.&nbsp; For real-time the 
 >   limit is 10 mSec.&nbsp; </FONT><BR><FONT size=2>&gt; Therefore, within 
 >   </FONT><BR><FONT size=2>&gt; 10 mSec the max packet payload is 28 bytes. 
 >   </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; So if you want to do 
 >   real-time seamless mobility using IPv6 ( </FONT><BR><FONT size=2>&gt; meaning 
 >   you </FONT><BR><FONT size=2>&gt; want to use an IPv6 packet to switch a slave) 
 >   it cannot be </FONT><BR><FONT size=2>&gt; done because you </FONT><BR><FONT 
 >   size=2>&gt; will go well over the 10 mSec time limit. </FONT><BR><FONT 
 >   size=2>&gt; </FONT><BR><FONT size=2>&gt; To summerize, SAR yes. 
 >   </FONT><BR><FONT size=2>&gt; Real-time Seamless Mobility (switch slaves using 
 >   IPv6 in 10 mSec) </FONT><BR><FONT size=2>&gt; mathematically not possible. 
 >   </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Also, read my email 
 >   to follow regarding what you saw in the </FONT><BR><FONT size=2>&gt; June IETF 
 >   BOF </FONT><BR><FONT size=2>&gt; for Bluetooth. </FONT><BR><FONT size=2>&gt; 
 >   </FONT><BR><FONT size=2>&gt; - Kulwinder. </FONT><BR><FONT size=2>&gt; 
 >   </FONT></P></BLOCKQUOTE></BODY></HTML>