From owner-seamoby@diameter.org  Tue Jan  2 16:13:34 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22721
	for <seamoby-archive@odin.ietf.org>; Tue, 2 Jan 2001 16:13:26 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f02Kx6E02410
	for seamoby-list; Tue, 2 Jan 2001 12:59:07 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f02Kx3W02405
	for <seamoby@diameter.org>; Tue, 2 Jan 2001 12:59:03 -0800
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2650.21)
	id <ZXNW85TJ>; Tue, 2 Jan 2001 15:06:27 -0500
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0480ACFEA@meshpdc.meshnetworks.com>
From: Michael Ruckstuhl <mruckstuhl@MeshNetworks.com>
To: "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>, seamoby@diameter.org
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
Date: Tue, 2 Jan 2001 15:06:25 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

One of the things I got out of Erik Anderlind's comments (12/20) was the
idea of separating handover on the local service network from selection of
'the (current) best' service network. The MN has its own ideas of best -
billing cost, battery cost, bandwidth cost, etc. However, if micromobility
can satisfy our needs on the current service network, we don't have to jump
through hoops to know all the RSSI gradient information. For the times (and
there will be some) when the current service network cannot maintain our QoS
needs following the handover, notification of this degradation of service
must be propagated to the correct layer on the MN, which would then
re-evaluate local service networks, and choose the 'best'.

I would like to see a segregation of inter- and intra- service network
handovers. 

I think that the intra- handovers should be covered by whatever cost
agreements exist between the service provider and the subscriber, presenting
an 'homogenous' network, requiring no real awareness of Full Radio Map
(other networks) by the MN. I think that inter- handovers are more
complicated because the subscriber wants the 'best deal' and may have cost
vs. QoS vs. bandwidth tradeoffs affecting network selection. 

Thus, intra-network handover can be made to maintain some BE support while
the MN realizes that an inter-network handover is now required per the
subscriber's configuration. I think the intra-network handover is what
everyone is discussing as micromobility?


mruckstuhl

-----Original Message-----
From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
Sent: Thursday, December 28, 2000 6:02 PM
To: 'Michael Thomas'; seamoby@diameter.org
Cc: Dave Oran; mankin@east.isi.edu
Subject: [seamoby] MicroMobility Algorithm Outline Revision 0.0001


Ok, I couldn't hold it in any longer.  Here it is.  My first crack this
problem. 

MicroMobility Outline:

Tri-cell map: upto three of the nearest endpoints in hetro net.
Bi-cell map: upto two of the nearest endpoints in hetro net.
Radio map: a collection of bi-cells or tri-cells forming a hetro net.
Golden min: The minumum RSSI value that will trigger pro-active hand-off.
GUID: unque id for a tri-cell, or bi-cell.


Partial Radio Map Discovery
	Go thru Radio interfaces in preferred order  /* see if we are in a
radio map that we know
		Tx SeaMoby_Tri-cell_GUID  	/* transmit the last GUIDS
that we knew current net 
						/* EP will respond with GUID
if correct, or tri-cell map 
						/* and new GUID
	Go until one acceptable QoS is found
Setup Connection				/* Get up and running on one
good known link first.
Full Radio Map Discovery
	Send a SeaMoby Discovery packet with IDs for the different nets we
may want links for
	Wait for SeaMoby RSSI packets to come back with two RSSI
values,timestamps,QoS per AP 
	and the relative position of homogenous APs

we have our relative position of APs and velocity vectors for MN to do
pro-active handoff.
Now we are ready for normal operation

If RSSI is less than Golden value then
Use Seamoby RSSI packets to monitor our relative position to discovered APs
We need at least a bi-cell within the radio map to track our change in
position.
This will tell us which AP is AP (N+1)

Handoff sequence Triggers:

T (Gold_min): The time that RSSI = Golden min
T (Start_ApNew): The trigger to start the microflows on AP(N+1)
T (MnSw_Start): The MN starts switching to the new AP(N+1).
T(MnSw_Stop): The MN finishes switching to AP(N+1).
T(Stop_ApOld): The trigger to stop the microflows on AP

I am ready.  Release the hounds!

- Kulwinder.




 


From owner-seamoby@diameter.org  Tue Jan  2 17:56:40 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23788
	for <seamoby-archive@odin.ietf.org>; Tue, 2 Jan 2001 17:56:39 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f02MWpW02497
	for seamoby-list; Tue, 2 Jan 2001 14:32:51 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f02MWnW02492
	for <seamoby@diameter.org>; Tue, 2 Jan 2001 14:32:49 -0800
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f02LdD110962;
	Tue, 2 Jan 2001 13:39:13 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104])
	by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f02LeCb05755;
	Tue, 2 Jan 2001 13:40:12 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 882569C8.00772DEA ; Tue, 2 Jan 2001 13:41:45 -0800
X-Lotus-FromDomain: 3COM
From: Phil_Neumiller@3Com.com
To: Michael Ruckstuhl <mruckstuhl@MeshNetworks.com>
cc: seamoby@diameter.org
Message-ID: <882569C8.00772974.00@hqoutbound.ops.3com.com>
Date: Tue, 2 Jan 2001 15:43:06 -0600
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-seamoby@diameter.org
Precedence: bulk



Hi Michael,

I think you have cut to the chase here with Occam's razor (micromobility is
moving from
medieval to modern thought).  What I really like about your thinking is that you
see
that inter-domain, inter-operator, inter-mobile, inter AP, and inter-XYZ all
will have seamoby
requirements and just maybe a generalized solution may exist.  Its not your
father's
micro-mobility in the "classical" sense anymore.  I would like to twist your
ideas a bit further.

There will be cases where the "same" service provider provides different air
interfaces that
overlap in coverage on both different and the same subnets and in any possible
permutation
on this you can dream up. My argument is that the number of these "now weird"
combinations
is going to go up, not down.  A particular base station may "want" to do things
one way,
whereas a particular mobile may "want" do things another way due too their
perspective.
This is why, we need  (here goes Phil again!!!) something like a contract
bidding algorithm
running between the interested parties (mobility agents? (overloaded term)).

If you think this idea holds any water at all, you may be curious enough to read
the
(albeit a very rough and not ready draft) I-D:

http://www.ietf.org/internet-drafts/draft-neumiller-seamoby-cnpmobility-00.txt

W/respect to RSSI gradients, to me this is just fine tuning, and a much more
serious
problem is that RF coverage in general is spotty.  Its a fading environment full
of
holes, shadows, reflections, etc.  The real problem in my mind is keeping up
multiple
air interfaces until the other one is ready to go and not fading in and out
forcing
ping-poging etc.  I believe handover reliability will go up enourmously if
SeaMoby
institutes a try to do make-before-break before anything else policy.  I realize
this
will not always be possible, but lets build towards this goal.  Also, you can do
some
nifty multi-homing transport things with SCTP should we get far enough along
to discuss that.

BTW, I don't like the term micro-mobility, but we are probably stuck with it.
The
SeaMoby flavor of micromobility IMHO would be more appropriately called Edge
Mobility, since it involves the communication between edge devices like access
points and base stations and mobile nodes (all apologies to the EMA guys!).

Thanks,

Phil




Sent by:  Michael Ruckstuhl <mruckstuhl@MeshNetworks.com>


To:   "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>, seamoby@diameter.org
cc:    (Phil Neumiller/MW/US/3Com)
Subject:  RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001



One of the things I got out of Erik Anderlind's comments (12/20) was the
idea of separating handover on the local service network from selection of
'the (current) best' service network. The MN has its own ideas of best -
billing cost, battery cost, bandwidth cost, etc. However, if micromobility
can satisfy our needs on the current service network, we don't have to jump
through hoops to know all the RSSI gradient information. For the times (and
there will be some) when the current service network cannot maintain our QoS
needs following the handover, notification of this degradation of service
must be propagated to the correct layer on the MN, which would then
re-evaluate local service networks, and choose the 'best'.

I would like to see a segregation of inter- and intra- service network
handovers.

I think that the intra- handovers should be covered by whatever cost
agreements exist between the service provider and the subscriber, presenting
an 'homogenous' network, requiring no real awareness of Full Radio Map
(other networks) by the MN. I think that inter- handovers are more
complicated because the subscriber wants the 'best deal' and may have cost
vs. QoS vs. bandwidth tradeoffs affecting network selection.

Thus, intra-network handover can be made to maintain some BE support while
the MN realizes that an inter-network handover is now required per the
subscriber's configuration. I think the intra-network handover is what
everyone is discussing as micromobility?


mruckstuhl

-----Original Message-----
From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
Sent: Thursday, December 28, 2000 6:02 PM
To: 'Michael Thomas'; seamoby@diameter.org
Cc: Dave Oran; mankin@east.isi.edu
Subject: [seamoby] MicroMobility Algorithm Outline Revision 0.0001


Ok, I couldn't hold it in any longer.  Here it is.  My first crack this
problem.

MicroMobility Outline:

Tri-cell map: upto three of the nearest endpoints in hetro net.
Bi-cell map: upto two of the nearest endpoints in hetro net.
Radio map: a collection of bi-cells or tri-cells forming a hetro net.
Golden min: The minumum RSSI value that will trigger pro-active hand-off.
GUID: unque id for a tri-cell, or bi-cell.


Partial Radio Map Discovery
     Go thru Radio interfaces in preferred order  /* see if we are in a
radio map that we know
          Tx SeaMoby_Tri-cell_GUID       /* transmit the last GUIDS
that we knew current net
                              /* EP will respond with GUID
if correct, or tri-cell map
                              /* and new GUID
     Go until one acceptable QoS is found
Setup Connection                   /* Get up and running on one
good known link first.
Full Radio Map Discovery
     Send a SeaMoby Discovery packet with IDs for the different nets we
may want links for
     Wait for SeaMoby RSSI packets to come back with two RSSI
values,timestamps,QoS per AP
     and the relative position of homogenous APs

we have our relative position of APs and velocity vectors for MN to do
pro-active handoff.
Now we are ready for normal operation

If RSSI is less than Golden value then
Use Seamoby RSSI packets to monitor our relative position to discovered APs
We need at least a bi-cell within the radio map to track our change in
position.
This will tell us which AP is AP (N+1)

Handoff sequence Triggers:

T (Gold_min): The time that RSSI = Golden min
T (Start_ApNew): The trigger to start the microflows on AP(N+1)
T (MnSw_Start): The MN starts switching to the new AP(N+1).
T(MnSw_Stop): The MN finishes switching to AP(N+1).
T(Stop_ApOld): The trigger to stop the microflows on AP

I am ready.  Release the hounds!

- Kulwinder.











From owner-seamoby@diameter.org  Tue Jan  2 19:02:15 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24226
	for <seamoby-archive@odin.ietf.org>; Tue, 2 Jan 2001 19:02:15 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f02NZBb02555
	for seamoby-list; Tue, 2 Jan 2001 15:35:11 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f02NYKW02550
	for <seamoby@diameter.org>; Tue, 2 Jan 2001 15:34:22 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 2 Jan 2001 17:39:52 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CC0L6DFS>; Tue, 2 Jan 2001 17:39:59 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8A51@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'seamoby@diameter.org'" <seamoby@diameter.org>
Subject: [seamoby] Context Transfer design team
Date: Tue, 2 Jan 2001 17:39:48 -0500
Sensitivity: Company-Confidential
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0750C.E9815B00"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0750C.E9815B00
Content-Type: text/plain;
	charset="ISO-8859-1"

Hello.

Below is a list of all those who I believe have requested to be part
of the context transfer design team. In the next day or two, an
email list server (seamoby_context@nortelnetworks.com) will be
activated, with these names on the list.

If your address is not on the list and you would like it to be, or if
your address as listed below is incorrect or out of date, send
*me* (gkenward@nortelnetworks.com) an email with the 
subject line "subscribe seamoby_context list".


If your address is on the list and you would like it taken off email
*me* (gkenward@nortelnetworks.com) with the subject line 
"unsubscribe seamoby_context list".

This process will be automated once the list is up, but it starting
with the existing list will save time and, hopefully, trouble.

Happy 3rd Millennium!
Gary

gkenward@nortelnetworks.com
hmsyed@nortelnetworks.com
alakas@nortelnetworks.com
g.tsirtsis@flarion.com
Govind.Krishnamurthi@nokia.com 
henrik.levkowetz@abrandnewworld.se 
Hong-Yon_Lach-AHL005@email.mot.com
jmanner@cs.Helsinki.FI
john.loughney@nokia.com
kulwinder.atwal@zucotto.com
Madjid.Nakhjiri@motorola.com
mscorson@ix.netcom.com
oneill@flarion.com
peter.lei@motorola.com
rajeev@IPRG.nokia.com
Sharif.Shahrier@InterDigital.com
t.pagtzis@cs.ucl.ac.uk
Yousuf.Saifullah@nokia.com

------_=_NextPart_001_01C0750C.E9815B00
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>Context Transfer design team</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hello.</FONT>
</P>

<P><FONT SIZE=2>Below is a list of all those who I believe have requested to be part</FONT>
<BR><FONT SIZE=2>of the context transfer design team. In the next day or two, an</FONT>
<BR><FONT SIZE=2>email list server (seamoby_context@nortelnetworks.com) will be</FONT>
<BR><FONT SIZE=2>activated, with these names on the list.</FONT>
</P>

<P><FONT SIZE=2>If your address is not on the list and you would like it to be, or if</FONT>
<BR><FONT SIZE=2>your address as listed below is incorrect or out of date, send</FONT>
<BR><FONT SIZE=2>*me* (gkenward@nortelnetworks.com) an email with the </FONT>
<BR><FONT SIZE=2>subject line &quot;subscribe seamoby_context list&quot;.</FONT>
</P>
<BR>

<P><FONT SIZE=2>If your address is on the list and you would like it taken off email</FONT>
<BR><FONT SIZE=2>*me* (gkenward@nortelnetworks.com) with the subject line </FONT>
<BR><FONT SIZE=2>&quot;unsubscribe seamoby_context list&quot;.</FONT>
</P>

<P><FONT SIZE=2>This process will be automated once the list is up, but it starting</FONT>
<BR><FONT SIZE=2>with the existing list will save time and, hopefully, trouble.</FONT>
</P>

<P><FONT SIZE=2>Happy 3rd Millennium!</FONT>
<BR><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>gkenward@nortelnetworks.com</FONT>
<BR><FONT SIZE=2>hmsyed@nortelnetworks.com</FONT>
<BR><FONT SIZE=2>alakas@nortelnetworks.com</FONT>
<BR><FONT SIZE=2>g.tsirtsis@flarion.com</FONT>
<BR><FONT SIZE=2>Govind.Krishnamurthi@nokia.com </FONT>
<BR><FONT SIZE=2>henrik.levkowetz@abrandnewworld.se </FONT>
<BR><FONT SIZE=2>Hong-Yon_Lach-AHL005@email.mot.com</FONT>
<BR><FONT SIZE=2>jmanner@cs.Helsinki.FI</FONT>
<BR><FONT SIZE=2>john.loughney@nokia.com</FONT>
<BR><FONT SIZE=2>kulwinder.atwal@zucotto.com</FONT>
<BR><FONT SIZE=2>Madjid.Nakhjiri@motorola.com</FONT>
<BR><FONT SIZE=2>mscorson@ix.netcom.com</FONT>
<BR><FONT SIZE=2>oneill@flarion.com</FONT>
<BR><FONT SIZE=2>peter.lei@motorola.com</FONT>
<BR><FONT SIZE=2>rajeev@IPRG.nokia.com</FONT>
<BR><FONT SIZE=2>Sharif.Shahrier@InterDigital.com</FONT>
<BR><FONT SIZE=2>t.pagtzis@cs.ucl.ac.uk</FONT>
<BR><FONT SIZE=2>Yousuf.Saifullah@nokia.com</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0750C.E9815B00--


From owner-seamoby@diameter.org  Tue Jan  2 22:19:26 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26147
	for <seamoby-archive@odin.ietf.org>; Tue, 2 Jan 2001 22:19:26 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f032d7F02658
	for seamoby-list; Tue, 2 Jan 2001 18:39:07 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from c007.snv.cp.net (c007-h008.c007.snv.cp.net [209.228.33.214])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f032bnW02653
	for <seamoby@diameter.org>; Tue, 2 Jan 2001 18:37:50 -0800
Received: (cpmta 4697 invoked from network); 2 Jan 2001 17:45:19 -0800
Received: from dsl-64-193-0-129.telocity.com (HELO telocity.com) (64.193.0.129)
  by smtp.telocity.com (209.228.33.214) with SMTP; 2 Jan 2001 17:45:19 -0800
X-Sent: 3 Jan 2001 01:45:19 GMT
Message-ID: <3A52849D.BC406C4E@telocity.com>
Date: Tue, 02 Jan 2001 19:47:09 -0600
From: Phil Neumiller <neumiller@telocity.com>
Organization: 3Com
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Lee, Jiwoong" <porce@kaist.ac.kr>, seamoby@diameter.org
Subject: Re: [seamoby] Request: Vertical IP research stuffs
References: <000901c074a0$15f8f340$d012060a@hansol.co.kr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello Jiwoong Lee,

If I understand your "definition" of "Vertical IP".
I believe you are referring to vertical handoffs in general.
Yes, SeaMoby is very much interested in vertical handoffs
since they occur at the edge of IP networks.  I guess
I would put the following examples into this category:

GSM -to/from- 802.11a
CDMA2000 -to/from- Bluetooth
UMTS -to/from- 802.11b

My desire is to make vertical handoff candidate APs aware
of each other a-priori, i.e. they can be discovered by
Mobile nodes but learned by access points or base 
transceiver stations.  Once learned they occassionaly
transfer to state to/from each other, possibly as part
of handover request messages.  This way an optimized route
can be slowly coalesce between the handoff neighbors.  I
like to think of make-before break when speaking of this 
type of handover.  Many people on this list and elsewhere
have refered to this type of handover as heterogeneous.
The up-stream routers in the Internet may be redirected
using mobile, IP.  The local exchange of QoS/AAA and
possibly traffic during micro-mobility handover is handled
by SeaMoby in my mind.

Perhaps you could elaborate more about the scenarios or
use cases that you are thinking about.

Thanks very much for your interest!

Phil Neumiller

"Lee, Jiwoong" wrote:
> 
> Vertical IP may be inappropriate in this WG. Anyway
> the carriers such as my company are quite interested in
> this for the upcoming market item.
> 
> I'm looking for some research/development effort
> in vertical IP or handoffs between multiple different
> access network with different NICs.
> 
> I found Perkins's mobile IP tutorial mentions this,
> as a research result of UCB - and I couldn't find
> relevant web pages.
> 
> Or else. If you have appropriate info on this,
> including web pages, research report or papers,
> or standard works, in any form, please let me know
> via this ML or personally. I appreciate your help in adv.
> 
> Thanks very much,
> 
> Jiwoong Lee


From owner-seamoby@diameter.org  Wed Jan  3 06:30:33 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA17610
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 06:30:32 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03AhFL02843
	for seamoby-list; Wed, 3 Jan 2001 02:43:15 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03AhDW02838
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 02:43:13 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <ZJFR844W>; Wed, 3 Jan 2001 04:50:46 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B62@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Michael Ruckstuhl'" <mruckstuhl@MeshNetworks.com>,
        "'Kulwinder Atwal'"
	 <kulwinder.atwal@herc.zucotto.com>,
        seamoby@diameter.org
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
Date: Wed, 3 Jan 2001 04:50:41 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk



> -----Original Message-----
> From: Michael Ruckstuhl [mailto:mruckstuhl@meshnetworks.com]
> Sent: Tuesday, January 02, 2001 3:06 PM
> To: 'Kulwinder Atwal'; seamoby@diameter.org
> Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
> 
> 
> One of the things I got out of Erik Anderlind's comments 
> (12/20) was the
> idea of separating handover on the local service network from 
> selection of
> 'the (current) best' service network. The MN has its own 
> ideas of best -
> billing cost, battery cost, bandwidth cost, etc. However, if 
> micromobility
> can satisfy our needs on the current service network, we 
> don't have to jump
> through hoops to know all the RSSI gradient information. For 
> the times (and
> there will be some) when the current service network cannot 
> maintain our QoS
> needs following the handover, notification of this 
> degradation of service
> must be propagated to the correct layer on the MN, which would then
> re-evaluate local service networks, and choose the 'best'.
> 
> I would like to see a segregation of inter- and intra- service network
> handovers. 

I agree completely.

> 
> I think that the intra- handovers should be covered by whatever cost
> agreements exist between the service provider and the 
> subscriber, presenting
> an 'homogenous' network, requiring no real awareness of Full Radio Map
> (other networks) by the MN. I think that inter- handovers are more
> complicated because the subscriber wants the 'best deal' and 
> may have cost
> vs. QoS vs. bandwidth tradeoffs affecting network selection. 

I have tried to solve the problem both ways, just give this idea a chance.
Just in case I missed something.  I wanted to show the wired guys that an
honest effort had been made.
 
> Thus, intra-network handover can be made to maintain some BE 
> support while
> the MN realizes that an inter-network handover is now required per the
> subscriber's configuration. I think the intra-network handover is what
> everyone is discussing as micromobility?

I don't think using IP is a good idea for intra-network hand-off.
Just the IPv6 header is 40 bytes.  The largest single slot packet that I can
send over Bluetooth has 28 bytes of payload.  This means that Bluetooth
cannot use IPv6 to do real-time seamless mobility.

I agree with everything that you have said.  The only place for IP is in
switch packet flows between two different types of networks.

 - Kulwinder.


From owner-seamoby@diameter.org  Wed Jan  3 06:54:25 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA17996
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 06:54:25 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03B9i502861
	for seamoby-list; Wed, 3 Jan 2001 03:09:44 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03B9gW02856
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 03:09:42 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <ZJFR8448>; Wed, 3 Jan 2001 05:17:16 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B63@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: Kulwinder Atwal <kulwinder.atwal@zucotto.com>,
        "'Michael Ruckstuhl'"
	 <mruckstuhl@MeshNetworks.com>,
        "'Kulwinder Atwal'"
	 <kulwinder.atwal@herc.zucotto.com>,
        seamoby@diameter.org
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
Date: Wed, 3 Jan 2001 05:17:15 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk


> I agree with everything that you have said.  The only place 
> for IP is in
> switch packet flows between two different types of networks.

Let me clarify.

The place for IP based real-time messaging is over the landline IP network
between a Bluetooth Host and other Cellular Base Stations to switch IP
packet flows.  Not, over a wireless link.  We cannot achieve seamless
real-time behaviour by sending IP over a Bluetooth wireless link.  I need to
get it done over a wireless link with only 28 bytes.

- Kulwinder.


From owner-seamoby@diameter.org  Wed Jan  3 07:30:05 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18920
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 07:30:05 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03C64b03005
	for seamoby-list; Wed, 3 Jan 2001 04:06:04 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from oulu.fi (root@ousrvr.oulu.fi [130.231.240.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03C5rW03000
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 04:05:54 -0800
Received: from ee.oulu.fi (ees2.oulu.fi [130.231.61.23])
	by oulu.fi (8.8.5/8.8.5) with ESMTP id NAA01161
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 13:13:24 +0200 (EET)
Received: from stekt60 (stekt60 [130.231.60.100])
	by ee.oulu.fi (8.11.1/8.11.1) with ESMTP id f03BDNI17653
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 13:13:23 +0200 (EET)
Date: Wed, 3 Jan 2001 13:13:23 +0200 (EET)
From: Mika Ylianttila <over@ees2.oulu.fi>
X-Sender:  <over@stekt60>
To: <seamoby@diameter.org>
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
In-Reply-To: <FC0292EA4D13D34EA2E5FC728D70A8E3078B62@NEPTUNE.zucotto.com>
Message-ID: <Pine.GSO.4.30.0101031302220.5325-100000@stekt60>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Wed, 3 Jan 2001, Kulwinder Atwal wrote:

>I don't think using IP is a good idea for intra-network hand-off.
>Just the IPv6 header is 40 bytes.  The largest single slot packet that I can
>send over Bluetooth has 28 bytes of payload.  This means that Bluetooth
>cannot use IPv6 to do real-time seamless mobility.

  Did you forget the possibility for header compression?  ;)

--
Mika Ylianttila
M.Sc., Project Manager
Centre for Wireless Communications
PL 4500, Tutkijantie 2 E, FIN-90014
University of Oulu, Finland




From owner-seamoby@diameter.org  Wed Jan  3 09:06:26 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22192
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 09:06:26 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03D4dM03148
	for seamoby-list; Wed, 3 Jan 2001 05:04:39 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mailhub1.shef.ac.uk (mailhub1.shef.ac.uk [143.167.1.9])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03D4XW03143
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 05:04:34 -0800
Received: from ridingwood.shef.ac.uk ([143.167.59.249])
	by mailhub1.shef.ac.uk with esmtp (Exim 3.16 #1)
	id 14Dmlu-0003rN-00; Wed, 03 Jan 2001 12:12:02 +0000
Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48);
    3 Jan 01 12:12:02 +0000
Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 3 Jan 01 12:11:48 +0000
Received: from Mobile1 (143.167.59.139) by ridingwood.shef.ac.uk (Mercury 1.48);
    3 Jan 01 12:11:45 +0000
Message-ID: <004301c0757d$e55f3e40$923ba78f@Mobile1>
Reply-To: "cnyap" <cny@ieee.org>
From: "cnyap" <cny@dcs.shef.ac.uk>
To: "Phil Neumiller" <neumiller@telocity.com>,
        "Lee, Jiwoong" <porce@kaist.ac.kr>, <seamoby@diameter.org>
References: <000901c074a0$15f8f340$d012060a@hansol.co.kr> <3A52849D.BC406C4E@telocity.com>
Subject: Re: [seamoby] Request: Vertical IP research stuffs
Date: Wed, 3 Jan 2001 12:08:34 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Phil 

Just a very small comment.
Vertical Handoffs does not meant that it needed to be heterogeneous,
very often Vertical handoffs is done on a homogeneous environment.

Cheers
Chern Nam Yap
MIEEE, MSc(Res), BSc(Hons)
Research Associate
Center for Mobile Communication Research
Department of Electronic and Electrical Engineering
University of Sheffield
F132 Mappin Building
Mappin Street
Sheffield S1 3JD
United Kingdom
Tel:+44 (0) 114-222-5182
Mobile:+ 44(0) 7712804892
Web: www.mobile1.net
E-mail: cny@ieee.org

----- Original Message ----- 
From: "Phil Neumiller" <neumiller@telocity.com>
To: "Lee, Jiwoong" <porce@kaist.ac.kr>; <seamoby@diameter.org>
Sent: Wednesday, January 03, 2001 1:47 AM
Subject: Re: [seamoby] Request: Vertical IP research stuffs


> Hello Jiwoong Lee,
> 
> If I understand your "definition" of "Vertical IP".
> I believe you are referring to vertical handoffs in general.
> Yes, SeaMoby is very much interested in vertical handoffs
> since they occur at the edge of IP networks.  I guess
> I would put the following examples into this category:
> 
> GSM -to/from- 802.11a
> CDMA2000 -to/from- Bluetooth
> UMTS -to/from- 802.11b
> 
> My desire is to make vertical handoff candidate APs aware
> of each other a-priori, i.e. they can be discovered by
> Mobile nodes but learned by access points or base 
> transceiver stations.  Once learned they occassionaly
> transfer to state to/from each other, possibly as part
> of handover request messages.  This way an optimized route
> can be slowly coalesce between the handoff neighbors.  I
> like to think of make-before break when speaking of this 
> type of handover.  Many people on this list and elsewhere
> have refered to this type of handover as heterogeneous.
> The up-stream routers in the Internet may be redirected
> using mobile, IP.  The local exchange of QoS/AAA and
> possibly traffic during micro-mobility handover is handled
> by SeaMoby in my mind.
> 
> Perhaps you could elaborate more about the scenarios or
> use cases that you are thinking about.
> 
> Thanks very much for your interest!
> 
> Phil Neumiller
> 
> "Lee, Jiwoong" wrote:
> > 
> > Vertical IP may be inappropriate in this WG. Anyway
> > the carriers such as my company are quite interested in
> > this for the upcoming market item.
> > 
> > I'm looking for some research/development effort
> > in vertical IP or handoffs between multiple different
> > access network with different NICs.
> > 
> > I found Perkins's mobile IP tutorial mentions this,
> > as a research result of UCB - and I couldn't find
> > relevant web pages.
> > 
> > Or else. If you have appropriate info on this,
> > including web pages, research report or papers,
> > or standard works, in any form, please let me know
> > via this ML or personally. I appreciate your help in adv.
> > 
> > Thanks very much,
> > 
> > Jiwoong Lee



From owner-seamoby@diameter.org  Wed Jan  3 10:30:06 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25497
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 10:30:01 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03EXhP03199
	for seamoby-list; Wed, 3 Jan 2001 06:33:43 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03EXfW03194
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 06:33:41 -0800
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA03749;
	Wed, 3 Jan 2001 05:41:08 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA08763;
	Wed, 3 Jan 2001 05:41:07 -0800 (PST)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id FAA06290;
	Wed, 3 Jan 2001 05:41:07 -0800 (PST)
Message-Id: <200101031341.FAA06290@nasnfs.eng.sun.com>
Date: Wed, 3 Jan 2001 05:41:20 -0800 (PST)
From: James Kempf <James.Kempf@eng.sun.com>
Reply-To: James Kempf <James.Kempf@eng.sun.com>
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
To: mruckstuhl@MeshNetworks.com, kulwinder.atwal@herc.zucotto.com,
        seamoby@diameter.org, kulwinder.atwal@zucotto.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: Y5fK1MlLkqAiUWGsNssvwQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk


>> Thus, intra-network handover can be made to maintain some BE 
>> support while
>> the MN realizes that an inter-network handover is now required per the
>> subscriber's configuration. I think the intra-network handover is what
>> everyone is discussing as micromobility?
>
>I don't think using IP is a good idea for intra-network hand-off.
>Just the IPv6 header is 40 bytes.  The largest single slot packet that I can
>send over Bluetooth has 28 bytes of payload.  This means that Bluetooth
>cannot use IPv6 to do real-time seamless mobility.
>

I don't understand this statement. The Bluetooth device simply needs
to do segmentation and reassambly. CDMA radio frames are also limited
in size, and nobody is suggesting that IPv6 can't be used for
mobility on CMDA.

		jak



From owner-seamoby@diameter.org  Wed Jan  3 11:55:17 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28180
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 11:55:16 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03GGbG03279
	for seamoby-list; Wed, 3 Jan 2001 08:16:37 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03GGZW03274
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 08:16:35 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <ZJFR84ZR>; Wed, 3 Jan 2001 10:24:09 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B64@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Mika Ylianttila'" <over@ees2.oulu.fi>, seamoby@diameter.org
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
Date: Wed, 3 Jan 2001 10:24:04 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

No, it just seems like a waste of effort.  Someone has to show me the real
value of doing this on a homogenous net.  Since we are talking about
real-time preformance, it would take time to compress/decompress.  If I can
do it without compression and get the same value I will.

- Kal.

> -----Original Message-----
> From: Mika Ylianttila [mailto:over@ees2.oulu.fi]
> Sent: Wednesday, January 03, 2001 6:13 AM
> To: seamoby@diameter.org
> Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
> 
> 
> On Wed, 3 Jan 2001, Kulwinder Atwal wrote:
> 
> >I don't think using IP is a good idea for intra-network hand-off.
> >Just the IPv6 header is 40 bytes.  The largest single slot 
> packet that I can
> >send over Bluetooth has 28 bytes of payload.  This means 
> that Bluetooth
> >cannot use IPv6 to do real-time seamless mobility.
> 
>   Did you forget the possibility for header compression?  ;)
> 
> --
> Mika Ylianttila
> M.Sc., Project Manager
> Centre for Wireless Communications
> PL 4500, Tutkijantie 2 E, FIN-90014
> University of Oulu, Finland
> 
> 


From owner-seamoby@diameter.org  Wed Jan  3 11:57:06 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28272
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 11:57:06 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03Fp2M03248
	for seamoby-list; Wed, 3 Jan 2001 07:51:02 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03FoxW03243
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 07:50:59 -0800
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09892;
	Wed, 3 Jan 2001 06:58:29 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA16710;
	Wed, 3 Jan 2001 06:58:28 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id GAA08205;
	Wed, 3 Jan 2001 06:58:27 -0800 (PST)
Date: Wed, 3 Jan 2001 06:54:56 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: RE: [seamoby] Micromobility Problem Statement
To: Michael Thomas <mat@cisco.com>
Cc: Gary Kenward <gkenward@nortelnetworks.com>,
        "'James Kempf'" <James.Kempf@eng.sun.com>, Phil_Neumiller@3Com.com,
        dblair@cisco.com, seamoby@diameter.org
In-Reply-To: "Your message with ID" <14913.21155.882040.452020@thomasm-u1.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.978533696.31572.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

> 
>    Why not? You're not under the mistaken notion that RSVP topology
>    changes need to touch every router in the path (as James seems
>    to be below) are you? RSVP works just fine with routing changes.
>    If it isn't RSVP that's going to deal with mobility, it's going
>    to be something that substantially reinvents it.
> 
I will be the first to admit that I haven't been following all of the recent
RSVP activities, but in the past it DID require that all routers in the path
to the destination process the RSVP message, and maintain state. I presume
that some of this is no longer required, somehow, in order to make use of RSVP
signaling in a diffserv core.

However, your comment on the fact that RSVP deals with mobility needs
clarification. Are you stating that RSVP is the method to request some QoS, or
it is in itself a mobility protocol?

PatC



From owner-seamoby@diameter.org  Wed Jan  3 12:06:08 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28544
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 12:06:07 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03GBu403270
	for seamoby-list; Wed, 3 Jan 2001 08:11:56 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03GBrW03265
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 08:11:53 -0800
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA18592;
	Wed, 3 Jan 2001 07:19:22 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA19372;
	Wed, 3 Jan 2001 07:19:05 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA08723;
	Wed, 3 Jan 2001 07:18:39 -0800 (PST)
Date: Wed, 3 Jan 2001 07:15:09 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: RE: [seamoby] Micromobility Problem Statement
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: Michael Thomas <mat@cisco.com>, Gary Kenward <gkenward@nortelnetworks.com>,
        "'James Kempf'" <James.Kempf@eng.sun.com>, Phil_Neumiller@3Com.com,
        dblair@cisco.com, seamoby@diameter.org
In-Reply-To: "Your message with ID" <Roam.SIMC.2.0.6.978533696.31572.pcalhoun@nasnfs>
Message-ID: <Roam.SIMC.2.0.6.978534909.15724.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

<chair hat>
As I wade through the countless e-mails in my never ending inbox, I find
myself easily led into QOS discussions, and what should be the signaling
method to get micromobility. However, I think that we should all focus our
efforts on getting the actual problem statement (hey, look at the subject of
this e-mail). I think that Dana's goal was to get the problem statement work
started, and instead this thread has degrated into the solution space.

Could we continue with the task of defining what the problem is that we are
trying to solve? </chair hat>

PatC



From owner-seamoby@diameter.org  Wed Jan  3 12:09:20 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28181
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 11:55:16 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03FjVU03237
	for seamoby-list; Wed, 3 Jan 2001 07:45:31 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03FjSW03232
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 07:45:28 -0800
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA10251;
	Wed, 3 Jan 2001 06:52:55 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA27567;
	Wed, 3 Jan 2001 06:52:54 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id GAA08076;
	Wed, 3 Jan 2001 06:52:53 -0800 (PST)
Date: Wed, 3 Jan 2001 06:49:23 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: RE: [seamoby] Micromobility Problem Statement
To: James Kempf <James.Kempf@eng.sun.com>
Cc: Phil_Neumiller@3Com.com, dblair@cisco.com, gkenward@nortelnetworks.com,
        seamoby@diameter.org
In-Reply-To: "Your message with ID" <200012202100.NAA01510@nasnfs.eng.sun.com>
Message-ID: <Roam.SIMC.2.0.6.978533363.7667.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

> 
> >I am aware of this problem. RSVP is not well suited for mobility
> >support because of the nature of the PATH state and the way it
> >is setup.
> >
> >This doesn't mean there isn't an edge solution, as Steve implied.
> >It does mean that a good solution may require looking at RSVP
> >and RSVP state closely. I don't think resending RSVP path and
> >resv messages is the way to handle QoS mobility in any case.
> >
> 
> I agree. Whether or not QoS state needs to be transferred
> depends on the QoS solution for mobile nodes, and I don't believe
> that is something currently within the charter of the Seamoby group,
> though, IMHO, it should be in *someone's* charter.
> 
My 2 cents on this one:

more signaling != seamless

For that matter, it appears as if diffserv needs to be used in the core. Now,
perhaps some signaling from the mobile is needed to get the edge device to
"reserve" the resources. This information can be transfered in the context
transfer, so no new signaling would be needed by the mobile.

This, of course, also needs to work across domains, so the QoS info transfered
would have to be "generic", and able to be mapped to the local DSCP.

PatC



From owner-seamoby@diameter.org  Wed Jan  3 12:14:09 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28810
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 12:14:08 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03Gd4503304
	for seamoby-list; Wed, 3 Jan 2001 08:39:04 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03Gd1W03299
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 08:39:01 -0800
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA28957;
	Wed, 3 Jan 2001 07:46:33 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA24080;
	Wed, 3 Jan 2001 07:46:32 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA09461;
	Wed, 3 Jan 2001 07:46:25 -0800 (PST)
Date: Wed, 3 Jan 2001 07:42:55 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [seamoby] cart-before-seamoby
To: Michael Thomas <mat@cisco.com>
Cc: seamoby@diameter.org, Dave Oran <oran@cisco.com>, mankin@east.isi.edu
In-Reply-To: "Your message with ID" <14923.36449.410575.132204@thomasm-u1.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.978536575.7679.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

> 
> I really wonder why we ended up with three design
> teams. I have no particular issue with the paging
> team, but it seems to me that it's really
> inappropriate to start thinking about context
> transfer isolated from what the overall
> requirements are. I assume that the goal of the
> [sic] "micro-mobility" design team is to come up
> with some set of scenarios which seamoby needs to
> consider, derive some requirements, and hopefully
> determine what the actual protocol work that needs
> to be done as well as a partition as to what
> seamoby should work on versus other working
> groups.
> 
> While it seems pretty obvious that some sort of
> context transfer and forward tunnel establishment
> needs to be provided for, it's not at all clear to
> me that we should be looking to solve those
> problems without considering the framework that
> comes out of the other work; indeed, it seems
> likely to cause even more confusion.
> 
I do understand your concern, but before we start considering a "framework",
we really need to understand what it is that we are trying to do. I have seen
on the list some disagreements on what the actual problem is. So, the three
design teams, at this time, are concerned with putting together the problem
statement. Once the design teams agree on what the problem is that needs to be
solved, as well as the IESG, we can consider rejoining everything into one.

PatC



From owner-seamoby@diameter.org  Wed Jan  3 12:38:50 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29487
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 12:38:50 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03Gj7R03321
	for seamoby-list; Wed, 3 Jan 2001 08:45:07 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03Gj4W03316
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 08:45:04 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <ZJFR8454>; Wed, 3 Jan 2001 10:52:39 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B65@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'James Kempf'" <James.Kempf@eng.sun.com>, mruckstuhl@MeshNetworks.com,
        kulwinder.atwal@herc.zucotto.com, seamoby@diameter.org
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
Date: Wed, 3 Jan 2001 10:52:29 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

I was waiting for this question.
Here we go.

If we say that real-time is 10 mSec, then in 10mSec Bluetooth has a total of
8 Master/Slave slot pairs.

A Master/Slave slot pair is composed of one Master TX slot and one Slave TX
slot. A slot is 625 microseconds.  A slot Master/Slave slot pair is two of
these, or 1.25 milliseconds.

There is a max of seven active slaves on a Bluetooth net. 
( 1.25 mSec x 7 = 8.75 mSec)

Therefore, if we want all slaves to have the same number of slots, then we
have one Master/Slave slot pair left over.  It is this pair that we can use
to do seamless mobility in real-time (10 mSec).

So, the phrase to focus on is "Real-time seamless mobility".

Of course, we can do IP SAR to all seven MNs, but it will not happen in
real-time.

- Kulwinder. 

> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@eng.sun.com]
> Sent: Wednesday, January 03, 2001 8:41 AM
> To: mruckstuhl@meshnetworks.com; kulwinder.atwal@herc.zucotto.com;
> seamoby@diameter.org; kulwinder.atwal@herc.zucotto.com
> Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
> 
> 
> 
> >> Thus, intra-network handover can be made to maintain some BE 
> >> support while
> >> the MN realizes that an inter-network handover is now 
> required per the
> >> subscriber's configuration. I think the intra-network 
> handover is what
> >> everyone is discussing as micromobility?
> >
> >I don't think using IP is a good idea for intra-network hand-off.
> >Just the IPv6 header is 40 bytes.  The largest single slot 
> packet that I can
> >send over Bluetooth has 28 bytes of payload.  This means 
> that Bluetooth
> >cannot use IPv6 to do real-time seamless mobility.
> >
> 
> I don't understand this statement. The Bluetooth device simply needs
> to do segmentation and reassambly. CDMA radio frames are also limited
> in size, and nobody is suggesting that IPv6 can't be used for
> mobility on CMDA.
> 
> 		jak
> 


From owner-seamoby@diameter.org  Wed Jan  3 12:53:12 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29987
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 12:53:09 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03GsoT03336
	for seamoby-list; Wed, 3 Jan 2001 08:54:50 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (witbier.cisco.com [171.71.152.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03GsmW03331
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 08:54:48 -0800
Received: from Ramalho-Family (rtp-vpn-120.cisco.com [10.82.192.120])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id HAA08995;
	Wed, 3 Jan 2001 07:58:44 -0800 (PST)
Message-Id: <4.1.20010103094645.00a3c420@witbier.cisco.com>
X-Sender: mramalho@witbier.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 03 Jan 2001 11:00:53 -0500
To: Kulwinder Atwal <kulwinder.atwal@zucotto.com>,
        "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'Kulwinder Atwal'" <kulwinder.atwal@herc.zucotto.com>,
        seamoby@diameter.org
From: "Michael A. Ramalho" <mramalho@cisco.com>
Subject: RE: [seamoby] cart-before-seamoby
In-Reply-To: <FC0292EA4D13D34EA2E5FC728D70A8E3078B5B@NEPTUNE.zucotto.com
 >
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_9477497==_.ALT"
Sender: owner-seamoby@diameter.org
Precedence: bulk

--=====================_9477497==_.ALT
Content-Type: text/plain; charset="us-ascii"

Kulwinder,

I have few comments/questions below.

I would like to thank you for providing enough background
information for me to comment on.

Please take my comments as constructive comments and/or
questions ... I've included a lot of commentary whose purpose
is to help clarify seamoby assumptions ... I am specifically
trying not to flame you. Sometimes that is hard to tell via email :-).

Michael Ramalho

At 06:40 PM 12/29/00 -0500, Kulwinder Atwal wrote: 
>
> Thankyou for making me aware of some the SeaMoby history.
>  
> The reason that I agree with Mike's observation is that have not heard 
> the discussions mention two things: Time Scale and RF Energy Gradient.


These seem to be related to a particular network technology, right?

That is ... given a network (radio/spectrum) design ... then "network
handoff triggers" are determined by the network designers ... and these
triggers can use such information to help determine when the
"triggering events" should be requested, right?

There is nothing in our draft-blair-rt-mobileipv6-seamoby that precludes
such measurement or *network* triggering events.

What our draft includes is other triggering events potentially generated
by the mobile for the case where it desires to move to either a
different link layer technology (potentially provided by the same
or different service provider) or the same link layer technology
provided by another service provider.

For the case where the mobile can listen on more than one radio
interface/technology ... the *seamless* make-before-break case is
more likely ... and the "handoff decision" heuristic (based on these
"handoff triggers") can be based on whatever information the network
or mobile decides to use.

For the case where the mobile can only listen/tune to one radio
technology/frequency at a given time AND there is *not* sufficient overlap
of the coverage (of the present service provider) ... then *specific
technology link layer metrics* (as I presume the RF gradient
stuff is) is essential to the *design or layout* of the network/spectrum.

Of course, the design is, in turn, dependent upon how fast/efficient
the context transfer mechanism is ... so there is some circularity
in the argument ... but only FOR THE CASE OF NOT SUFFICEINT
COVERAGE OVERLAP AND ONLY ONE RADIO/TUNER. This is
an important case in the present ... but likely less so in the future.

In the future, I hope that:

1) a given volume will either be covered by more than one technology
and/or service provider, and
2) that mobile devices can listen/tune to more than one radio technology
at a given time (heck ... even my car radio is really two radios, using
diversity technology to decide which signal is stronger!).

Lets make sure that seamoby accommodates the "single radio/coverage"
case above ... but let us not optimize for it alone. Please.

>
>  
> The time scale of events will determine what parts of the context need to be
>  transferred when, what paging messages need to be sent and when, and what 
> the structure of the hand-off needs to be.  Since I am new, maybe this info 
> is in some document I have yet to read.  At the chance of re-hashing, 
> I will expand on what I mean by Time Scale and RF Energy Gradient.
>  
> In the draft Realtime Mobile IPv6 Framework looking at the first diagram, I
> have 
> noticed that the overall view of the network is in the static physical
> domain.  
> In real-time systems if we what to maximize the efficient use of available
> system
>  bandwidth the overall view has to be in time domain.  We need to do the
> right 
> thing at the right time in the right place.  


We have examples in the Appendix of particular handoff movements and
examples of how to transfer context for these cases. The sequencing
of events are important .... particularly so for a particular technology under
consideration. But this is a design issue for a particular technology (thus
these examples were put in our appendix ... and not a cornerstone of our
framework draft itself).

I hope that seamoby defines a kind of framework or unified design principles
that can be applied to particular technologies. That is ... we need to
understand
the constraints of present technologies ... but not necessarily optimize around
one of them at the *potential* expense of de-optimizing a lot of other link
layer technologies.

>
> Let me expand on the time scales that 
> are relevant to this problem.
>  
> Radio Map Time Scale:  The time it takes to traverse at least three endpoint
> service areas.


What is an "endpoint service area"? Sounds like a particular network technology
to me.

>
> This is different than a Trusted Domain as we are talking about the nearest
> three endpoints
>  in the hetro net.  ( Time Scale is : ~ minute minumum)


A Trust Domain was defined as it is likely to effect whether the context
from elements in one trust domain will be accepted by another. It has nothing
to
do with latency between access routers/APs ... only with security/trust
relationships.

>
> Endpoint Service Area Time Scale:  The time it takes to traverse the service
> area of an
> endpoint.  ( Time Scale is: ~ 10 seconds minumum)


Isn't this related to the assumed movement of the mobile and the size
of the coverage area (e.g., cell) .... that is ... a *network design* issue.
For a particular *network design* this is important.

>
> Real-Time Time Scale: The time that it takes for a video stream to lose its
> real-time 
> behaviour.  ( Time Scale is: < = 10 milliseconds)


Why is video significantly different from other interactive modes of
communications
(e.g., voice)?

>
> Mobile Node Switch Time:  The time that it takes for a mobile node to switch
> frequencies.
> ( Time Scale is: ~ microseconds)


Sounds again like you are assuming the single frequency/technology case. Why
should this case *alone* significantly drive seamoby design? I think it is an
important
case to study ... especially for present designs ... but not necessarily to
optimize
about.

>
>  
> So the overall goal for all the teams is to push decision making and packet
> transfers toward the 
> Radio Map time scale, and pre-configure where ever and when ever possible.


Network handoff decision heuristics can drive the handoff process .. but we
should
*not* limit our discussion in seamoby to only this case. More below.

>
>  
> RF Energy Gradient:
>  
> In Pro-active hand-off we must ask "In our current direction of travel where
> will be the next strongest signal."  What we need is for  APs to tell us is,
> how is our signal changing over time as we travel on our current path.  This
> is the RF Energy Gradient.  
>  
> RF Energy Gradient = change in RSSI / change in time
>  
> What we need is for the APs to measure the MN RSSI at two points in time and
> send it to the mobile node.  Since the mobile node will most likely travel to
> the same places every day, the mobile node can store the QoS values for the
> APs.  When a mobile node enters an area it can send the last GUID it had for
> the area to see if the radio map has changed.  
>  


Fine ... engineering a particular network technology to measure these things
are
precisely what equipment manufacturers design. Is there any reason why access
points
that service a particular network technology uses cannot communicate this
information
to the point(s) in the network responsible for the (network, in your case)
decision.

That is, what of the above discussion is required to be specified by seamoby?

We have a lot of signaling transport and control protocols at our disposal for
this .... I see no reason why seamoby needs to (re)specify them.

In other words ... seamoby should not specify *network design* ... the market
will decide which manufacturers/designs work the best .... or other standards
bodies will offer design recommendations ... I think seamoby should steer clear
of such political rat-holes!

Again, I'd like to thank Kulwinder for the opportunity to comment ... but these
comments highlight the need for a seamoby "problem statement" that we
can all rally behind.

My hope is that such a problem statement will not suggest to the world that
we are effectively re-designing (ONLY) cellular network behavior over IP. I
would
like equipment manufacturers to do that specific job .. preferably using
(unified) design principles that are in seamoby's charter or framework
document.

Stepping off my soapbox.
>
>>
>> -----Original Message----- 
>> From: Gary Kenward [mailto:gkenward@nortelnetworks.com] 
>> Sent: Friday, December 29, 2000 5:01 PM 
>> To: 'Kulwinder Atwal'; seamoby@diameter.org 
>> Subject: RE: [seamoby] cart-before-seamoby
>>
>> You've missed the point, Kulwinder. The SeaMoby wg is tasked with writing  
>> problem statements for the three identified areas of concern, paging,
micro- 
>> mobility and context handoff. As far as I know, the ADs are also looking
for 
>> these problem statements. 
>>
>> Since the CRAPS BOF, the collection of people contributing to this area have
>> had  
>> a rough time convincing the IETF at large that there are real problems to
>> solve.  
>> Algorithms, protocols, etc., are all well and good, but the working group
>> will not  
>> proceed without the problem statements. Whether it is one or three problem  
>> statements is moot at this point. The working group consensus was to produce
>> three problem statements. Maybe once this has been completed, we can combine
>> the three into one, if that is considered a useful exercise. 
>>
>> I happen to agree with the observation that if we cannot collectively
agree  
>> on a definition of the problem, then we don't have much hope of ever
>> agreeing  
>> on a solution. Regardless, do not flame the messenger, it was not my
>> decision. 
>>
>> Gary 
>>
>> > -----Original Message-----  
>> > From: Kulwinder Atwal
>> [<mailto:kulwinder.atwal@zucotto.com>mailto:kulwinder.atwal@zucotto.com]  
>> > Sent: Thursday, December 28, 2000 4:05 PM  
>> > To: 'Michael Thomas'; seamoby@diameter.org  
>> > Cc: Dave Oran; mankin@east.isi.edu  
>> > Subject: RE: [seamoby] cart-before-seamoby  
>> >  
>> > 
>> > I have been having the same thoughts.  I am of the opinion 
>> > that without an  
>> > algorithm we can only agree to disagree.  That is why I have  
>> > not made any  
>> > further input on context transfer, and instead I have been  
>> > thinking on how  
>> > to do just pro-active RF switching among dynamic hetro nets.   
>> > I have written  
>> > a two page outline for an algorithm on how to do the  
>> > pro-active switching  
>> > initiated by the MN across hetro nets using RSSI.  I will  
>> > work on it for  
>> > another day, or so before putting it out there to the wolves.  
>> >  Then at least  
>> > we will have a starting point.  
>> >  
>> > - Kulwinder.  
>> > 
>> > > -----Original Message-----  
>> > > From: Michael Thomas [<mailto:mat@cisco.com>mailto:mat@cisco.com]  
>> > > Sent: Thursday, December 28, 2000 2:03 PM  
>> > > To: seamoby@diameter.org  
>> > > Cc: Dave Oran; mankin@east.isi.edu  
>> > > Subject: [seamoby] cart-before-seamoby  
>> > >  
>> > > 
>> > > 
>> > > I really wonder why we ended up with three design  
>> > > teams. I have no particular issue with the paging  
>> > > team, but it seems to me that it's really  
>> > > inappropriate to start thinking about context  
>> > > transfer isolated from what the overall  
>> > > requirements are. I assume that the goal of the  
>> > > [sic] "micro-mobility" design team is to come up  
>> > > with some set of scenarios which seamoby needs to  
>> > > consider, derive some requirements, and hopefully  
>> > > determine what the actual protocol work that needs  
>> > > to be done as well as a partition as to what  
>> > > seamoby should work on versus other working  
>> > > groups.  
>> > >  
>> > > While it seems pretty obvious that some sort of  
>> > > context transfer and forward tunnel establishment  
>> > > needs to be provided for, it's not at all clear to  
>> > > me that we should be looking to solve those  
>> > > problems without considering the framework that  
>> > > comes out of the other work; indeed, it seems  
>> > > likely to cause even more confusion.  
>> > >  
>> > >             Mike  
>> > >  
>> > 
>
>
>
>
> Michael A. Ramalho, Ph.D.
> Office email: mramalho@cisco.com
> Personal email: mar42@cornell.edu
> Office: +1.732.449.5762
> Cell: +1.732.809.0188
> Pager: +1.800.365.4578 
--=====================_9477497==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Kulwinder,<br>
<br>
I have few comments/questions below.<br>
<br>
I would like to thank you for providing enough background<br>
information for me to comment on.<br>
<br>
Please take my comments as constructive comments and/or<br>
questions ... I've included a lot of commentary whose purpose<br>
is to help clarify seamoby assumptions ... I am specifically<br>
trying not to flame you. Sometimes that is hard to tell via email
:-).<br>
<br>
Michael Ramalho<br>
<br>
At 06:40 PM 12/29/00 -0500, Kulwinder Atwal wrote: <br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>Thankyou
for making me aware of some the SeaMoby history.</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">The reason that I agree with
Mike's observation is that have not heard </font><br>
the discussions mention two things: Time Scale and RF Energy
Gradient.</blockquote><br>
These seem to be related to a particular network technology, right?<br>
<br>
That is ... given a network (radio/spectrum) design ... then
&quot;network<br>
handoff triggers&quot; are determined by the network designers ... and
these<br>
triggers can use such information to help determine when the<br>
&quot;triggering events&quot; should be requested, right?<br>
<br>
There is nothing in our draft-blair-rt-mobileipv6-seamoby that
precludes<br>
such measurement or *network* triggering events.<br>
<br>
What our draft includes is other triggering events potentially
generated<br>
by the mobile for the case where it desires to move to either a<br>
different link layer technology (potentially provided by the same<br>
or different service provider) or the same link layer technology<br>
provided by another service provider.<br>
<br>
For the case where the mobile can listen on more than one radio<br>
interface/technology ... the *seamless* make-before-break case is<br>
more likely ... and the &quot;handoff decision&quot; heuristic (based on
these<br>
&quot;handoff triggers&quot;) can be based on whatever information the
network<br>
or mobile decides to use.<br>
<br>
For the case where the mobile can only listen/tune to one radio<br>
technology/frequency at a given time AND there is *not* sufficient
overlap<br>
of the coverage (of the present service provider) ... then 
*specific<br>
technology link layer metrics* (as I presume the RF gradient<br>
stuff is) is essential to the *design or layout* of the
network/spectrum.<br>
<br>
Of course, the design is, in turn, dependent upon how 
fast/efficient<br>
the context transfer mechanism is ... so there is some circularity<br>
in the argument ... but only FOR THE CASE OF NOT SUFFICEINT<br>
COVERAGE OVERLAP AND ONLY ONE RADIO/TUNER. This is<br>
an important case in the present ... but likely less so in the
future.<br>
<br>
In the future, I hope that:<br>
<br>
1) a given volume will either be covered by more than one 
technology<br>
and/or service provider, and<br>
2) that mobile devices can listen/tune to more than one radio
technology<br>
at a given time (heck ... even my car radio is really two radios,
using<br>
diversity technology to decide which signal is stronger!).<br>
<br>
Lets make sure that seamoby accommodates the &quot;single
radio/coverage&quot;<br>
case above ... but let us not optimize for it alone. Please.<br>
<br>
<blockquote type=cite cite>&nbsp;<br>
<font face="arial" size=2 color="#0000FF">The time scale of events will
determine what parts of the context need to be</font><br>
&nbsp;transferred when, what paging messages need to be sent and when,
and what <br>
the structure of the hand-off needs to be.&nbsp; Since I am new, maybe
this info <br>
is in some document I have yet to read.&nbsp; At the chance of
re-hashing, <br>
I will expand on what I mean by Time Scale and RF Energy Gradient.<br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">In the draft Realtime Mobile
IPv6 Framework looking at the first diagram, I have </font><br>
noticed that the overall view of the network is in the static physical
domain.&nbsp; <br>
In real-time systems if we what to maximize the efficient use of
available system<br>
&nbsp;bandwidth the overall view has to be in time domain.&nbsp; We need
to do the right <br>
thing at the right time in the right place.&nbsp; </blockquote><br>
We have examples in the Appendix of particular handoff movements 
and<br>
examples of how to transfer context for these cases. The sequencing<br>
of events are important .... particularly so for a particular technology
under<br>
consideration. But this is a design issue for a particular technology
(thus<br>
these examples were put in our appendix ... and not a cornerstone of
our<br>
framework draft itself).<br>
<br>
I hope that seamoby defines a kind of framework or unified design
principles<br>
that can be applied to particular technologies. That is ... we need to
understand<br>
the constraints of present technologies ... but not necessarily optimize
around<br>
one of them at the *potential* expense of de-optimizing a lot of other
link<br>
layer technologies.<br>
<br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>Let
me expand on the time scales that </font><br>
are relevant to this problem.<br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Radio Map Time Scale:&nbsp; The
time it takes to traverse at least three endpoint service
areas.</font></blockquote><br>
What is an &quot;endpoint service area&quot;? Sounds like a particular
network technology<br>
to me.<br>
<br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>This
is different than a Trusted Domain as we are talking about the nearest
three endpoints</font><br>
&nbsp;in the hetro net.&nbsp; ( Time Scale is : ~ minute
minumum)</blockquote><br>
A Trust Domain was defined as it is likely to effect whether the
context<br>
from elements in one trust domain will be accepted by another. It has
nothing to<br>
do with latency between access routers/APs ... only with security/trust
relationships.<br>
<br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>Endpoint
Service Area Time Scale:&nbsp; The time it takes to traverse the service
area of an</font><br>
endpoint.&nbsp; ( Time Scale is: ~ 10 seconds minumum)</blockquote><br>
Isn't this related to the assumed movement of the mobile and the
size<br>
of the coverage area (e.g., cell) .... that is ... a *network design*
issue.<br>
For a particular *network design* this is important.<br>
<br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>Real-Time
Time Scale: The time that it takes for a video stream to lose its
real-time </font><br>
behaviour.&nbsp; ( Time Scale is: &lt; = 10
milliseconds)</blockquote><br>
Why is video significantly different from other interactive modes of
communications<br>
(e.g., voice)?<br>
<br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>Mobile
Node Switch Time:&nbsp; The time that it takes for a mobile node to
switch frequencies.</font><br>
( Time Scale is: ~ microseconds)<br>
</blockquote><br>
Sounds again like you are assuming the single frequency/technology case.
Why<br>
should this case *alone* significantly drive seamoby design? I think it
is an important<br>
case to study ... especially for present designs ... but not necessarily
to optimize<br>
about.<br>
<br>
<blockquote type=cite cite>&nbsp;<br>
<font face="arial" size=2 color="#0000FF">So the overall goal for all the
teams is to push decision making and packet transfers toward the
</font><br>
Radio Map time scale, and pre-configure where ever and when ever
possible.<br>
</blockquote><br>
Network handoff decision heuristics can drive the handoff process .. but
we should<br>
*not* limit our discussion in seamoby to only this case. More 
below.<br>
<br>
<blockquote type=cite cite>&nbsp;<br>
<font face="arial" size=2 color="#0000FF">RF Energy 
Gradient:</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">In Pro-active hand-off we must
ask &quot;In our current direction of travel where will be the next
strongest signal.&quot;&nbsp; What we need is for&nbsp; APs to tell us
is, how is our signal changing over time as we travel on our current
path.&nbsp; This is the RF Energy Gradient.&nbsp; </font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">RF Energy Gradient = change in
RSSI / change in time</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">What we need is for the APs to
measure the MN RSSI at two points in time and send it to the mobile
node.&nbsp; Since the mobile node will most likely travel to the same
places every day, the mobile node can store the QoS values for the
APs.&nbsp; When a mobile node enters an area it can send the last GUID it
had for the area to see if the radio map has changed.&nbsp; </font><br>
&nbsp;</blockquote><br>
Fine ... engineering a particular network technology to measure these
things are<br>
precisely what equipment manufacturers design. Is there any reason why
access points<br>
that service a particular network technology uses cannot communicate this
information<br>
to the point(s) in the network responsible for the (network, in your
case) decision.<br>
<br>
That is, what of the above discussion is required to be specified by
seamoby?<br>
<br>
We have a lot of signaling transport and control protocols at our
disposal for<br>
this .... I see no reason why seamoby needs to (re)specify them.<br>
<br>
In other words ... seamoby should not specify *network design* ... the
market<br>
will decide which manufacturers/designs work the best .... or other
standards<br>
bodies will offer design recommendations ... I think seamoby should steer
clear<br>
of such political rat-holes!<br>
<br>
Again, I'd like to thank Kulwinder for the opportunity to comment ... but
these<br>
comments highlight the need for a seamoby &quot;problem statement&quot;
that we<br>
can all rally behind.<br>
<br>
My hope is that such a problem statement will not suggest to the world
that<br>
we are effectively re-designing (ONLY) cellular network behavior over IP.
I would<br>
like equipment manufacturers to do that specific job .. preferably
using<br>
(unified) design principles that are in seamoby's charter or framework
document.<br>
<br>
Stepping off my soapbox.<br>
<blockquote><font face="tahoma" size=2><blockquote type=cite cite>
<dl>
<dd>-----Original Message-----
<dd>From:</b> Gary Kenward
[<a href="mailto:gkenward@nortelnetworks.com" eudora="autourl">mailto:gkenward@nortelnetworks.com</a>]
<dd>Sent:</b> Friday, December 29, 2000 5:01 PM
<dd>To:</b> 'Kulwinder Atwal'; seamoby@diameter.org
<dd>Subject:</b> RE: [seamoby] cart-before-seamoby<br>
<br>
</font>
<dd>You've missed the point, Kulwinder. The SeaMoby wg is tasked with
writing <font size=2>
<dd>problem statements for the three identified areas of concern, paging,
micro-</font> <font size=2>
<dd>mobility and context handoff. As far as I know, the ADs are also
looking for</font> <font size=2>
<dd>these problem statements.</font> <br>
<br>
<font size=2>
<dd>Since the CRAPS BOF, the collection of people contributing to this
area have had</font> <font size=2>
<dd>a rough time convincing the IETF at large that there are real
problems to solve. </font>
<dd>Algorithms, protocols, etc., are all well and good, but the working
group will not <font size=2>
<dd>proceed without the problem statements. Whether it is one or three
problem</font> <font size=2>
<dd>statements is moot at this point. The working group consensus was to
produce </font>
<dd>three problem statements. Maybe once this has been completed, we can
combine 
<dd>the three into one, if that is considered a useful exercise. <br>
<br>
<font size=2>
<dd>I happen to agree with the observation that if we cannot collectively
agree</font> <font size=2>
<dd>on a definition of the problem, then we don't have much hope of ever
agreeing</font> <font size=2>
<dd>on a solution. Regardless, do not flame the messenger, it was not my
decision.</font> <br>
<br>
<font size=2>
<dd>Gary</font> <br>
<br>
<font size=2>
<dd>&gt; -----Original Message-----</font> <font size=2>
<dd>&gt; From: Kulwinder Atwal
[<a href="mailto:kulwinder.atwal@zucotto.com">mailto:kulwinder.atwal@zucotto.com</a>]</font>
<font size=2>
<dd>&gt; Sent: Thursday, December 28, 2000 4:05 PM</font> <font size=2>
<dd>&gt; To: 'Michael Thomas'; seamoby@diameter.org</font> 
<font size=2>
<dd>&gt; Cc: Dave Oran; mankin@east.isi.edu</font> <font size=2>
<dd>&gt; Subject: RE: [seamoby] cart-before-seamoby</font> <font size=2>
<dd>&gt; </font>
<dd>&gt; 
<dd>&gt; I have been having the same thoughts.&nbsp; I am of the opinion 
<dd>&gt; that without an <font size=2>
<dd>&gt; algorithm we can only agree to disagree.&nbsp; That is why I have </font>
<dd>&gt; not made any <font size=2>
<dd>&gt; further input on context transfer, and instead I have been </font>
<dd>&gt; thinking on how <font size=2>
<dd>&gt; to do just pro-active RF switching among dynamic hetro nets.&nbsp; </font>
<dd>&gt; I have written <font size=2>
<dd>&gt; a two page outline for an algorithm on how to do the </font>
<dd>&gt; pro-active switching <font size=2>
<dd>&gt; initiated by the MN across hetro nets using RSSI.&nbsp; I will </font>
<dd>&gt; work on it for <font size=2>
<dd>&gt; another day, or so before putting it out there to the wolves. </font>
<dd>&gt;&nbsp; Then at least <font size=2>
<dd>&gt; we will have a starting point.</font> <font size=2>
<dd>&gt; </font>
<dd>&gt; - Kulwinder.&nbsp; 
<dd>&gt; 
<dd>&gt; &gt; -----Original Message----- <font size=2>
<dd>&gt; &gt; From: Michael Thomas [<a href="mailto:mat@cisco.com">mailto:mat@cisco.com</a>]</font> <font size=2>
<dd>&gt; &gt; Sent: Thursday, December 28, 2000 2:03 PM</font> <font size=2>
<dd>&gt; &gt; To: seamoby@diameter.org</font> <font size=2>
<dd>&gt; &gt; Cc: Dave Oran; mankin@east.isi.edu</font> <font size=2>
<dd>&gt; &gt; Subject: [seamoby] cart-before-seamoby</font> <font size=2>
<dd>&gt; &gt; </font>
<dd>&gt; &gt; 
<dd>&gt; &gt; 
<dd>&gt; &gt; I really wonder why we ended up with three design <font size=2>
<dd>&gt; &gt; teams. I have no particular issue with the paging</font> <font size=2>
<dd>&gt; &gt; team, but it seems to me that it's really</font> <font size=2>
<dd>&gt; &gt; inappropriate to start thinking about context</font> <font size=2>
<dd>&gt; &gt; transfer isolated from what the overall</font> <font size=2>
<dd>&gt; &gt; requirements are. I assume that the goal of the</font> <font size=2>
<dd>&gt; &gt; [sic] &quot;micro-mobility&quot; design team is to come up</font> <font size=2>
<dd>&gt; &gt; with some set of scenarios which seamoby needs to</font> <font size=2>
<dd>&gt; &gt; consider, derive some requirements, and hopefully</font> <font size=2>
<dd>&gt; &gt; determine what the actual protocol work that needs</font> <font size=2>
<dd>&gt; &gt; to be done as well as a partition as to what</font> <font size=2>
<dd>&gt; &gt; seamoby should work on versus other working</font> <font size=2>
<dd>&gt; &gt; groups.</font> <font size=2>
<dd>&gt; &gt; </font>
<dd>&gt; &gt; While it seems pretty obvious that some sort of <font size=2>
<dd>&gt; &gt; context transfer and forward tunnel establishment</font> <font size=2>
<dd>&gt; &gt; needs to be provided for, it's not at all clear to</font> <font size=2>
<dd>&gt; &gt; me that we should be looking to solve those</font> <font size=2>
<dd>&gt; &gt; problems without considering the framework that</font> <font size=2>
<dd>&gt; &gt; comes out of the other work; indeed, it seems</font> <font size=2>
<dd>&gt; &gt; likely to cause even more confusion.</font> <font size=2>
<dd>&gt; &gt; </font>
<dd>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mike <font size=2>
<dd>&gt; &gt; </font>
<dd>&gt; </blockquote>
</dl><br>
<br>
<br>
<div>Michael A. Ramalho, Ph.D.</div>
<div>Office email: mramalho@cisco.com</div>
<div>Personal email: mar42@cornell.edu</div>
<div>Office: +1.732.449.5762</div>
<div>Cell: +1.732.809.0188</div>
Pager: +1.800.365.4578
</html>

--=====================_9477497==_.ALT--



From owner-seamoby@diameter.org  Wed Jan  3 12:55:07 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00064
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 12:55:06 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03H2ZX03352
	for seamoby-list; Wed, 3 Jan 2001 09:02:35 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03H2XW03347
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 09:02:33 -0800
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA07170;
	Wed, 3 Jan 2001 08:09:59 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA29528;
	Wed, 3 Jan 2001 08:09:58 -0800 (PST)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA10079;
	Wed, 3 Jan 2001 08:09:58 -0800 (PST)
Message-Id: <200101031609.IAA10079@nasnfs.eng.sun.com>
Date: Wed, 3 Jan 2001 08:10:11 -0800 (PST)
From: James Kempf <James.Kempf@eng.sun.com>
Reply-To: James Kempf <James.Kempf@eng.sun.com>
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
To: James.Kempf@eng.sun.com, mruckstuhl@MeshNetworks.com,
        kulwinder.atwal@herc.zucotto.com, seamoby@diameter.org,
        kulwinder.atwal@zucotto.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: O3o23IumDgWoMDGQ+t8b+w==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Kulwinder,

My understanding from the presentation given several IETFs back is that IP over 
Bluetooth will use PPP. Please correct me if I am wrong on this point. PPP is a 
long way above the details of the L1 protocol that you have presented below, if 
I recall from the presentation correctly, and so would not be able to make 
direct use of this refined slot scheme. Given that, I don't quite see
the problem with doing SAR. It would have to be fitted into L2/L2.5
somewhere.

Or am I missing something?

		jak

>From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
>To: "'James Kempf'" <James.Kempf@eng.sun.com>, mruckstuhl@meshnetworks.com, 
kulwinder.atwal@herc.zucotto.com, seamoby@diameter.org
>Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
>Date: Wed, 3 Jan 2001 10:52:29 -0500 
>MIME-Version: 1.0
>
>I was waiting for this question.
>Here we go.
>
>If we say that real-time is 10 mSec, then in 10mSec Bluetooth has a total of
>8 Master/Slave slot pairs.
>
>A Master/Slave slot pair is composed of one Master TX slot and one Slave TX
>slot. A slot is 625 microseconds.  A slot Master/Slave slot pair is two of
>these, or 1.25 milliseconds.
>
>There is a max of seven active slaves on a Bluetooth net. 
>( 1.25 mSec x 7 = 8.75 mSec)
>
>Therefore, if we want all slaves to have the same number of slots, then we
>have one Master/Slave slot pair left over.  It is this pair that we can use
>to do seamless mobility in real-time (10 mSec).
>
>So, the phrase to focus on is "Real-time seamless mobility".
>
>Of course, we can do IP SAR to all seven MNs, but it will not happen in
>real-time.
>
>- Kulwinder. 
>
>> -----Original Message-----
>> From: James Kempf [mailto:James.Kempf@eng.sun.com]
>> Sent: Wednesday, January 03, 2001 8:41 AM
>> To: mruckstuhl@meshnetworks.com; kulwinder.atwal@herc.zucotto.com;
>> seamoby@diameter.org; kulwinder.atwal@herc.zucotto.com
>> Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
>> 
>> 
>> 
>> >> Thus, intra-network handover can be made to maintain some BE 
>> >> support while
>> >> the MN realizes that an inter-network handover is now 
>> required per the
>> >> subscriber's configuration. I think the intra-network 
>> handover is what
>> >> everyone is discussing as micromobility?
>> >
>> >I don't think using IP is a good idea for intra-network hand-off.
>> >Just the IPv6 header is 40 bytes.  The largest single slot 
>> packet that I can
>> >send over Bluetooth has 28 bytes of payload.  This means 
>> that Bluetooth
>> >cannot use IPv6 to do real-time seamless mobility.
>> >
>> 
>> I don't understand this statement. The Bluetooth device simply needs
>> to do segmentation and reassambly. CDMA radio frames are also limited
>> in size, and nobody is suggesting that IPv6 can't be used for
>> mobility on CMDA.
>> 
>> 		jak
>> 



From owner-seamoby@diameter.org  Wed Jan  3 13:30:39 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01122
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 13:30:38 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03HVvp03405
	for seamoby-list; Wed, 3 Jan 2001 09:31:57 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03HVtW03400
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 09:31:55 -0800
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f03GcK114766
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 08:38:20 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104])
	by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f03GdJB16494
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 08:39:19 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 882569C9.005BA6D6 ; Wed, 3 Jan 2001 08:41:04 -0800
X-Lotus-FromDomain: 3COM
From: Phil_Neumiller@3Com.com
To: seamoby@diameter.org
Message-ID: <882569C9.005B82CA.00@hqoutbound.ops.3com.com>
Date: Wed, 3 Jan 2001 10:45:07 -0600
Subject: [seamoby] Micromobility Problem Statement ISSUE 1
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-seamoby@diameter.org
Precedence: bulk



Nothing stays homogeneous very long.  The beauty of an IP based solution
is that it can evolve seperately from air interfaces.  The WHOLE point here is
take things that are "commonly done" by a majority of air interfaces to enact
micro
mobility, and place this over IP.  This way a new radio interface can be easily
 plopped in to an old system without breaking the signalling.  This is the most
important design principle for micro-mobility I can think of.

PROBLEM STATEMENT ISSUE 1
Existing air interfaces have a tendency to do the same things in different ways.
Our collective experience with many air interfaces over time has lead us to
believe that micro-mobility can be implemented as an IP based protocol.
This will allow air interface technology to evolve seperately from the handoff
algorithms that are deployed.




Sent by:  Kulwinder Atwal <kulwinder.atwal@zucotto.com>


To:   "'Mika Ylianttila'" <over@ees2.oulu.fi>, seamoby@diameter.org
cc:    (Phil Neumiller/MW/US/3Com)
Subject:  RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001



No, it just seems like a waste of effort.  Someone has to show me the real
value of doing this on a homogenous net.  Since we are talking about
real-time preformance, it would take time to compress/decompress.  If I can
do it without compression and get the same value I will.

- Kal.

> -----Original Message-----
> From: Mika Ylianttila [mailto:over@ees2.oulu.fi]
> Sent: Wednesday, January 03, 2001 6:13 AM
> To: seamoby@diameter.org
> Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
>
>
> On Wed, 3 Jan 2001, Kulwinder Atwal wrote:
>
> >I don't think using IP is a good idea for intra-network hand-off.
> >Just the IPv6 header is 40 bytes.  The largest single slot
> packet that I can
> >send over Bluetooth has 28 bytes of payload.  This means
> that Bluetooth
> >cannot use IPv6 to do real-time seamless mobility.
>
>   Did you forget the possibility for header compression?  ;)
>
> --
> Mika Ylianttila
> M.Sc., Project Manager
> Centre for Wireless Communications
> PL 4500, Tutkijantie 2 E, FIN-90014
> University of Oulu, Finland
>
>






From owner-seamoby@diameter.org  Wed Jan  3 14:01:26 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02043
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 14:01:26 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03Hv1403452
	for seamoby-list; Wed, 3 Jan 2001 09:57:01 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03HuxW03447
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 09:56:59 -0800
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f03H3T122693
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 09:03:29 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104])
	by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f03H4SB22627
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 09:04:28 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 882569C9.005DF5DC ; Wed, 3 Jan 2001 09:06:17 -0800
X-Lotus-FromDomain: 3COM
From: Phil_Neumiller@3Com.com
To: seamoby@diameter.org
Message-ID: <882569C9.005DF2EE.00@hqoutbound.ops.3com.com>
Date: Wed, 3 Jan 2001 11:10:15 -0600
Subject: [seamoby] Micromobility Problem Statement ISSUE 2
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-seamoby@diameter.org
Precedence: bulk




In IPv6 or IPv4 networks, the mobility agents are probably 2+ hops up
stream in the router chain inside a given administrative domain.  Many
quick decisions must be made in milliseconds with respect to handoff
and mobility.  The Mobile node, and the access point/router have a
better perspective on the local traffic situation (QoS), security, and
compression, etc.  Thus, these devices are in the best position to
make decisions  about adding links, m-casting, context transfer etc.
Furthermre, this implies that the  SeaMoby protocol should reside in
MNs, and AP/Rs and work in conjunction with MIPv4 or MIPv6 when
subnet routing boundaries are crossed.   This also has the desirable
effect of moving intelligence to the "edge" where we can avoid
redundancy and assure global scalability.




From owner-seamoby@diameter.org  Wed Jan  3 14:05:57 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02174
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 14:05:56 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03I3I103479
	for seamoby-list; Wed, 3 Jan 2001 10:03:18 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03I3FW03474
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 10:03:15 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <ZJFR848H>; Wed, 3 Jan 2001 12:10:50 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B68@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'James Kempf'" <James.Kempf@eng.sun.com>, mruckstuhl@MeshNetworks.com,
        seamoby@diameter.org
Subject: RE: FW: [seamoby] Context transfer problem statement
Date: Wed, 3 Jan 2001 12:10:41 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C075A8.1E9EC07B"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C075A8.1E9EC07B
Content-Type: text/plain;
	charset="iso-8859-1"

 

-----Original Message-----
From: Kulwinder Atwal 
Sent: Thursday, December 28, 2000 7:42 AM
To: 'Gary Kenward'; 'Kulwinder Atwal'; 'Phil_Neumiller@3com.com'; Shahrier,
Sharif M.; seamoby@diameter.org
Subject: RE: FW: [seamoby] Context transfer problem statement



-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Wednesday, December 27, 2000 2:05 PM
To: 'Kulwinder Atwal'; 'Phil_Neumiller@3com.com'; Shahrier, Sharif M.;
seamoby@diameter.org
Subject: RE: FW: [seamoby] Context transfer problem statement



Kulwinder: 

   You make an important point about Bluetooth. I'm not sure that you
address Phil's 
point, but he can respond himself. I do, however, believe that Phil, and
others share 
your dream, at least in part. 

   You refer to a PDA to laptop link as a network. It is my impression that
Bluetooth 
does not have the capability (yet) to support networking (discovery,
routing, forwarding, 
security, etc.). Am I mistaken?  

Discovery: SDP - Service Discovery Protocol.  The IETF SLP is on its way to
becoming a Profile.  Therefore SLP can replace SDP at your option.

Routing: L2CAP if you want it, or make your own.

Routing is only to a particular slave. 

Security:  

- 128 bit PIN code

- Link Key: Never transmitted over the air.  Both devices must agree in
advance on how to locally generate link keys. (ie: have same encryption
software).

- Some of the Host Controller Commands relating to security: 

Link_Key_Request: ( Request other device to locally generate and use a new
key on its end)

Link_Key_Request_Reply:

Link_Key_Request_Negative_Reply:

 

PIN_Code_Request: upto 128 bits

PIN_Key_Request_Reply:

PIN_Key_Request_Negative_Reply:

Authentication_Requested

Set_Connection_Encryption

Master Link Key:( request that master use a temporary Link for broadcast. Or
semi-permanant Link Key for private encrypted point-to-point comms)

This is further detailed in Part H1: Host Controller Interface Functional
Specification of the Core Bluetooth Spec on the bluetooth.com site.

Bluetooth has the functionality to support security.  It is left upto
implementors and users to develop/pick the right software.

I fully agree that Bluetooth does not have the full functionality of the
Internet.  

BTW, I just read the Q&A, and looked at the slides for the Pittsburgh BOF on
the IETF site.  I have come to the conclusion that:There are lies, damned
lies, and then there is PowerPoint.  It is obvious to me that the info in
the IETF BOF was inaccurate, misleading, and incorrect.  The people there
had a very superficial understanding of the upper stack, and zero
understanding of the lower stack.  

The LAN profile is profile and as such is completely and totally optional.
Therefore, it is completely inappropriate for them to use words like the
profile "Mandates".  Or, make statements like "if you want to run IP over
Bluetooth 1.0, this is the required way to support it!".  Because, tomorrow
I can come up with my own profile that is the complete opposite, and if I so
choose, have it approved by the SIG.  There is currently an explosion of
profiles in the SIG.  It should read, "This is how this particular profile
implements IP over Bluetooth".  The only requirement is that for every
"client" stack on one side that there exists a similiar "server" stack on
the other side for the "client" to have something to talk to.  Or, simply
that you need the same driver on both ends.  This is nothing new to anyone
in the IETF. (Networking 101)  

I got the impression that they did not read the spec, other than looking at
some of the pictures and tables.  They were probably product management or
marketing types.  Pravin, from AT&T mentions that there exists a Host
Controller but spends no time talking about it.  Yet, there is over 300
pages in the spec detailing the Host Controller Interface.  No other single
entity is afforded this much space in the spec.  It is fully intended to be
used a stand-alone device.  The spec talks about how the Host Controller can
be placed in a PC Card by itself.  It even has a picture.  The spec also
refers to "personal" devices that can be pre-programmed to respond only to
one other device.  Such devices may want to use their own manufacturer
specific protocol and a Host Controller.

 

What I would like to find is the most efficient way to connect the Host
Controller (Link Manager\Link Controller\BaseBand\Radio) to IP.

The routing and forwarding function, I think would best be handled by an
IP/Bluetooth endpoint connected to the rest of the IP network by landline.
This endpoint would have at least a protocol handler to interface to the
Host Controller and at least one Host Controller.

Something like:

Network Layer: IP

Logical Link Layer: SeaMoby

Physical Link Layer: Bluetooth Host Controller

It would be nice to do another BOF, so that the IETF can find out the truth
from the people who have actually read the spec.   

A little knowledge, and some PowerPoint is a dangerous thing. 

- Kulwinder.

 


------_=_NextPart_001_01C075A8.1E9EC07B
Content-Type: text/html;
	charset="iso-8859-1"

<!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: FW: [seamoby] Context transfer problem statement</TITLE>

<META content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD>
<BODY>
<DIV>&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> Kulwinder Atwal 
  <BR><B>Sent:</B> Thursday, December 28, 2000 7:42 AM<BR><B>To:</B> 'Gary 
  Kenward'; 'Kulwinder Atwal'; 'Phil_Neumiller@3com.com'; Shahrier, Sharif M.; 
  seamoby@diameter.org<BR><B>Subject:</B> RE: FW: [seamoby] Context transfer 
  problem statement<BR><BR></FONT></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:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, December 27, 
    2000 2:05 PM<BR><B>To:</B> 'Kulwinder Atwal'; 'Phil_Neumiller@3com.com'; 
    Shahrier, Sharif M.; seamoby@diameter.org<BR><B>Subject:</B> RE: FW: 
    [seamoby] Context transfer problem statement<BR><BR></FONT></DIV>
    <P><FONT size=2>Kulwinder:</FONT> </P>
    <P><FONT size=2>&nbsp;&nbsp; You make an important point about Bluetooth. 
    I'm not sure that you address Phil's</FONT> <BR><FONT size=2>point, but he 
    can respond himself. I do, however, believe that Phil, and others 
    share</FONT> <BR><FONT size=2>your dream, at least in part.</FONT> </P>
    <P><FONT size=2>&nbsp;&nbsp; You refer to a PDA to laptop link as a network. 
    It is my impression that Bluetooth</FONT> <BR><FONT size=2>does not have the 
    capability (yet) to support networking (discovery, routing, 
    forwarding,</FONT> <BR><FONT size=2>security, etc.). Am I 
    mistaken?</FONT>&nbsp;<SPAN class=693454208-28122000><FONT face=Arial 
    color=#0000ff size=2>&nbsp;</FONT></SPAN></P>
    <P><SPAN class=693454208-28122000><FONT face=Arial color=#0000ff 
    size=2>Discovery: SDP - Service&nbsp;Discovery Protocol.&nbsp; The IETF SLP 
    is on its way to becoming a Profile.&nbsp; Therefore SLP can replace SDP at 
    your option.</FONT></SPAN></P>
    <P><SPAN class=693454208-28122000><FONT face=Arial color=#0000ff 
    size=2>Routing: L2CAP if you want it, or make your own.</FONT></SPAN></P>
    <P><SPAN class=693454208-28122000><FONT face=Arial color=#0000ff 
    size=2>Routing is only to a particular slave.&nbsp;</FONT></SPAN></P>
    <P><SPAN class=693454208-28122000><FONT face=Arial color=#0000ff 
    size=2>Security:&nbsp; </FONT></SPAN></P>
    <P><SPAN class=693454208-28122000><FONT face=Arial color=#0000ff size=2>- 
    128 bit PIN code</FONT></SPAN></P>
    <P><SPAN class=693454208-28122000><FONT face=Arial color=#0000ff size=2>- 
    Link Key: Never transmitted over the air.&nbsp; Both devices must agree in 
    advance on how to locally generate link&nbsp;keys. (ie: have same encryption 
    software).</FONT></SPAN></P>
    <P><SPAN class=693454208-28122000><FONT face=Arial color=#0000ff size=2>- 
    Some of the Host Controller Commands relating to security: 
</FONT></SPAN></P>
    <P><SPAN class=693454208-28122000><FONT face=Arial color=#0000ff 
    size=2>Link_Key_Request: ( Request other device to locally generate and use 
    a new key on its end)</FONT></SPAN></P>
    <P><SPAN class=693454208-28122000><FONT face=Arial color=#0000ff 
    size=2><SPAN class=693454208-28122000><FONT face=Arial color=#0000ff 
    size=2>Link_Key_Request_Reply:</FONT></SPAN></FONT></SPAN></P><SPAN 
    class=693454208-28122000><FONT face=Arial color=#0000ff size=2><SPAN 
    class=693454208-28122000>
    <P><SPAN class=693454208-28122000><FONT face=Arial color=#0000ff 
    size=2><SPAN class=693454208-28122000><FONT face=Arial color=#0000ff 
    size=2>Link_Key_Request_Negative_Reply:</FONT></SPAN></FONT></SPAN></P></SPAN></FONT></SPAN>
    <P><SPAN class=693454208-28122000>&nbsp;</P>
    <P><SPAN class=693454208-28122000><FONT face=Arial color=#0000ff 
    size=2>PIN_Code_Request: upto 128 bits</FONT></SPAN></P>
    <P><SPAN class=693454208-28122000><FONT face=Arial color=#0000ff 
    size=2><SPAN class=693454208-28122000><FONT face=Arial color=#0000ff 
    size=2>PIN_Key_Request_Reply:</FONT></SPAN></FONT></SPAN></P><SPAN 
    class=693454208-28122000><FONT face=Arial color=#0000ff size=2><SPAN 
    class=693454208-28122000>
    <P><SPAN class=693454208-28122000><FONT face=Arial color=#0000ff 
    size=2><SPAN class=693454208-28122000><FONT face=Arial color=#0000ff 
    size=2>PIN_Key_Request_Negative_Reply:</FONT></SPAN></FONT></SPAN></P></SPAN></FONT></SPAN>
    <P><SPAN class=693454208-28122000><FONT face=Arial color=#0000ff 
    size=2>Authentication_Requested</FONT></SPAN></P>
    <P><SPAN class=693454208-28122000><FONT face=Arial color=#0000ff 
    size=2>Set_Connection_Encryption</FONT></SPAN></P>
    <P><SPAN class=693454208-28122000><FONT face=Arial color=#0000ff 
    size=2>Master Link Key:( request that master use a temporary Link for 
    broadcast. Or s</FONT></SPAN><SPAN class=693454208-28122000><FONT face=Arial 
    color=#0000ff size=2>emi-permanant Link Key for private encrypted 
    point-to-point comms)</FONT></SPAN></P></SPAN>
    <P><FONT size=2><SPAN class=693454208-28122000><FONT face=Arial 
    color=#0000ff>This is further detailed in&nbsp;Part H1: Host Controller 
    Interface Functional Specification of the Core Bluetooth Spec on 
    the&nbsp;bluetooth.com site.</FONT></SPAN></FONT></P>
    <P><FONT face=Arial color=#0000ff size=2><SPAN 
    class=693454208-28122000>Bluetooth has the functionality to support 
    security.&nbsp; It is left upto implementors and users to develop/pick the 
    right software.</SPAN></FONT></P>
    <P><FONT face=Arial color=#0000ff size=2><SPAN class=693454208-28122000>I 
    fully agree that Bluetooth does not have the full functionality of the 
    Internet.&nbsp; </SPAN></FONT></P>
    <P><FONT face=Arial color=#0000ff size=2><SPAN class=693454208-28122000>BTW, 
    I just read the Q&amp;A, and looked at the slides for the Pittsburgh BOF on 
    the IETF site.&nbsp;&nbsp;I&nbsp;have come to the conclusion 
    that:There&nbsp;are lies, damned lies, and then there is PowerPoint.&nbsp; 
    It is obvious to&nbsp;me that the info in the IETF BOF was inaccurate, 
    misleading, and incorrect.&nbsp; The people there had a very superficial 
    understanding of the upper stack, and&nbsp;zero understanding&nbsp;of the 
    lower stack.&nbsp; </SPAN></FONT></P>
    <P><FONT face=Arial color=#0000ff size=2><SPAN class=693454208-28122000>The 
    LAN profile is profile and as such is completely 
    and&nbsp;totally&nbsp;optional.&nbsp; Therefore, it is completely 
    inappropriate for them to use words like the profile "Mandates".&nbsp; Or, 
    make statements like "if you want to&nbsp;run IP over Bluetooth 1.0, this is 
    the required way to support it!".&nbsp; Because, tomorrow I can come up with 
    my own profile that is the complete opposite, and&nbsp;if I so choose, have 
    it approved by the SIG.&nbsp; There is currently an explosion of profiles in 
    the SIG.&nbsp; It should read, "This is how this particular profile 
    implements IP over Bluetooth".&nbsp; The only requirement is that for every 
    "client" stack on one side that there exists a similiar "server" stack on 
    the other side for the "client" to have something to talk to.&nbsp; Or, 
    simply that you need the same driver on both ends.&nbsp; This is nothing new 
    to anyone&nbsp;in the IETF. (Networking 101)&nbsp; </SPAN></FONT></P>
    <P><FONT face=Arial color=#0000ff size=2><SPAN class=693454208-28122000>I 
    got the impression that they did not read the spec, other than looking at 
    some of the pictures and tables.&nbsp; They&nbsp;were probably product 
    management or marketing types.&nbsp; Pravin, from AT&amp;T mentions that 
    there exists a Host Controller but spends no time talking about it.&nbsp; 
    Yet, there is over 300&nbsp;pages in the spec detailing the Host Controller 
    Interface.&nbsp; No other single entity is afforded this much space in the 
    spec.&nbsp; It is fully intended to be used a stand-alone device.&nbsp; The 
    spec talks about how&nbsp;the Host Controller&nbsp;can be placed in a PC 
    Card by itself.&nbsp; It even&nbsp;has a picture.&nbsp; The spec&nbsp;also 
    refers to "personal" devices that can be pre-programmed to respond only to 
    one other device.&nbsp; Such devices may want to use their own manufacturer 
    specific protocol and a Host Controller.</SPAN></FONT></P>
    <P><FONT face=Arial color=#0000ff size=2><SPAN 
    class=693454208-28122000></SPAN></FONT>&nbsp;</P>
    <P><FONT face=Arial color=#0000ff size=2><SPAN class=693454208-28122000>What 
    I would like</SPAN></FONT><FONT face=Arial color=#0000ff size=2><SPAN 
    class=693454208-28122000>&nbsp;to find is the most efficient way to connect 
    the Host Controller (Link Manager\Link Controller\BaseBand\Radio) to 
    IP.</SPAN></FONT></P>
    <P><FONT face=Arial color=#0000ff size=2><SPAN class=693454208-28122000>The 
    routing and forwarding function,&nbsp;I think would best be&nbsp;handled by 
    an IP/Bluetooth endpoint connected&nbsp;to the rest of the IP 
    network&nbsp;by landline.&nbsp; This endpoint would have at least a protocol 
    handler to interface to the Host Controller and at least one&nbsp;Host 
    Controller.</SPAN></FONT></P>
    <P><FONT face=Arial color=#0000ff size=2><SPAN 
    class=693454208-28122000>Something like:</SPAN></FONT></P>
    <P><FONT face=Arial color=#0000ff size=2><SPAN 
    class=693454208-28122000>Network Layer: IP</SPAN></FONT></P>
    <P><FONT face=Arial color=#0000ff size=2><SPAN 
    class=693454208-28122000>Logical Link Layer:&nbsp;SeaMoby</SPAN></FONT></P>
    <P><FONT face=Arial color=#0000ff size=2><SPAN 
    class=693454208-28122000>Physical Link Layer: Bluetooth Host 
    Controller</SPAN></FONT></P>
    <P><FONT face=Arial color=#0000ff size=2><SPAN class=693454208-28122000>It 
    would be nice to do another BOF,&nbsp;so that the&nbsp;IETF can find out the 
    truth from the people&nbsp;who have actually read&nbsp;the 
    spec.&nbsp;&nbsp;&nbsp;</SPAN></FONT></P>
    <P><FONT face=Arial color=#0000ff size=2><SPAN class=693454208-28122000>A 
    little knowledge, and some PowerPoint is a dangerous thing. 
    </SPAN></FONT></P>
    <P><FONT face=Arial color=#0000ff size=2><SPAN class=693454208-28122000>- 
    Kulwinder.</SPAN></FONT></P>
    <P><FONT size=2></FONT>&nbsp;</P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C075A8.1E9EC07B--


From owner-seamoby@diameter.org  Wed Jan  3 14:43:35 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02993
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 14:43:34 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03I8Vn03489
	for seamoby-list; Wed, 3 Jan 2001 10:08:31 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03I8SW03484
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 10:08:28 -0800
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id JAA13954;
	Wed, 3 Jan 2001 09:12:33 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA20420; Wed, 3 Jan 2001 09:12:33 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14931.23937.269455.481693@thomasm-u1.cisco.com>
Date: Wed, 3 Jan 2001 09:12:33 -0800 (PST)
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: Michael Thomas <mat@cisco.com>, Gary Kenward <gkenward@nortelnetworks.com>,
        "'James Kempf'" <James.Kempf@eng.sun.com>, Phil_Neumiller@3Com.com,
        dblair@cisco.com, seamoby@diameter.org
Subject: RE: [seamoby] Micromobility Problem Statement
In-Reply-To: <Roam.SIMC.2.0.6.978534909.15724.pcalhoun@nasnfs>
References: <Roam.SIMC.2.0.6.978533696.31572.pcalhoun@nasnfs>
	<Roam.SIMC.2.0.6.978534909.15724.pcalhoun@nasnfs>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


I'm not sure what you're asking us to do here.
From my standpoint, if QoS cannot be reestablished
in a timely fashion for real time traffic, then
you cannot have seamless mobility for the most
important case and we might as well pick up our
marbles and go home. Others don't think that QoS
is important at all. Still others aren't up to
speed as to where the actual gaps are with current
IETF protocols.

So, like, what now? This doesn't seem like an
argument over the solution space so much as an
argument over relevance.

	       Mike

Pat Calhoun writes:
 > <chair hat>
 > As I wade through the countless e-mails in my never ending inbox, I find
 > myself easily led into QOS discussions, and what should be the signaling
 > method to get micromobility. However, I think that we should all focus our
 > efforts on getting the actual problem statement (hey, look at the subject of
 > this e-mail). I think that Dana's goal was to get the problem statement work
 > started, and instead this thread has degrated into the solution space.
 > 
 > Could we continue with the task of defining what the problem is that we are
 > trying to solve? </chair hat>
 > 
 > PatC
 > 
 > 


From owner-seamoby@diameter.org  Wed Jan  3 14:43:43 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03004
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 14:43:42 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03I2Rm03470
	for seamoby-list; Wed, 3 Jan 2001 10:02:27 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03I2PW03465
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 10:02:25 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <ZJFR8481>; Wed, 3 Jan 2001 12:10:00 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B67@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'James Kempf'" <James.Kempf@eng.sun.com>, mruckstuhl@MeshNetworks.com,
        kulwinder.atwal@herc.zucotto.com, seamoby@diameter.org
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
Date: Wed, 3 Jan 2001 12:09:54 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk



> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@eng.sun.com]
> Sent: Wednesday, January 03, 2001 11:10 AM
> To: James.Kempf@eng.sun.com; mruckstuhl@meshnetworks.com;
> kulwinder.atwal@herc.zucotto.com; seamoby@diameter.org;
> kulwinder.atwal@herc.zucotto.com
> Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
> 
> 
> Kulwinder,
> 
> My understanding from the presentation given several IETFs 
> back is that IP over 
> Bluetooth will use PPP. Please correct me if I am wrong on 
> this point.

This PPP/RFCOMM profile is completely optional, and should be viewed as 
an interm measure.  I would like to work with the IETF to find a better way
to put IP over Bluetooth. The Bluetooth SIG will "Rubber Stamp" it if it
comes from the IETF.  

> PPP is a 
> long way above the details of the L1 protocol that you have 
> presented below, if 
> I recall from the presentation correctly, and so would not be 
> able to make 
> direct use of this refined slot scheme. 

We can create a new profile called the "Roaming" profile.

> Given that, I don't quite see
> the problem with doing SAR. It would have to be fitted into L2/L2.5
> somewhere.

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. 

> 
> Or am I missing something?
> 
> 		jak
> 
> >From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
> >To: "'James Kempf'" <James.Kempf@eng.sun.com>, 
> mruckstuhl@meshnetworks.com, 
> kulwinder.atwal@herc.zucotto.com, seamoby@diameter.org
> >Subject: RE: [seamoby] MicroMobility Algorithm Outline 
> Revision 0.0001
> >Date: Wed, 3 Jan 2001 10:52:29 -0500 
> >MIME-Version: 1.0
> >
> >I was waiting for this question.
> >Here we go.
> >
> >If we say that real-time is 10 mSec, then in 10mSec 
> Bluetooth has a total of
> >8 Master/Slave slot pairs.
> >
> >A Master/Slave slot pair is composed of one Master TX slot 
> and one Slave TX
> >slot. A slot is 625 microseconds.  A slot Master/Slave slot 
> pair is two of
> >these, or 1.25 milliseconds.
> >
> >There is a max of seven active slaves on a Bluetooth net. 
> >( 1.25 mSec x 7 = 8.75 mSec)
> >
> >Therefore, if we want all slaves to have the same number of 
> slots, then we
> >have one Master/Slave slot pair left over.  It is this pair 
> that we can use
> >to do seamless mobility in real-time (10 mSec).
> >
> >So, the phrase to focus on is "Real-time seamless mobility".
> >
> >Of course, we can do IP SAR to all seven MNs, but it will 
> not happen in
> >real-time.
> >
> >- Kulwinder. 
> >
> >> -----Original Message-----
> >> From: James Kempf [mailto:James.Kempf@eng.sun.com]
> >> Sent: Wednesday, January 03, 2001 8:41 AM
> >> To: mruckstuhl@meshnetworks.com; kulwinder.atwal@herc.zucotto.com;
> >> seamoby@diameter.org; kulwinder.atwal@herc.zucotto.com
> >> Subject: RE: [seamoby] MicroMobility Algorithm Outline 
> Revision 0.0001
> >> 
> >> 
> >> 
> >> >> Thus, intra-network handover can be made to maintain some BE 
> >> >> support while
> >> >> the MN realizes that an inter-network handover is now 
> >> required per the
> >> >> subscriber's configuration. I think the intra-network 
> >> handover is what
> >> >> everyone is discussing as micromobility?
> >> >
> >> >I don't think using IP is a good idea for intra-network hand-off.
> >> >Just the IPv6 header is 40 bytes.  The largest single slot 
> >> packet that I can
> >> >send over Bluetooth has 28 bytes of payload.  This means 
> >> that Bluetooth
> >> >cannot use IPv6 to do real-time seamless mobility.
> >> >
> >> 
> >> I don't understand this statement. The Bluetooth device 
> simply needs
> >> to do segmentation and reassambly. CDMA radio frames are 
> also limited
> >> in size, and nobody is suggesting that IPv6 can't be used for
> >> mobility on CMDA.
> >> 
> >> 		jak
> >> 
> 


From owner-seamoby@diameter.org  Wed Jan  3 14:48:29 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03113
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 14:48:28 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03Iec903520
	for seamoby-list; Wed, 3 Jan 2001 10:40:38 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03IeZW03515
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 10:40:35 -0800
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00201;
	Wed, 3 Jan 2001 09:48:04 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA01185;
	Wed, 3 Jan 2001 09:48:03 -0800 (PST)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA13414;
	Wed, 3 Jan 2001 09:48:02 -0800 (PST)
Message-Id: <200101031748.JAA13414@nasnfs.eng.sun.com>
Date: Wed, 3 Jan 2001 09:48:16 -0800 (PST)
From: James Kempf <James.Kempf@eng.sun.com>
Reply-To: James Kempf <James.Kempf@eng.sun.com>
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
To: James.Kempf@eng.sun.com, mruckstuhl@MeshNetworks.com,
        kulwinder.atwal@herc.zucotto.com, seamoby@diameter.org,
        kulwinder.atwal@zucotto.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: RpYybiBILb+q3gVzOhhgmg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Kulwinder,

Thanx for the clarification.

Actually, I don't think this problem is restricted to IPv6. IPv4
suffers from the same problem. 28 bytes is not enough to get
much of a payload across. IPv4 headers are 20 bytes, UDP is 8 bytes,
so the header would have to go in one packet and the payload in
others. SAR would still be required.

I'm going to post a separate message about Bluetooth.

		jak

>From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
>To: "'James Kempf'" <James.Kempf@eng.sun.com>, mruckstuhl@meshnetworks.com, 
kulwinder.atwal@herc.zucotto.com, seamoby@diameter.org
>Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
>Date: Wed, 3 Jan 2001 12:09:54 -0500 
>MIME-Version: 1.0
>
>
>
>> -----Original Message-----
>> From: James Kempf [mailto:James.Kempf@eng.sun.com]
>> Sent: Wednesday, January 03, 2001 11:10 AM
>> To: James.Kempf@eng.sun.com; mruckstuhl@meshnetworks.com;
>> kulwinder.atwal@herc.zucotto.com; seamoby@diameter.org;
>> kulwinder.atwal@herc.zucotto.com
>> Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
>> 
>> 
>> Kulwinder,
>> 
>> My understanding from the presentation given several IETFs 
>> back is that IP over 
>> Bluetooth will use PPP. Please correct me if I am wrong on 
>> this point.
>
>This PPP/RFCOMM profile is completely optional, and should be viewed as 
>an interm measure.  I would like to work with the IETF to find a better way
>to put IP over Bluetooth. The Bluetooth SIG will "Rubber Stamp" it if it
>comes from the IETF.  
>
>> PPP is a 
>> long way above the details of the L1 protocol that you have 
>> presented below, if 
>> I recall from the presentation correctly, and so would not be 
>> able to make 
>> direct use of this refined slot scheme. 
>
>We can create a new profile called the "Roaming" profile.
>
>> Given that, I don't quite see
>> the problem with doing SAR. It would have to be fitted into L2/L2.5
>> somewhere.
>
>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. 
>
>> 
>> Or am I missing something?
>> 
>> 		jak
>> 
>> >From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
>> >To: "'James Kempf'" <James.Kempf@eng.sun.com>, 
>> mruckstuhl@meshnetworks.com, 
>> kulwinder.atwal@herc.zucotto.com, seamoby@diameter.org
>> >Subject: RE: [seamoby] MicroMobility Algorithm Outline 
>> Revision 0.0001
>> >Date: Wed, 3 Jan 2001 10:52:29 -0500 
>> >MIME-Version: 1.0
>> >
>> >I was waiting for this question.
>> >Here we go.
>> >
>> >If we say that real-time is 10 mSec, then in 10mSec 
>> Bluetooth has a total of
>> >8 Master/Slave slot pairs.
>> >
>> >A Master/Slave slot pair is composed of one Master TX slot 
>> and one Slave TX
>> >slot. A slot is 625 microseconds.  A slot Master/Slave slot 
>> pair is two of
>> >these, or 1.25 milliseconds.
>> >
>> >There is a max of seven active slaves on a Bluetooth net. 
>> >( 1.25 mSec x 7 = 8.75 mSec)
>> >
>> >Therefore, if we want all slaves to have the same number of 
>> slots, then we
>> >have one Master/Slave slot pair left over.  It is this pair 
>> that we can use
>> >to do seamless mobility in real-time (10 mSec).
>> >
>> >So, the phrase to focus on is "Real-time seamless mobility".
>> >
>> >Of course, we can do IP SAR to all seven MNs, but it will 
>> not happen in
>> >real-time.
>> >
>> >- Kulwinder. 
>> >
>> >> -----Original Message-----
>> >> From: James Kempf [mailto:James.Kempf@eng.sun.com]
>> >> Sent: Wednesday, January 03, 2001 8:41 AM
>> >> To: mruckstuhl@meshnetworks.com; kulwinder.atwal@herc.zucotto.com;
>> >> seamoby@diameter.org; kulwinder.atwal@herc.zucotto.com
>> >> Subject: RE: [seamoby] MicroMobility Algorithm Outline 
>> Revision 0.0001
>> >> 
>> >> 
>> >> 
>> >> >> Thus, intra-network handover can be made to maintain some BE 
>> >> >> support while
>> >> >> the MN realizes that an inter-network handover is now 
>> >> required per the
>> >> >> subscriber's configuration. I think the intra-network 
>> >> handover is what
>> >> >> everyone is discussing as micromobility?
>> >> >
>> >> >I don't think using IP is a good idea for intra-network hand-off.
>> >> >Just the IPv6 header is 40 bytes.  The largest single slot 
>> >> packet that I can
>> >> >send over Bluetooth has 28 bytes of payload.  This means 
>> >> that Bluetooth
>> >> >cannot use IPv6 to do real-time seamless mobility.
>> >> >
>> >> 
>> >> I don't understand this statement. The Bluetooth device 
>> simply needs
>> >> to do segmentation and reassambly. CDMA radio frames are 
>> also limited
>> >> in size, and nobody is suggesting that IPv6 can't be used for
>> >> mobility on CMDA.
>> >> 
>> >> 		jak
>> >> 
>> 



From owner-seamoby@diameter.org  Wed Jan  3 14:58:51 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03373
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 14:58:51 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03IcnT03509
	for seamoby-list; Wed, 3 Jan 2001 10:38:49 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03IcjW03504
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 10:38:45 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <ZJFR849N>; Wed, 3 Jan 2001 12:46:20 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B69@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Michael A. Ramalho'" <mramalho@cisco.com>,
        "'Gary Kenward'"
	 <gkenward@nortelnetworks.com>, seamoby@diameter.org
Subject: RE: [seamoby] cart-before-seamoby
Date: Wed, 3 Jan 2001 12:46:16 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C075AD.1455CF57"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C075AD.1455CF57
Content-Type: text/plain;
	charset="iso-8859-1"


These seem to be related to a particular network technology, right?

That is ... given a network (radio/spectrum) design ... then "network
handoff triggers" are determined by the network designers ... and these
triggers can use such information to help determine when the
"triggering events" should be requested, right?
 
Is this not for wireless networks?
 
If so, then EVERY wireless network has a RF signal.  Not just Bluetooth.
And every radio I have ever put my hands in has had a RSSI.
This includes Shortwave, VHF, UHF, Microwave, Bluetooth and yes even cell
phones.
This is how a radio measures the signal strength.  Some radios called it the
Recieve Signal 
Strength Indicator, while others call it the Radio Signal Strength
Indicator.
This is fundemental.   Fundemental wireless terminology.
Look on your cell phone display, you will see it.
 
If you want to come up with a wireless protocol you must be willing and able
to learn and use some basic wireless terminology.
 
If you are working on a wired protocol then you should say so.
 
 
 
- Kulwinder
 
 

------_=_NextPart_001_01C075AD.1455CF57
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD>
<BODY><FONT face=Arial color=#0000ff size=2></FONT>
<DIV><FONT face=Arial color=#0000ff size=2></FONT><FONT face=Arial color=#0000ff 
size=2></FONT><BR>These seem to be related to a particular network technology, 
right?<BR><BR>That is ... given a network (radio/spectrum) design ... then 
"network<BR>handoff triggers" are determined by the network designers ... and 
these<BR>triggers can use such information to help determine when 
the<BR>"triggering events" should be requested, right?<BR><SPAN 
class=121242917-03012001><FONT face=Arial color=#0000ff 
size=2>&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=121242917-03012001><FONT face=Arial color=#0000ff size=2>Is 
this not for wireless networks?</FONT></SPAN></DIV>
<DIV><SPAN class=121242917-03012001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=121242917-03012001><FONT face=Arial color=#0000ff size=2>If so, 
then EVERY wireless network has a RF signal.&nbsp; Not just 
Bluetooth.</FONT></SPAN></DIV>
<DIV><SPAN class=121242917-03012001><FONT face=Arial color=#0000ff 
size=2>And&nbsp;every radio I&nbsp;have ever put my hands in has had a 
RSSI.</FONT></SPAN></DIV>
<DIV><SPAN class=121242917-03012001><FONT face=Arial color=#0000ff 
size=2>This&nbsp;includes Shortwave, VHF, UHF, Microwave, Bluetooth and yes even 
cell phones.</FONT></SPAN></DIV>
<DIV><SPAN class=121242917-03012001><FONT face=Arial color=#0000ff size=2>This 
is how a radio measures </FONT><SPAN class=121242917-03012001><FONT face=Arial 
color=#0000ff size=2>the signal strength.&nbsp; Some radios called it the 
Recieve Signal </FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
face=Arial color=#0000ff size=2>Strength Indicator, while others call it the 
Radio Signal Strength Indicator.</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
face=Arial color=#0000ff size=2>This is fundemental.&nbsp;&nbsp; Fundemental 
wireless terminology.</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
face=Arial color=#0000ff size=2>Look on your cell phone display, you will see 
it.</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
face=Arial color=#0000ff size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
face=Arial color=#0000ff size=2>If you want to come up with a wireless protocol 
you must be willing and able to learn and use some basic wireless 
terminology.</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
face=Arial color=#0000ff size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
face=Arial color=#0000ff size=2>If you are working on a wired protocol then you 
should say so.</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
face=Arial color=#0000ff size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
face=Arial color=#0000ff size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
face=Arial color=#0000ff size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
face=Arial color=#0000ff size=2>- Kulwinder</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
face=Arial color=#0000ff size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=121242917-03012001>&nbsp;</SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C075AD.1455CF57--


From owner-seamoby@diameter.org  Wed Jan  3 14:58:52 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03384
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 14:58:52 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03Imcq03529
	for seamoby-list; Wed, 3 Jan 2001 10:48:38 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03ImZW03524
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 10:48:35 -0800
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id JAA14812;
	Wed, 3 Jan 2001 09:52:45 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA20427; Wed, 3 Jan 2001 09:52:45 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14931.26349.294698.950118@thomasm-u1.cisco.com>
Date: Wed, 3 Jan 2001 09:52:45 -0800 (PST)
To: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
Cc: "'Michael Ruckstuhl'"
	 <mruckstuhl@MeshNetworks.com>,
        "'Kulwinder Atwal'"
	 <kulwinder.atwal@herc.zucotto.com>,
        seamoby@diameter.org
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
In-Reply-To: <FC0292EA4D13D34EA2E5FC728D70A8E3078B63@NEPTUNE.zucotto.com>
References: <FC0292EA4D13D34EA2E5FC728D70A8E3078B63@NEPTUNE.zucotto.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


Like others, my bogosity meter just pinned. SAR's and
ROHC are your friends.

	 Mike

Kulwinder Atwal writes:
 > 
 > > I agree with everything that you have said.  The only place 
 > > for IP is in
 > > switch packet flows between two different types of networks.
 > 
 > Let me clarify.
 > 
 > The place for IP based real-time messaging is over the landline IP network
 > between a Bluetooth Host and other Cellular Base Stations to switch IP
 > packet flows.  Not, over a wireless link.  We cannot achieve seamless
 > real-time behaviour by sending IP over a Bluetooth wireless link.  I need to
 > get it done over a wireless link with only 28 bytes.
 > 
 > - Kulwinder.
 > 


From owner-seamoby@diameter.org  Wed Jan  3 15:13:39 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03761
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 15:13:38 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03JF8b03594
	for seamoby-list; Wed, 3 Jan 2001 11:15:08 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03JF5W03589
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 11:15:05 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <ZJFR8405>; Wed, 3 Jan 2001 13:22:40 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B6A@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Peter Lei'" <peter.lei@motorola.com>
Cc: "'James Kempf'" <James.Kempf@eng.sun.com>, seamoby@diameter.org
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
Date: Wed, 3 Jan 2001 13:22:37 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

> I don't follow this... Even with IPv4, without header 
> compression you're
> only going to get 8 bytes of payload, not including the 
> TCP/UDP/SCTP header,
> on this link...
> 
> Also, I'll point out that the SAR is already there-- see the 
> first couple
> of bits in the data header of the baseband payload in conjunction with
> L2CAP...

I KNOW it is there.  I WROTE the CODE !!!

Now try to follow this.  

One DH1 baseband packet per slave = 10 mSec = 28 payload bytes.

One L2CAP packet can be many baseband packets.

If IPv4 takes 20 bytes (with no options), and UDP take 16 bytes you have
negative eight bytes for Seamoby over UDP/IP within 10 mSec.

- Kulwinder.

> 
> --peter
> 


From owner-seamoby@diameter.org  Wed Jan  3 15:22:13 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03924
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 15:22:12 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03JRQd03606
	for seamoby-list; Wed, 3 Jan 2001 11:27:26 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (witbier.cisco.com [171.71.152.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03JRNW03601
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 11:27:23 -0800
Received: from Ramalho-Family (rtp-vpn-120.cisco.com [10.82.192.120])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id KAA04527;
	Wed, 3 Jan 2001 10:34:35 -0800 (PST)
Message-Id: <4.1.20010103130151.00a25260@witbier.cisco.com>
X-Sender: mramalho@witbier.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 03 Jan 2001 13:36:44 -0500
To: Kulwinder Atwal <kulwinder.atwal@zucotto.com>,
        "'Gary Kenward'" <gkenward@nortelnetworks.com>, seamoby@diameter.org
From: "Michael A. Ramalho" <mramalho@cisco.com>
Subject: RE: [seamoby] cart-before-seamoby
In-Reply-To: <FC0292EA4D13D34EA2E5FC728D70A8E3078B69@NEPTUNE.zucotto.com
 >
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_18827752==_.ALT"
Sender: owner-seamoby@diameter.org
Precedence: bulk

--=====================_18827752==_.ALT
Content-Type: text/plain; charset="us-ascii"

Kulwinder,

Final volley here.

Michael

At 12:46 PM 1/3/01 -0500, Kulwinder Atwal wrote: 

>
> These seem to be related to a particular network technology, right?
>
> That is ... given a network (radio/spectrum) design ... then "network
> handoff triggers" are determined by the network designers ... and these
> triggers can use such information to help determine when the
> "triggering events" should be requested, right?
>  
> Is this not for wireless networks?
>  
> If so, then EVERY wireless network has a RF signal.  Not just Bluetooth.
> And every radio I have ever put my hands in has had a RSSI.
> This includes Shortwave, VHF, UHF, Microwave, Bluetooth and yes even cell
> phones.
> This is how a radio measures the signal strength.  Some radios called it the
> Recieve Signal 
> Strength Indicator, while others call it the Radio Signal Strength Indicator.
> This is fundemental.   Fundemental wireless terminology.
> Look on your cell phone display, you will see it.


You missed my point (again).

Your assumed network, assuming a *PARTICULAR NETWORK
TECHNOLOGY* (can I emphasize it enough?), in general, does
*not know* what  *OTHER NETWORK TECHNOLOGIES* may
be available to the mobile. And, in general, does *not know*
the relative signal strengths of those other technologies that
*may* be available to it.

My point was *not* that some indication of signal strength of
*a particular network technology's* signal is highly desirous.
We are not village idiots on this list.

My point was that a particular network provider, in general, only
knows metrics about it's network. Period. Full Stop. And, in
general, does not know everything that may be available to the
mobile that would make the mobile's movement somewhere
else better (perhaps a better signal strength on another
technology!). Period.

Please re-read my comments in that light.

My issue with your email was not that it wasn't sincere, but
rather that it only focused on a *particular network
technology* ... and not the wholistic future wireless landscape
using mobile IP technology.

>
>  
> If you want to come up with a wireless protocol you must be willing and able
> to learn and use some basic wireless terminology.


I can transform any power metric you desire to use via
first principals and Parseval's Theorem between any
relevant engineering transform domains, if you would like.

Rethinking that ... any domain that preserves the L2 norm
(which includes all relevant engineering domains, if
you excuse use of 1 and 1/(2*pi) in forward and reverse
engineering transforms, where mathematical purists would
more properly use 1/sqrt(2*pi) in both forward and reverse
transforms ... can't change those engineering texts
now ... you would screw up the units).


>
>  
> If you are working on a wired protocol then you should say so.
>  


Could you have read the rest of the email?

>
>  
>  
> - Kulwinder
>  
>  




Michael A. Ramalho, Ph.D.
Office email: mramalho@cisco.com
Personal email: mar42@cornell.edu
Office: +1.732.449.5762
Cell: +1.732.809.0188
Pager: +1.800.365.4578 
--=====================_18827752==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Kulwinder,<br>
<br>
Final volley here.<br>
<br>
Michael<br>
<br>
At 12:46 PM 1/3/01 -0500, Kulwinder Atwal wrote: <br>
<br>
<blockquote type=cite cite>These seem to be related to a particular
network technology, right?<br>
<br>
That is ... given a network (radio/spectrum) design ... then
&quot;network<br>
handoff triggers&quot; are determined by the network designers ... and
these<br>
triggers can use such information to help determine when the<br>
&quot;triggering events&quot; should be requested, right?<br>
<font face="arial" size=2 color="#0000FF">&nbsp;</font><br>
Is this not for wireless networks?<br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">If so, then EVERY wireless
network has a RF signal.&nbsp; Not just Bluetooth.</font><br>
And every radio I have ever put my hands in has had a RSSI.<br>
This includes Shortwave, VHF, UHF, Microwave, Bluetooth and yes even cell
phones.<br>
This is how a radio measures the signal strength.&nbsp; Some radios
called it the Recieve Signal <br>
Strength Indicator, while others call it the Radio Signal Strength
Indicator.<br>
This is fundemental.&nbsp;&nbsp; Fundemental wireless terminology.<br>
Look on your cell phone display, you will see it.</blockquote><br>
You missed my point (again).<br>
<br>
Your assumed network, assuming a *PARTICULAR NETWORK<br>
TECHNOLOGY* (can I emphasize it enough?), in general, does<br>
*not know* what&nbsp; *OTHER NETWORK TECHNOLOGIES* may<br>
be available to the mobile. And, in general, does *not know*<br>
the relative signal strengths of those other technologies that<br>
*may* be available to it.<br>
<br>
My point was *not* that some indication of signal strength of<br>
*a particular network technology's* signal is highly desirous.<br>
We are not village idiots on this list.<br>
<br>
My point was that a particular network provider, in general, only<br>
knows metrics about it's network. Period. Full Stop. And, in<br>
general, does not know everything that may be available to the<br>
mobile that would make the mobile's movement somewhere<br>
else better (perhaps a better signal strength on another<br>
technology!). Period.<br>
<br>
Please re-read my comments in that light.<br>
<br>
My issue with your email was not that it wasn't sincere, but<br>
rather that it only focused on a *particular network<br>
technology* ... and not the wholistic future wireless landscape<br>
using mobile IP technology.<br>
<br>
<blockquote type=cite cite>&nbsp;<br>
<font face="arial" size=2 color="#0000FF">If you want to come up with a
wireless protocol you must be willing and able to learn and use some
basic wireless terminology.</font><br>
</blockquote><br>
I can transform any power metric you desire to use via<br>
first principals and Parseval's Theorem between any<br>
relevant engineering transform domains, if you would like.<br>
<br>
Rethinking that ... any domain that preserves the L2 norm<br>
(which includes all relevant engineering domains, if<br>
you excuse use of 1 and 1/(2*pi) in forward and reverse<br>
engineering transforms, where mathematical purists would<br>
more properly use 1/sqrt(2*pi) in both forward and reverse<br>
transforms ... can't change those engineering texts<br>
now ... you would screw up the units).<br>
<br>
<br>
<blockquote type=cite cite>&nbsp;<br>
<font face="arial" size=2 color="#0000FF">If you are working on a wired
protocol then you should say so.</font><br>
&nbsp;<br>
</blockquote><br>
Could you have read the rest of the email?<br>
<br>
<blockquote type=cite cite>&nbsp;<br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">- Kulwinder</font><br>
&nbsp;<br>
&nbsp;</blockquote><br>
<br>
<br>
<div>Michael A. Ramalho, Ph.D.</div>
<div>Office email: mramalho@cisco.com</div>
<div>Personal email: mar42@cornell.edu</div>
<div>Office: +1.732.449.5762</div>
<div>Cell: +1.732.809.0188</div>
Pager: +1.800.365.4578
</html>

--=====================_18827752==_.ALT--



From owner-seamoby@diameter.org  Wed Jan  3 15:22:59 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03950
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 15:22:58 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03JTLr03615
	for seamoby-list; Wed, 3 Jan 2001 11:29:21 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03JTJW03610
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 11:29:19 -0800
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id KAA16020;
	Wed, 3 Jan 2001 10:36:49 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA20434; Wed, 3 Jan 2001 10:36:49 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14931.28992.947160.274401@thomasm-u1.cisco.com>
Date: Wed, 3 Jan 2001 10:36:48 -0800 (PST)
To: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
Cc: "'Peter Lei'" <peter.lei@motorola.com>,
        "'James Kempf'" <James.Kempf@eng.sun.com>, seamoby@diameter.org
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
In-Reply-To: <FC0292EA4D13D34EA2E5FC728D70A8E3078B6A@NEPTUNE.zucotto.com>
References: <FC0292EA4D13D34EA2E5FC728D70A8E3078B6A@NEPTUNE.zucotto.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Kulwinder Atwal writes:
 > If IPv4 takes 20 bytes (with no options), and UDP take 16 bytes you have
 > negative eight bytes for Seamoby over UDP/IP within 10 mSec.

   Well, this begs the question of where the requirement
   for "within 10 ms" came from.

	       Mike


From owner-seamoby@diameter.org  Wed Jan  3 15:28:16 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04113
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 15:28:15 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03IsLY03540
	for seamoby-list; Wed, 3 Jan 2001 10:54:21 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03IsJW03535
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 10:54:19 -0800
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09712
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 10:01:53 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA05214
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 10:01:52 -0800 (PST)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA14057
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 10:01:51 -0800 (PST)
Message-Id: <200101031801.KAA14057@nasnfs.eng.sun.com>
Date: Wed, 3 Jan 2001 10:02:05 -0800 (PST)
From: James Kempf <James.Kempf@eng.sun.com>
Reply-To: James Kempf <James.Kempf@eng.sun.com>
Subject: [seamoby] Which Bluetooth?
To: seamoby@diameter.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: mrpcuPD5nqS5IbZpJR12Rg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Kulwinder Atwal wrote:

>The LAN profile is profile and as such is completely and totally optional.
>Therefore, it is completely inappropriate for them to use words like the
>profile "Mandates".  Or, make statements like "if you want to run IP over
>Bluetooth 1.0, this is the required way to support it!".  Because, tomorrow
>I can come up with my own profile that is the complete opposite, and if I so
>choose, have it approved by the SIG.  There is currently an explosion of
>profiles in the SIG.  It should read, "This is how this particular profile
>implements IP over Bluetooth".  The only requirement is that for every
>"client" stack on one side that there exists a similiar "server" stack on
>the other side for the "client" to have something to talk to.  Or, simply
>that you need the same driver on both ends.  This is nothing new to anyone
>in the IETF. (Networking 101) 

This leaves me with more than a little concern. 

If anyone can define a Bluetooth profile, then which profile should
we be concentrating on? I suppose one could say "all" but neverthess.
This seems like a recipe for an interoperability nightmare.

My impression is that the LAN profile was the Bluetooth
Association's recommendation to what L2 to use for IP. Is that not so? If it
is, then barring the case where IETF defines its own profile, I'd like to 
propose that we concentrate on the LAN profile to avoid talking about 
hypothetical profiles that may or  may not happen. Naturally, it is important to 
keep in mind future growth and future L2s, but I don't think arguments about how 
the Bluetooth L1 works are helpful in focussing on what may or may not
be needed in getting a micromobility protocol to support IP on Bluetooth.

All this is made more complicated by the fact that it is next to impossible
to get details about the direction the Bluetooth Association is
going in from outside, and that information is even selectively disclosed
to members depending on their status.

		jak



From owner-seamoby@diameter.org  Wed Jan  3 15:28:41 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04151
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 15:28:41 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03J0ED03567
	for seamoby-list; Wed, 3 Jan 2001 11:00:14 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03J0CW03562
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 11:00:12 -0800
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id KAA15181;
	Wed, 3 Jan 2001 10:07:36 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA20430; Wed, 3 Jan 2001 10:07:36 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14931.27240.257480.366345@thomasm-u1.cisco.com>
Date: Wed, 3 Jan 2001 10:07:36 -0800 (PST)
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: James Kempf <James.Kempf@eng.sun.com>, Phil_Neumiller@3Com.com,
        dblair@cisco.com, gkenward@nortelnetworks.com, seamoby@diameter.org
Subject: RE: [seamoby] Micromobility Problem Statement
In-Reply-To: <Roam.SIMC.2.0.6.978533363.7667.pcalhoun@nasnfs>
References: <200012202100.NAA01510@nasnfs.eng.sun.com>
	<Roam.SIMC.2.0.6.978533363.7667.pcalhoun@nasnfs>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat Calhoun writes:
 > more signaling != seamless

   There ain't no such thing as a free lunch. Also: it's not
   entirely clear whether L2 blocking is useful here or
   not. If it is, modularity may be the better direction.
 
 > For that matter, it appears as if diffserv needs to be used in the core. Now,
 > perhaps some signaling from the mobile is needed to get the edge device to
 > "reserve" the resources. This information can be transfered in the context
 > transfer, so no new signaling would be needed by the mobile.

   I don't see how it's our choice to mandate diffserv;
   we're not the protocol police after all. The fact is
   that some networks will be built with Intserv and/or
   Intserv/Diffserv mixes.

 > This, of course, also needs to work across domains, so the QoS info transfered
 > would have to be "generic", and able to be mapped to the local DSCP.

   Sure. The same goes for signaled QoS too.

	     Mike


From owner-seamoby@diameter.org  Wed Jan  3 15:30:40 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04234
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 15:30:39 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03IwVF03549
	for seamoby-list; Wed, 3 Jan 2001 10:58:31 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03IwTW03544
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 10:58:29 -0800
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id LAA16441; Wed, 3 Jan 2001 11:05:49 -0700 (MST)]
Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id LAA26176; Wed, 3 Jan 2001 11:05:48 -0700 (MST)]
Received: from motorola.com (d42-2903 [160.15.41.3]) by relay1.cig.mot.com (8.8.8+Sun/SCERG-RELAY-1.11b) with ESMTP id MAA07293; Wed, 3 Jan 2001 12:05:48 -0600 (CST)
Message-ID: <3A536A38.8EDE6C76@motorola.com>
Date: Wed, 03 Jan 2001 12:06:48 -0600
From: Peter Lei <peter.lei@motorola.com>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
CC: "'James Kempf'" <James.Kempf@eng.sun.com>, seamoby@diameter.org
Subject: Re: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
References: <FC0292EA4D13D34EA2E5FC728D70A8E3078B67@NEPTUNE.zucotto.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Kulwinder,

[snip]
> > Given that, I don't quite see
> > the problem with doing SAR. It would have to be fitted into L2/L2.5
> > somewhere.
> 
> 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.

I don't follow this... Even with IPv4, without header compression you're
only going to get 8 bytes of payload, not including the TCP/UDP/SCTP header,
on this link...

Also, I'll point out that the SAR is already there-- see the first couple
of bits in the data header of the baseband payload in conjunction with
L2CAP...

--peter


From owner-seamoby@diameter.org  Wed Jan  3 16:19:36 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05170
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 16:19:36 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03KKED03649
	for seamoby-list; Wed, 3 Jan 2001 12:20:14 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from sirius.ctr.columbia.edu (sirius.ctr.columbia.edu [128.59.64.60])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03KKCW03644
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 12:20:12 -0800
Received: from SWEETPEA (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with SMTP id OAA22344; Wed, 3 Jan 2001 14:27:45 -0500 (EST)
From: "Andrew T. Campbell" <campbell@comet.columbia.edu>
To: <Phil_Neumiller@3Com.com>, <seamoby@diameter.org>
Subject: RE: [seamoby] Micromobility Problem Statement ISSUE 1
Date: Wed, 3 Jan 2001 14:27:22 -0800
Message-ID: <014801c075d4$58397150$3d443b80@SWEETPEA>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <882569C9.005B82CA.00@hqoutbound.ops.3com.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


Phil:

Your message is intriguing but throws up lots of challenges.

> -----Original Message-----
> From: owner-seamoby@diameter.org [mailto:owner-seamoby@diameter.org]On
> Behalf Of Phil_Neumiller@3Com.com
> Sent: Wednesday, January 03, 2001 8:45 AM
> To: seamoby@diameter.org
> Subject: [seamoby] Micromobility Problem Statement ISSUE 1
> 
> 
> 
> 
> Nothing stays homogeneous very long.  The beauty of an IP 
> based solution
> is that it can evolve seperately from air interfaces.  The 
> WHOLE point here is
> take things that are "commonly done" by a majority of air 
> interfaces to enact
> micro
> mobility, and place this over IP.  This way a new radio 
> interface can be easily
>  plopped in to an old system without breaking the signalling. 
>  This is the most
> important design principle for micro-mobility I can think of.

This is an interesting and important point. Historically
wireless control has been a level 1 issue and one can be
radical (and academic) and say: why not build the key
controllers over IP with an eye to evolving simple radio
interfaces. 

One can look, for example, at the WCDMA UTRAN
and Core Network functions and implement them over IP. Clearly,
handoff control, and paging is feasible but some fast time
scale controllers such as fast power control make be more
challenging but the message (in a 3GPP/3GPP2 sense) is
why not build the UE, UTRAN and CN all over IP? 
I'm being a tad simplistic here to make the point.

I could make the same argument for cdma2000/TD-CDMA, etc.  

But regardless of whether people agree with 
"IP everywhere" for 3G networks I would argue that 
we need IP paging and handoff control at layer 3
regardless of what is happening at L1 today.

I would hedge my bets and predict that many of the 
L1 wireless and mobile control
functions will be implemented over IP as wireless connectivity
becomes the norm for Internet. In that case one could imagine that
future radios will be simple and interface to a set of 
programmable controllers over IP. These controllers 
could be implemented in a fully
distributed fashion and could be reused for a variety of
competing radio technology and environments. (With CIP we implemented 
IP handoff and paging in a fully distributed manner -
as a modest test case). 


> 
> PROBLEM STATEMENT ISSUE 1
> Existing air interfaces have a tendency to do the same things 
> in different ways.
> Our collective experience with many air interfaces over time 
> has lead us to
> believe that micro-mobility can be implemented as an IP based 
> protocol.
> This will allow air interface technology to evolve separately 
> from the handoff
> algorithms that are deployed.
> 
> 
> 
> 
> Sent by:  Kulwinder Atwal <kulwinder.atwal@zucotto.com>
> 
> 
> To:   "'Mika Ylianttila'" <over@ees2.oulu.fi>, seamoby@diameter.org
> cc:    (Phil Neumiller/MW/US/3Com)
> Subject:  RE: [seamoby] MicroMobility Algorithm Outline 
> Revision 0.0001
> 
> 
> 
> No, it just seems like a waste of effort.  Someone has to 
> show me the real
> value of doing this on a homogenous net.  Since we are talking about
> real-time preformance, it would take time to 
> compress/decompress.  If I can
> do it without compression and get the same value I will.
> 
> - Kal.
> 
> > -----Original Message-----
> > From: Mika Ylianttila [mailto:over@ees2.oulu.fi]
> > Sent: Wednesday, January 03, 2001 6:13 AM
> > To: seamoby@diameter.org
> > Subject: RE: [seamoby] MicroMobility Algorithm Outline 
> Revision 0.0001
> >
> >
> > On Wed, 3 Jan 2001, Kulwinder Atwal wrote:
> >
> > >I don't think using IP is a good idea for intra-network hand-off.
> > >Just the IPv6 header is 40 bytes.  The largest single slot
> > packet that I can
> > >send over Bluetooth has 28 bytes of payload.  This means
> > that Bluetooth
> > >cannot use IPv6 to do real-time seamless mobility.
> >
> >   Did you forget the possibility for header compression?  ;)
> >
> > --
> > Mika Ylianttila
> > M.Sc., Project Manager
> > Centre for Wireless Communications
> > PL 4500, Tutkijantie 2 E, FIN-90014
> > University of Oulu, Finland
> >
> >
> 
> 
> 
> 
> 


From owner-seamoby@diameter.org  Wed Jan  3 16:42:35 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05671
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 16:42:35 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03KqNr03668
	for seamoby-list; Wed, 3 Jan 2001 12:52:23 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from newman.frascone.com (god@www.frascone.com [216.62.83.25])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f03KqLW03663
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 12:52:21 -0800
Received: (qmail 11354 invoked by uid 500); 3 Jan 2001 20:42:35 -0000
Date: Wed, 3 Jan 2001 14:42:34 -0600
From: David Frascone <dave@frascone.com>
To: seamoby@diameter.org
Subject: Re: [seamoby] Micromobility Problem Statement
Message-ID: <20010103144234.J10666@newman.frascone.com>
Mail-Followup-To: seamoby@diameter.org
References: <Roam.SIMC.2.0.6.978533696.31572.pcalhoun@nasnfs> <Roam.SIMC.2.0.6.978534909.15724.pcalhoun@nasnfs> <14931.23937.269455.481693@thomasm-u1.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <14931.23937.269455.481693@thomasm-u1.cisco.com>; from mat@cisco.com on Wed, Jan 03, 2001 at 09:12:33AM -0800
X-encrypt-payload: no
Sender: owner-seamoby@diameter.org
Precedence: bulk

It sounds to me like QoS needs to go into the Problem Statement.  Then we can
be sure that Seamoby will addresses the issues.

But, maybe I'm confused as to what you're asking :)


-Dave

On Wed, Jan 03, 2001 at 09:12:33AM -0800, Michael Thomas wrote:
> 
> I'm not sure what you're asking us to do here.
> From my standpoint, if QoS cannot be reestablished
> in a timely fashion for real time traffic, then
> you cannot have seamless mobility for the most
> important case and we might as well pick up our
> marbles and go home. Others don't think that QoS
> is important at all. Still others aren't up to
> speed as to where the actual gaps are with current
> IETF protocols.
> 
> So, like, what now? This doesn't seem like an
> argument over the solution space so much as an
> argument over relevance.
> 
> 	       Mike
> 
> Pat Calhoun writes:
>  > <chair hat>
>  > As I wade through the countless e-mails in my never ending inbox, I find
>  > myself easily led into QOS discussions, and what should be the signaling
>  > method to get micromobility. However, I think that we should all focus our
>  > efforts on getting the actual problem statement (hey, look at the subject of
>  > this e-mail). I think that Dana's goal was to get the problem statement work
>  > started, and instead this thread has degrated into the solution space.
>  > 
>  > Could we continue with the task of defining what the problem is that we are
>  > trying to solve? </chair hat>
>  > 
>  > PatC
>  > 
>  > 


From owner-seamoby@diameter.org  Wed Jan  3 16:50:31 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05825
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 16:50:30 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03LG9h03697
	for seamoby-list; Wed, 3 Jan 2001 13:16:09 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03LG6W03692
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 13:16:06 -0800
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2650.21)
	id <ZXNW863C>; Wed, 3 Jan 2001 15:23:39 -0500
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0480ACFF0@meshpdc.meshnetworks.com>
From: Michael Ruckstuhl <mruckstuhl@MeshNetworks.com>
To: seamoby@diameter.org
Subject: RE: [seamoby] cart-before-seamoby
Date: Wed, 3 Jan 2001 15:23:34 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C075C3.0DA134B8"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C075C3.0DA134B8
Content-Type: text/plain;
	charset="iso-8859-1"

Wait a minute - are we assuming it's RF? I'm thinking I have my laptop with
an 802.11 card and an ethernet card - when I can plug into the local LAN, I
do, and that becomes my primary datapath. When I unplug, the 802.11 card
becomes my primary datapath. Maybe I have an IR transport of some kind. I
don't know, but the point is that mobility has to handle any kind of
transport, and should seamless mobility assume RF?
 
 
mruckstuhl

-----Original Message-----
From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
Sent: Wednesday, January 03, 2001 12:46 PM
To: 'Michael A. Ramalho'; 'Gary Kenward'; seamoby@diameter.org
Subject: RE: [seamoby] cart-before-seamoby




These seem to be related to a particular network technology, right?

That is ... given a network (radio/spectrum) design ... then "network
handoff triggers" are determined by the network designers ... and these
triggers can use such information to help determine when the
"triggering events" should be requested, right?
 
Is this not for wireless networks?
 
If so, then EVERY wireless network has a RF signal.  Not just Bluetooth.
And every radio I have ever put my hands in has had a RSSI.
This includes Shortwave, VHF, UHF, Microwave, Bluetooth and yes even cell
phones.
This is how a radio measures the signal strength.  Some radios called it the
Recieve Signal 
Strength Indicator, while others call it the Radio Signal Strength
Indicator.
This is fundemental.   Fundemental wireless terminology.
Look on your cell phone display, you will see it.
 
If you want to come up with a wireless protocol you must be willing and able
to learn and use some basic wireless terminology.
 
If you are working on a wired protocol then you should say so.
 
 
 
- Kulwinder
 
 


------_=_NextPart_001_01C075C3.0DA134B8
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=138091420-03012001>Wait a 
minute -&nbsp;are we assuming&nbsp;it's RF? I'm thinking I have my laptop with 
an 802.11 card and an ethernet card - when I can plug into the local LAN, I do, 
and that becomes my primary datapath. When I unplug, the 802.11 card becomes my 
primary datapath. Maybe I have an IR transport of some kind. I don't know, but 
the point is that mobility has to handle any kind of transport, and should 
seamless mobility assume RF?</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=138091420-03012001></SPAN></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=138091420-03012001>mruckstuhl</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Kulwinder Atwal 
  [mailto:kulwinder.atwal@zucotto.com]<BR><B>Sent:</B> Wednesday, January 03, 
  2001 12:46 PM<BR><B>To:</B> 'Michael A. Ramalho'; 'Gary Kenward'; 
  seamoby@diameter.org<BR><B>Subject:</B> RE: [seamoby] 
  cart-before-seamoby<BR><BR></DIV></FONT><FONT color=#0000ff face=Arial 
  size=2></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2></FONT><FONT color=#0000ff 
  face=Arial size=2></FONT><BR>These seem to be related to a particular network 
  technology, right?<BR><BR>That is ... given a network (radio/spectrum) design 
  ... then "network<BR>handoff triggers" are determined by the network designers 
  ... and these<BR>triggers can use such information to help determine when 
  the<BR>"triggering events" should be requested, right?<BR><SPAN 
  class=121242917-03012001><FONT color=#0000ff face=Arial 
  size=2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><FONT color=#0000ff face=Arial size=2>Is 
  this not for wireless networks?</FONT></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><FONT color=#0000ff face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=121242917-03012001><FONT color=#0000ff face=Arial size=2>If 
  so, then EVERY wireless network has a RF signal.&nbsp; Not just 
  Bluetooth.</FONT></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><FONT color=#0000ff face=Arial 
  size=2>And&nbsp;every radio I&nbsp;have ever put my hands in has had a 
  RSSI.</FONT></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><FONT color=#0000ff face=Arial 
  size=2>This&nbsp;includes Shortwave, VHF, UHF, Microwave, Bluetooth and yes 
  even cell phones.</FONT></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><FONT color=#0000ff face=Arial size=2>This 
  is how a radio measures </FONT><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2>the signal strength.&nbsp; Some radios called 
  it the Recieve Signal </FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2>Strength Indicator, while others call it the 
  Radio Signal Strength Indicator.</FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2>This is fundemental.&nbsp;&nbsp; Fundemental 
  wireless terminology.</FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2>Look on your cell phone display, you will see 
  it.</FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2>If you want to come up with a wireless 
  protocol you must be willing and able to learn and use some basic wireless 
  terminology.</FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2>If you are working on a wired protocol then 
  you should say so.</FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2>- Kulwinder</FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN 
class=121242917-03012001>&nbsp;</SPAN></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C075C3.0DA134B8--


From owner-seamoby@diameter.org  Wed Jan  3 16:55:51 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05892
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 16:55:51 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03LJlN03707
	for seamoby-list; Wed, 3 Jan 2001 13:19:47 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03LJjW03702
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 13:19:45 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <ZJFR8V1D>; Wed, 3 Jan 2001 15:27:21 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B6E@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Michael Thomas'" <mat@cisco.com>,
        Kulwinder Atwal
	 <kulwinder.atwal@herc.zucotto.com>
Cc: "'Peter Lei'" <peter.lei@motorola.com>,
        "'James Kempf'"
	 <James.Kempf@eng.sun.com>, seamoby@diameter.org
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
Date: Wed, 3 Jan 2001 15:27:19 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk



> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Wednesday, January 03, 2001 1:37 PM
> To: Kulwinder Atwal
> Cc: 'Peter Lei'; 'James Kempf'; seamoby@diameter.org
> Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
> 
> 
> Kulwinder Atwal writes:
>  > If IPv4 takes 20 bytes (with no options), and UDP take 16 
> bytes you have
>  > negative eight bytes for Seamoby over UDP/IP within 10 mSec.
> 
>    Well, this begs the question of where the requirement
>    for "within 10 ms" came from.

LCD display driver on a cellphone/PDA.

> 
> 	       Mike
> 


From owner-seamoby@diameter.org  Wed Jan  3 17:09:43 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06252
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 17:09:43 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03Lhub03729
	for seamoby-list; Wed, 3 Jan 2001 13:43:56 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03LhjW03724
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 13:43:46 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <ZJFR8V16>; Wed, 3 Jan 2001 15:51:21 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B6F@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'James Kempf'" <James.Kempf@eng.sun.com>, seamoby@diameter.org
Subject: RE: [seamoby] Which Bluetooth?
Date: Wed, 3 Jan 2001 15:51:12 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk



> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@eng.sun.com]
> Sent: Wednesday, January 03, 2001 1:02 PM
> To: seamoby@diameter.org
> Subject: [seamoby] Which Bluetooth?
> 
> 
> This leaves me with more than a little concern. 
> 
> If anyone can define a Bluetooth profile, then which profile should
> we be concentrating on? I suppose one could say "all" but neverthess.
> This seems like a recipe for an interoperability nightmare.

What I am saying is that Seamoby itself will end up being a profile seperate
from the LAN profile no matter where you decide to put it.  This is because
the Bluetooth SIG is standards based.  They will always try to adopt (rubber
stamp) a protocol as a profile before "re-inventing the wheel". And, it will
become an "official" SIG profile because it came from the IETF.  If you plan
to use the Host Controller for a non-standard purpose, you are free to do so
as long you understand that it is non-standard.

> 
> My impression is that the LAN profile was the Bluetooth
> Association's recommendation to what L2 to use for IP. Is 
> that not so?

It is one of many.  The IETF SLP will be an other.  Your book I believe.

> If it
> is, then barring the case where IETF defines its own profile, 
> I'd like to 
> propose that we concentrate on the LAN profile to avoid talking about 
> hypothetical profiles that may or  may not happen. Naturally, 
> it is important to 
> keep in mind future growth and future L2s, but I don't think 
> arguments about how 
> the Bluetooth L1 works are helpful in focussing on what may or may not
> be needed in getting a micromobility protocol to support IP 
> on Bluetooth.
> 
> All this is made more complicated by the fact that it is next 
> to impossible
> to get details about the direction the Bluetooth Association is
> going in from outside, and that information is even 
> selectively disclosed
> to members depending on their status.

Take a look at the spec:

http://www.bluetooth.com/developer/specification/specification.asp
 
> 		jak
> 


From owner-seamoby@diameter.org  Wed Jan  3 18:33:43 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09553
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 18:33:42 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03MB0e03871
	for seamoby-list; Wed, 3 Jan 2001 14:11:00 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03MAwW03866
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 14:10:58 -0800
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA19561;
	Wed, 3 Jan 2001 13:18:32 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA00192;
	Wed, 3 Jan 2001 13:18:29 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA21653;
	Wed, 3 Jan 2001 13:18:28 -0800 (PST)
Date: Wed, 3 Jan 2001 13:14:58 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [seamoby] Micromobility Problem Statement
To: David Frascone <dave@frascone.com>
Cc: seamoby@diameter.org
In-Reply-To: "Your message with ID" <20010103144234.J10666@newman.frascone.com>
Message-ID: <Roam.SIMC.2.0.6.978556498.18348.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

ok, let me try one more time. 

How about we collaborate together to come up with a problem statement. One
that describes what problem we have today, and what micro-mobility is
attempting to achieve.

Talking about whether diffserv or intserv, what signaling protocols should be
used, physical wireless interface characterics seem to be stepping in the
solutions space.

We need to provide to the IESG what exactly we are trying to solve. As
tempting as it is to reference protocols at this point, let's step back and
simply define the actual problem space.

Perhaps one such way is to provide your diffs against Dana's proposed problem
statement, or propose a new one altogether.

PatC


> On Wed, Jan 03, 2001 at 09:12:33AM -0800, Michael Thomas wrote:
> > 
> > I'm not sure what you're asking us to do here.
> > From my standpoint, if QoS cannot be reestablished
> > in a timely fashion for real time traffic, then
> > you cannot have seamless mobility for the most
> > important case and we might as well pick up our
> > marbles and go home. Others don't think that QoS
> > is important at all. Still others aren't up to
> > speed as to where the actual gaps are with current
> > IETF protocols.
> > 
> > So, like, what now? This doesn't seem like an
> > argument over the solution space so much as an
> > argument over relevance.
> > 
> > 	       Mike
> > 
> > Pat Calhoun writes:
> >  > <chair hat>
> >  > As I wade through the countless e-mails in my never ending inbox, I find
> >  > myself easily led into QOS discussions, and what should be the signaling
> >  > method to get micromobility. However, I think that we should all focus our
> >  > efforts on getting the actual problem statement (hey, look at the subject of
> >  > this e-mail). I think that Dana's goal was to get the problem statement work
> >  > started, and instead this thread has degrated into the solution space.
> >  > 
> >  > Could we continue with the task of defining what the problem is that we are
> >  > trying to solve? </chair hat>
> >  > 
> >  > PatC
> >  > 
> >  > 




From owner-seamoby@diameter.org  Wed Jan  3 19:00:26 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10041
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 19:00:25 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03NBBo03920
	for seamoby-list; Wed, 3 Jan 2001 15:11:11 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03NB8W03915
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 15:11:08 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <ZJFR8V2A>; Wed, 3 Jan 2001 17:18:43 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B70@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Michael Ruckstuhl'" <mruckstuhl@MeshNetworks.com>, seamoby@diameter.org
Subject: RE: [seamoby] cart-before-seamoby
Date: Wed, 3 Jan 2001 17:18:40 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C075D3.21458704"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C075D3.21458704
Content-Type: text/plain;
	charset="iso-8859-1"

My definition of RF includes near infra-red. Call it Electromagnetic
Radiation if you prefer. Maxwell's equations still apply. 
 
Whether it is:
 
- IR
- 802.11
 
We still can measure a signal strength.
 
But, you make a good point about switching between being plugged and
unplugged.
 
This suggests to me that L2 should handle roaming (seamless mobility) in a
homogenous network, because some networks like a LAN do not roam.
 
- Kulwinder. 

-----Original Message-----
From: Michael Ruckstuhl [mailto:mruckstuhl@meshnetworks.com]
Sent: Wednesday, January 03, 2001 3:24 PM
To: seamoby@diameter.org
Subject: RE: [seamoby] cart-before-seamoby


Wait a minute - are we assuming it's RF? I'm thinking I have my laptop with
an 802.11 card and an ethernet card - when I can plug into the local LAN, I
do, and that becomes my primary datapath. When I unplug, the 802.11 card
becomes my primary datapath. Maybe I have an IR transport of some kind. I
don't know, but the point is that mobility has to handle any kind of
transport, and should seamless mobility assume RF?
 
 
 


------_=_NextPart_001_01C075D3.21458704
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=835380722-03012001>My 
definition of RF includes near infra-red. Call it Electromagnetic&nbsp;Radiation 
if you prefer.&nbsp;Maxwell's equations still apply.&nbsp;</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=835380722-03012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=835380722-03012001>Whether it&nbsp;is:</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=835380722-03012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=835380722-03012001>- 
IR</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=835380722-03012001>- 
802.11</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=835380722-03012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=835380722-03012001>We 
still can measure a signal strength.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=835380722-03012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=835380722-03012001>But, 
you&nbsp;make a good point about switching between being plugged and 
unplugged.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=835380722-03012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=835380722-03012001>This 
suggests&nbsp;to me that L2 should handle roaming (seamless mobility)&nbsp;in a 
homogenous network, because some&nbsp;</SPAN></FONT><FONT face=Arial 
color=#0000ff size=2><SPAN class=835380722-03012001>networks like a&nbsp;LAN 
do&nbsp;not roam.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=835380722-03012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=835380722-03012001>-&nbsp;Kulwinder.&nbsp;</SPAN></FONT></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> Michael Ruckstuhl 
  [mailto:mruckstuhl@meshnetworks.com]<BR><B>Sent:</B> Wednesday, January 03, 
  2001 3:24 PM<BR><B>To:</B> seamoby@diameter.org<BR><B>Subject:</B> RE: 
  [seamoby] cart-before-seamoby<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=138091420-03012001>Wait 
  a minute -&nbsp;are we assuming&nbsp;it's RF? I'm thinking I have my laptop 
  with an 802.11 card and an ethernet card - when I can plug into the local LAN, 
  I do, and that becomes my primary datapath. When I unplug, the 802.11 card 
  becomes my primary datapath. Maybe I have an IR transport of some kind. I 
  don't know, but the point is that mobility has to handle any kind of 
  transport, and should seamless mobility assume RF?</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=138091420-03012001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=138091420-03012001></SPAN></FONT>&nbsp;</DIV>
  <DIV><SPAN class=121242917-03012001><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C075D3.21458704--


From owner-seamoby@diameter.org  Wed Jan  3 19:29:22 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10511
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 19:29:21 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03NeqW03983
	for seamoby-list; Wed, 3 Jan 2001 15:40:52 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03NeoW03978
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 15:40:50 -0800
Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com;
          Wed, 3 Jan 2001 17:43:55 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBPA8D>; Wed, 3 Jan 2001 17:44:02 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8A66@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Phil_Neumiller@3Com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
Subject: RE: [seamoby] Micromobility Problem Statement ISSUE 2
Date: Wed, 3 Jan 2001 17:43:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C075D6.A5C18C30"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C075D6.A5C18C30
Content-Type: text/plain;
	charset="iso-8859-1"

Well stated Phil.

At the very least, the suite of IP mobility solutions should not impose
topology restrictions - such as the number of hops between the MIP
mobility agents and the AP - upon the network. 

Gary

> -----Original Message-----
> From: Phil_Neumiller@3Com.com [mailto:Phil_Neumiller@3Com.com]
> Sent: Wednesday, January 03, 2001 12:10 PM
> To: seamoby@diameter.org
> Subject: [seamoby] Micromobility Problem Statement ISSUE 2
> 
> 
> 
> 
> 
> In IPv6 or IPv4 networks, the mobility agents are probably 2+ hops up
> stream in the router chain inside a given administrative domain.  Many
> quick decisions must be made in milliseconds with respect to handoff
> and mobility.  The Mobile node, and the access point/router have a
> better perspective on the local traffic situation (QoS), security, and
> compression, etc.  Thus, these devices are in the best position to
> make decisions  about adding links, m-casting, context transfer etc.
> Furthermre, this implies that the  SeaMoby protocol should reside in
> MNs, and AP/Rs and work in conjunction with MIPv4 or MIPv6 when
> subnet routing boundaries are crossed.   This also has the desirable
> effect of moving intelligence to the "edge" where we can avoid
> redundancy and assure global scalability.
> 
> 
> 

------_=_NextPart_001_01C075D6.A5C18C30
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] Micromobility Problem Statement ISSUE 2</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Well stated Phil.</FONT>
</P>

<P><FONT SIZE=2>At the very least, the suite of IP mobility solutions should not impose</FONT>
<BR><FONT SIZE=2>topology restrictions - such as the number of hops between the MIP</FONT>
<BR><FONT SIZE=2>mobility agents and the AP - upon the network. </FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Phil_Neumiller@3Com.com [<A HREF="mailto:Phil_Neumiller@3Com.com">mailto:Phil_Neumiller@3Com.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, January 03, 2001 12:10 PM</FONT>
<BR><FONT SIZE=2>&gt; To: seamoby@diameter.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: [seamoby] Micromobility Problem Statement ISSUE 2</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In IPv6 or IPv4 networks, the mobility agents are probably 2+ hops up</FONT>
<BR><FONT SIZE=2>&gt; stream in the router chain inside a given administrative domain.&nbsp; Many</FONT>
<BR><FONT SIZE=2>&gt; quick decisions must be made in milliseconds with respect to handoff</FONT>
<BR><FONT SIZE=2>&gt; and mobility.&nbsp; The Mobile node, and the access point/router have a</FONT>
<BR><FONT SIZE=2>&gt; better perspective on the local traffic situation (QoS), security, and</FONT>
<BR><FONT SIZE=2>&gt; compression, etc.&nbsp; Thus, these devices are in the best position to</FONT>
<BR><FONT SIZE=2>&gt; make decisions&nbsp; about adding links, m-casting, context transfer etc.</FONT>
<BR><FONT SIZE=2>&gt; Furthermre, this implies that the&nbsp; SeaMoby protocol should reside in</FONT>
<BR><FONT SIZE=2>&gt; MNs, and AP/Rs and work in conjunction with MIPv4 or MIPv6 when</FONT>
<BR><FONT SIZE=2>&gt; subnet routing boundaries are crossed.&nbsp;&nbsp; This also has the desirable</FONT>
<BR><FONT SIZE=2>&gt; effect of moving intelligence to the &quot;edge&quot; where we can avoid</FONT>
<BR><FONT SIZE=2>&gt; redundancy and assure global scalability.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C075D6.A5C18C30--


From owner-seamoby@diameter.org  Wed Jan  3 19:38:12 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10647
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 19:38:04 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03Ngq303992
	for seamoby-list; Wed, 3 Jan 2001 15:42:52 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03NgnW03987
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 15:42:50 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 3 Jan 2001 17:49:59 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBPA98>; Wed, 3 Jan 2001 17:50:06 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8A67@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>,
        "'Michael A. Ramalho'" <mramalho@cisco.com>, seamoby@diameter.org
Subject: RE: [seamoby] cart-before-seamoby
Date: Wed, 3 Jan 2001 17:49:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C075D7.7FB683A0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C075D7.7FB683A0
Content-Type: text/plain;
	charset="iso-8859-1"

Someone at the CRAPS BOF was adamant - and I agree - that
seamless mobility should support handover between access 
networks (full stop).
 
By definition, some of these access networks may be wired. Some
of these access networks may involve wireless links where the
sensing and calculation of RSSI is either meaningless, or uneconomical.
The origin of the "handoff trigger" as someone called it, is the 
purview of the access network designer, not SeaMoby.
 
Gary

-----Original Message-----
From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
Sent: Wednesday, January 03, 2001 12:46 PM
To: 'Michael A. Ramalho'; Kenward, Gary [WDLN2:AN10:EXCH];
seamoby@diameter.org
Subject: RE: [seamoby] cart-before-seamoby




These seem to be related to a particular network technology, right?

That is ... given a network (radio/spectrum) design ... then "network
handoff triggers" are determined by the network designers ... and these
triggers can use such information to help determine when the
"triggering events" should be requested, right?
 
Is this not for wireless networks?
 
If so, then EVERY wireless network has a RF signal.  Not just Bluetooth.
And every radio I have ever put my hands in has had a RSSI.
This includes Shortwave, VHF, UHF, Microwave, Bluetooth and yes even cell
phones.
This is how a radio measures the signal strength.  Some radios called it the
Recieve Signal 
Strength Indicator, while others call it the Radio Signal Strength
Indicator.
This is fundemental.   Fundemental wireless terminology.
Look on your cell phone display, you will see it.
 
If you want to come up with a wireless protocol you must be willing and able
to learn and use some basic wireless terminology.
 
If you are working on a wired protocol then you should say so.
 
 
 
- Kulwinder
 
 


------_=_NextPart_001_01C075D7.7FB683A0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>Someone at the 
CRAPS BOF was adamant - and I agree - that</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>seamless mobility 
should support handover between access </SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>networks (full 
stop).</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=040593422-03012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>By definition, 
some of these access networks may be wired. Some</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>of these access 
networks may involve wireless links where the</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>sensing and 
calculation of RSSI is either meaningless, or uneconomical.</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>The origin of the 
"handoff trigger" as someone called it, is the </SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>purview of the 
access</SPAN></FONT><FONT face="Comic Sans MS"><SPAN class=040593422-03012001> 
network designer, not SeaMoby.</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=040593422-03012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=040593422-03012001>Gary</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Kulwinder Atwal 
  [mailto:kulwinder.atwal@zucotto.com]<BR><B>Sent:</B> Wednesday, January 03, 
  2001 12:46 PM<BR><B>To:</B> 'Michael A. Ramalho'; Kenward, Gary 
  [WDLN2:AN10:EXCH]; seamoby@diameter.org<BR><B>Subject:</B> RE: [seamoby] 
  cart-before-seamoby<BR><BR></DIV></FONT><FONT color=#0000ff face=Arial 
  size=2></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2></FONT><FONT color=#0000ff 
  face=Arial size=2></FONT><BR>These seem to be related to a particular network 
  technology, right?<BR><BR>That is ... given a network (radio/spectrum) design 
  ... then "network<BR>handoff triggers" are determined by the network designers 
  ... and these<BR>triggers can use such information to help determine when 
  the<BR>"triggering events" should be requested, right?<BR><SPAN 
  class=121242917-03012001><FONT color=#0000ff face=Arial 
  size=2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><FONT color=#0000ff face=Arial size=2>Is 
  this not for wireless networks?</FONT></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><FONT color=#0000ff face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=121242917-03012001><FONT color=#0000ff face=Arial size=2>If 
  so, then EVERY wireless network has a RF signal.&nbsp; Not just 
  Bluetooth.</FONT></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><FONT color=#0000ff face=Arial 
  size=2>And&nbsp;every radio I&nbsp;have ever put my hands in has had a 
  RSSI.</FONT></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><FONT color=#0000ff face=Arial 
  size=2>This&nbsp;includes Shortwave, VHF, UHF, Microwave, Bluetooth and yes 
  even cell phones.</FONT></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><FONT color=#0000ff face=Arial size=2>This 
  is how a radio measures </FONT><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2>the signal strength.&nbsp; Some radios called 
  it the Recieve Signal </FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2>Strength Indicator, while others call it the 
  Radio Signal Strength Indicator.</FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2>This is fundemental.&nbsp;&nbsp; Fundemental 
  wireless terminology.</FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2>Look on your cell phone display, you will see 
  it.</FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2>If you want to come up with a wireless 
  protocol you must be willing and able to learn and use some basic wireless 
  terminology.</FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2>If you are working on a wired protocol then 
  you should say so.</FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2>- Kulwinder</FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
  color=#0000ff face=Arial size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN 
class=121242917-03012001>&nbsp;</SPAN></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C075D7.7FB683A0--


From owner-seamoby@diameter.org  Wed Jan  3 19:43:04 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10778
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 19:43:03 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03NnQZ04009
	for seamoby-list; Wed, 3 Jan 2001 15:49:26 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03NnOW04004
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 15:49:24 -0800
Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com;
          Wed, 3 Jan 2001 17:56:29 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBPBA3>; Wed, 3 Jan 2001 17:56:36 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8A68@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Michael Thomas'" <mat@cisco.com>, Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: James Kempf <James.Kempf@eng.sun.com>, Phil_Neumiller@3Com.com,
        dblair@cisco.com, seamoby@diameter.org
Subject: RE: [seamoby] Micromobility Problem Statement
Date: Wed, 3 Jan 2001 17:56:28 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C075D8.68270FB0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C075D8.68270FB0
Content-Type: text/plain;
	charset="iso-8859-1"

I think Pat meant "signalling over the air interface", please correct me if
I am 
wrong. This gets back to an earlier discussion of the scarcity of bandwidth
over the
access link (or not, Phil). *Most* people who work in wireless believe that
however scarce
or non-scarce wireless bandwidth might be, it's definitely a heck of a  lot
scarcer then
wireline bandwidth. I suspect the ultimate source of that scarcity is
related to noise and
Shannon's law.

I think its a good thing to keep signalling between the host and the network
to a minimum, 
regardless.

Guess what folks, we're back in solution space again.

Gary

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Wednesday, January 03, 2001 1:08 PM
> To: Pat Calhoun
> Cc: James Kempf; Phil_Neumiller@3Com.com; dblair@cisco.com; Kenward,
> Gary [WDLN2:AN10:EXCH]; seamoby@diameter.org
> Subject: RE: [seamoby] Micromobility Problem Statement
> 
> 
> Pat Calhoun writes:
>  > more signaling != seamless
> 
>    There ain't no such thing as a free lunch. Also: it's not
>    entirely clear whether L2 blocking is useful here or
>    not. If it is, modularity may be the better direction.
>  
>  > For that matter, it appears as if diffserv needs to be 
> used in the core. Now,
>  > perhaps some signaling from the mobile is needed to get 
> the edge device to
>  > "reserve" the resources. This information can be 
> transfered in the context
>  > transfer, so no new signaling would be needed by the mobile.
> 
>    I don't see how it's our choice to mandate diffserv;
>    we're not the protocol police after all. The fact is
>    that some networks will be built with Intserv and/or
>    Intserv/Diffserv mixes.
> 
>  > This, of course, also needs to work across domains, so the 
> QoS info transfered
>  > would have to be "generic", and able to be mapped to the 
> local DSCP.
> 
>    Sure. The same goes for signaled QoS too.
> 
> 	     Mike
> 

------_=_NextPart_001_01C075D8.68270FB0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] Micromobility Problem Statement</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I think Pat meant &quot;signalling over the air interface&quot;, please correct me if I am </FONT>
<BR><FONT SIZE=2>wrong. This gets back to an earlier discussion of the scarcity of bandwidth over the</FONT>
<BR><FONT SIZE=2>access link (or not, Phil). *Most* people who work in wireless believe that however scarce</FONT>
<BR><FONT SIZE=2>or non-scarce wireless bandwidth might be, it's definitely a heck of a&nbsp; lot scarcer then</FONT>
<BR><FONT SIZE=2>wireline bandwidth. I suspect the ultimate source of that scarcity is related to noise and</FONT>
<BR><FONT SIZE=2>Shannon's law.</FONT>
</P>

<P><FONT SIZE=2>I think its a good thing to keep signalling between the host and the network to a minimum, </FONT>
<BR><FONT SIZE=2>regardless.</FONT>
</P>

<P><FONT SIZE=2>Guess what folks, we're back in solution space again.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Michael Thomas [<A HREF="mailto:mat@cisco.com">mailto:mat@cisco.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, January 03, 2001 1:08 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Pat Calhoun</FONT>
<BR><FONT SIZE=2>&gt; Cc: James Kempf; Phil_Neumiller@3Com.com; dblair@cisco.com; Kenward,</FONT>
<BR><FONT SIZE=2>&gt; Gary [WDLN2:AN10:EXCH]; seamoby@diameter.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [seamoby] Micromobility Problem Statement</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Pat Calhoun writes:</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; more signaling != seamless</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; There ain't no such thing as a free lunch. Also: it's not</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; entirely clear whether L2 blocking is useful here or</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; not. If it is, modularity may be the better direction.</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; For that matter, it appears as if diffserv needs to be </FONT>
<BR><FONT SIZE=2>&gt; used in the core. Now,</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; perhaps some signaling from the mobile is needed to get </FONT>
<BR><FONT SIZE=2>&gt; the edge device to</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; &quot;reserve&quot; the resources. This information can be </FONT>
<BR><FONT SIZE=2>&gt; transfered in the context</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; transfer, so no new signaling would be needed by the mobile.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; I don't see how it's our choice to mandate diffserv;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; we're not the protocol police after all. The fact is</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; that some networks will be built with Intserv and/or</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Intserv/Diffserv mixes.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; This, of course, also needs to work across domains, so the </FONT>
<BR><FONT SIZE=2>&gt; QoS info transfered</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; would have to be &quot;generic&quot;, and able to be mapped to the </FONT>
<BR><FONT SIZE=2>&gt; local DSCP.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Sure. The same goes for signaled QoS too.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; Mike</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C075D8.68270FB0--


From owner-seamoby@diameter.org  Wed Jan  3 19:43:42 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10823
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 19:43:42 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03NcPK03971
	for seamoby-list; Wed, 3 Jan 2001 15:38:25 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03NcNW03966
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 15:38:23 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 3 Jan 2001 17:40:11 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBPA6Z>; Wed, 3 Jan 2001 17:40:18 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8A65@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>,
        "'James Kempf'" <James.Kempf@eng.sun.com>, mruckstuhl@MeshNetworks.com,
        kulwinder.atwal@herc.zucotto.com, seamoby@diameter.org
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
Date: Wed, 3 Jan 2001 17:40:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C075D6.212EA4D0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C075D6.212EA4D0
Content-Type: text/plain;
	charset="iso-8859-1"

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

------_=_NextPart_001_01C075D6.212EA4D0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>If it is true that you cannot perform &quot;real time&quot; 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>
</P>

<P><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>
</P>

<P><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>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C075D6.212EA4D0--


From owner-seamoby@diameter.org  Wed Jan  3 19:46:22 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10886
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 19:46:21 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03Nrog04020
	for seamoby-list; Wed, 3 Jan 2001 15:53:50 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03NrlW04015
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 15:53:48 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <ZJFR8VJ3>; Wed, 3 Jan 2001 18:01:23 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B71@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'James Kempf'"
	 <James.Kempf@eng.sun.com>,
        mruckstuhl@MeshNetworks.com, kulwinder.atwal@herc.zucotto.com,
        seamoby@diameter.org
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
Date: Wed, 3 Jan 2001 18:01:16 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C075D9.1764DD5F"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C075D9.1764DD5F
Content-Type: text/plain;
	charset="iso-8859-1"

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:gkenward@nortelnetworks.com]
Sent: Wednesday, January 03, 2001 5:40 PM
To: 'Kulwinder Atwal'; 'James Kempf'; mruckstuhl@meshnetworks.com;
kulwinder.atwal@herc.zucotto.com; seamoby@diameter.org
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. 
> 


------_=_NextPart_001_01C075D9.1764DD5F
Content-Type: text/html;
	charset="iso-8859-1"

<!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><SPAN class=917425522-03012001>
<DIV><SPAN class=917425522-03012001><FONT face=Arial color=#0000ff size=2>1. I 
can't do it with IP over a wireless link.</FONT></SPAN></DIV><FONT 
face=Arial><FONT color=#0000ff><FONT size=2><SPAN class=917425522-03012001>2. 
</SPAN>I can do it without IP over a wireless link. 
</FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=917425522-03012001><FONT face=Arial color=#0000ff size=2>3. 
Therefore, I would like to do&nbsp;the hand over&nbsp;with IP over a wired link 
to other types of networks.</FONT></SPAN></DIV>
<DIV><SPAN class=917425522-03012001><FONT face=Arial color=#0000ff 
size=2>4.&nbsp;And with L2 over the Bluetooth wireless link.</FONT></SPAN></DIV>
<DIV><SPAN class=917425522-03012001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=917425522-03012001><FONT face=Arial color=#0000ff size=2>- 
Kulwinder.</FONT></SPAN></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:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, January 03, 
  2001 5:40 PM<BR><B>To:</B> 'Kulwinder Atwal'; 'James Kempf'; 
  mruckstuhl@meshnetworks.com; kulwinder.atwal@herc.zucotto.com; 
  seamoby@diameter.org<BR><B>Subject:</B> RE: [seamoby] MicroMobility Algorithm 
  Outline Revision 0.0001<BR><BR></FONT></DIV>
  <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> </P>
  <P><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> </P>
  <P><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> </P>
  <P><FONT size=2>Gary</FONT> </P>
  <P><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>

------_=_NextPart_001_01C075D9.1764DD5F--


From owner-seamoby@diameter.org  Wed Jan  3 20:02:11 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11052
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 20:02:10 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03NxRa04056
	for seamoby-list; Wed, 3 Jan 2001 15:59:27 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03NxPW04051
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 15:59:25 -0800
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id PAA05533;
	Wed, 3 Jan 2001 15:06:40 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA20450; Wed, 3 Jan 2001 15:06:39 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14931.45183.702585.582609@thomasm-u1.cisco.com>
Date: Wed, 3 Jan 2001 15:06:39 -0800 (PST)
To: "Gary Kenward" <gkenward@nortelnetworks.com>
Cc: "'Michael Thomas'" <mat@cisco.com>, Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        James Kempf <James.Kempf@eng.sun.com>, Phil_Neumiller@3Com.com,
        dblair@cisco.com, seamoby@diameter.org
Subject: RE: [seamoby] Micromobility Problem Statement
In-Reply-To: <13E2EF604DE5D111B2E50000F80824E8057A8A68@zwdld001.ca.nortel.com>
References: <13E2EF604DE5D111B2E50000F80824E8057A8A68@zwdld001.ca.nortel.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Gary Kenward writes:
 > I think Pat meant "signalling over the air interface", please correct me if
 > I am 
 > wrong. This gets back to an earlier discussion of the scarcity of bandwidth
 > over the
 > access link (or not, Phil). *Most* people who work in wireless believe that
 > however scarce
 > or non-scarce wireless bandwidth might be, it's definitely a heck of a  lot
 > scarcer then
 > wireline bandwidth. I suspect the ultimate source of that scarcity is
 > related to noise and
 > Shannon's law.
 > 
 > I think its a good thing to keep signalling between the host and the network
 > to a minimum, 
 > regardless.

   Back to requirements, I think I disagree -- or at least
   partially. What's important for seamoby is that the 
   amount of signaling (number of messages, number of bytes)
   not interfere with in flight (real time/high priority) 
   traffic. If messaging is not in the critical
   path of a handoff, I think it's reasonable to
   say that that's not seamoby's problem to
   solve -- there are a lot of reasons why a
   particular application may not be suitable for
   a particular technology, after all.

		Mike


From owner-seamoby@diameter.org  Wed Jan  3 20:03:59 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11078
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 20:03:59 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f040aSw04127
	for seamoby-list; Wed, 3 Jan 2001 16:36:28 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f040aQW04122
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 16:36:26 -0800
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA16380;
	Wed, 3 Jan 2001 15:43:52 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA13576;
	Wed, 3 Jan 2001 15:43:46 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA27018;
	Wed, 3 Jan 2001 15:43:35 -0800 (PST)
Date: Wed, 3 Jan 2001 15:40:05 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: RE: [seamoby] cart-before-seamoby
To: Gary Kenward <gkenward@nortelnetworks.com>
Cc: "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>,
        "'Kulwinder Atwal'" <kulwinder.atwal@herc.zucotto.com>,
        "'Michael A. Ramalho'" <mramalho@cisco.com>, seamoby@diameter.org
In-Reply-To: "Your message with ID" <13E2EF604DE5D111B2E50000F80824E8057A8A6B@zwdld001.ca.nortel.com>
Message-ID: <Roam.SIMC.2.0.6.978565205.135.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

> There is a paragraph the refers to "3G SDOs", which I do
> not believe belongs in the charter. If we are to expect 
> requirements input from the various 3G camps (I'm not
> even sure what an "SDO" is, could someone remind me).,

SDO = Standards Defining Organization (e.g. TIA, ETSI, IEEE)

>
> Pat: I'm not sure we are allowed to, but I strongly request that
> this paragraph be struck from the charter.

I think that the paragraph was added to show certain possible ties with some
SDOs. It was not meant to be complete, and in no way ties us to specific
technologies. If people want it removed, I can talk to the ADs and see what
they think (but it did pass IESG review, and they know what an SDO is :)

PatC



From owner-seamoby@diameter.org  Wed Jan  3 20:04:13 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11093
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 20:04:12 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03NxCR04047
	for seamoby-list; Wed, 3 Jan 2001 15:59:12 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03NxAW04042
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 15:59:10 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 3 Jan 2001 18:04:08 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBPBC8>; Wed, 3 Jan 2001 18:04:16 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8A69@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Michael A. Ramalho'" <mramalho@cisco.com>,
        Kulwinder Atwal <kulwinder.atwal@zucotto.com>, seamoby@diameter.org
Subject: RE: [seamoby] cart-before-seamoby
Date: Wed, 3 Jan 2001 18:04:00 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C075D9.7571D000"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C075D9.7571D000
Content-Type: text/plain;
	charset="iso-8859-1"

Michael:

Assuming at least wide sense stationary signal and noise
characteristics, which is reasonable for CBR over the air,
but yet to be rationalized for VBR, in particular, bursty
traffic over the air. 

And, in anticipation, it is not my personal belief that adding
information to bursty traffic to make it appear wide sense
stationary so that you can manage the radio resources in a
circuit switched manner is an efficient solution. 

Cheers,
Gary Kenward, O.C.G.

> I can transform any power metric you desire to use via
> first principals and Parseval's Theorem between any
> relevant engineering transform domains, if you would like.

> Michael A. Ramalho, Ph.D.
> Office email: mramalho@cisco.com
> Personal email: mar42@cornell.edu
> Office: +1.732.449.5762
> Cell: +1.732.809.0188
> Pager: +1.800.365.4578 

------_=_NextPart_001_01C075D9.7571D000
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] cart-before-seamoby</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Michael:</FONT>
</P>

<P><FONT SIZE=2>Assuming at least wide sense stationary signal and noise</FONT>
<BR><FONT SIZE=2>characteristics, which is reasonable for CBR over the air,</FONT>
<BR><FONT SIZE=2>but yet to be rationalized for VBR, in particular, bursty</FONT>
<BR><FONT SIZE=2>traffic over the air. </FONT>
</P>

<P><FONT SIZE=2>And, in anticipation, it is not my personal belief that adding</FONT>
<BR><FONT SIZE=2>information to bursty traffic to make it appear wide sense</FONT>
<BR><FONT SIZE=2>stationary so that you can manage the radio resources in a</FONT>
<BR><FONT SIZE=2>circuit switched manner is an efficient solution. </FONT>
</P>

<P><FONT SIZE=2>Cheers,</FONT>
<BR><FONT SIZE=2>Gary Kenward, O.C.G.</FONT>
</P>

<P><FONT SIZE=2>&gt; I can transform any power metric you desire to use via</FONT>
<BR><FONT SIZE=2>&gt; first principals and Parseval's Theorem between any</FONT>
<BR><FONT SIZE=2>&gt; relevant engineering transform domains, if you would like.</FONT>
</P>

<P><FONT SIZE=2>&gt; Michael A. Ramalho, Ph.D.</FONT>
<BR><FONT SIZE=2>&gt; Office email: mramalho@cisco.com</FONT>
<BR><FONT SIZE=2>&gt; Personal email: mar42@cornell.edu</FONT>
<BR><FONT SIZE=2>&gt; Office: +1.732.449.5762</FONT>
<BR><FONT SIZE=2>&gt; Cell: +1.732.809.0188</FONT>
<BR><FONT SIZE=2>&gt; Pager: +1.800.365.4578 </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C075D9.7571D000--


From owner-seamoby@diameter.org  Wed Jan  3 20:05:47 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11143
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 20:05:44 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f03NtUX04030
	for seamoby-list; Wed, 3 Jan 2001 15:55:30 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f03NtRW04025
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 15:55:27 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <ZJFR8VJR>; Wed, 3 Jan 2001 18:03:03 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B72@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'Kulwinder Atwal'"
	 <kulwinder.atwal@herc.zucotto.com>,
        "'Michael A. Ramalho'"
	 <mramalho@cisco.com>, seamoby@diameter.org
Subject: RE: [seamoby] cart-before-seamoby
Date: Wed, 3 Jan 2001 18:03:00 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C075D9.530E408D"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C075D9.530E408D
Content-Type: text/plain;
	charset="iso-8859-1"

Thanks for the backgrounder.  I was not aware this was in our charter.
 
- Kulwinder.

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Wednesday, January 03, 2001 5:50 PM
To: 'Kulwinder Atwal'; 'Michael A. Ramalho'; seamoby@diameter.org
Subject: RE: [seamoby] cart-before-seamoby


Someone at the CRAPS BOF was adamant - and I agree - that
seamless mobility should support handover between access 
networks (full stop).
 
By definition, some of these access networks may be wired. Some
of these access networks may involve wireless links where the
sensing and calculation of RSSI is either meaningless, or uneconomical.
The origin of the "handoff trigger" as someone called it, is the 
purview of the access network designer, not SeaMoby.
 
Gary

-----Original Message-----
From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
Sent: Wednesday, January 03, 2001 12:46 PM
To: 'Michael A. Ramalho'; Kenward, Gary [WDLN2:AN10:EXCH];
seamoby@diameter.org
Subject: RE: [seamoby] cart-before-seamoby




These seem to be related to a particular network technology, right?

That is ... given a network (radio/spectrum) design ... then "network
handoff triggers" are determined by the network designers ... and these
triggers can use such information to help determine when the
"triggering events" should be requested, right?
 
Is this not for wireless networks?
 
If so, then EVERY wireless network has a RF signal.  Not just Bluetooth.
And every radio I have ever put my hands in has had a RSSI.
This includes Shortwave, VHF, UHF, Microwave, Bluetooth and yes even cell
phones.
This is how a radio measures the signal strength.  Some radios called it the
Recieve Signal 
Strength Indicator, while others call it the Radio Signal Strength
Indicator.
This is fundemental.   Fundemental wireless terminology.
Look on your cell phone display, you will see it.
 
If you want to come up with a wireless protocol you must be willing and able
to learn and use some basic wireless terminology.
 
If you are working on a wired protocol then you should say so.
 
 
 
- Kulwinder
 
 


------_=_NextPart_001_01C075D9.530E408D
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=543050223-03012001><FONT face=Arial color=#0000ff size=2>Thanks 
for the backgrounder.&nbsp; I was not aware this was in our 
charter.</FONT></SPAN></DIV>
<DIV><SPAN class=543050223-03012001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=543050223-03012001><FONT face=Arial color=#0000ff size=2>- 
Kulwinder.</FONT></SPAN></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:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, January 03, 
  2001 5:50 PM<BR><B>To:</B> 'Kulwinder Atwal'; 'Michael A. Ramalho'; 
  seamoby@diameter.org<BR><B>Subject:</B> RE: [seamoby] 
  cart-before-seamoby<BR><BR></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>Someone at the 
  CRAPS BOF was adamant - and I agree - that</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>seamless 
  mobility should support handover between access </SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>networks (full 
  stop).</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=040593422-03012001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>By definition, 
  some of these access networks may be wired. Some</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>of these access 
  networks may involve wireless links where the</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>sensing and 
  calculation of RSSI is either meaningless, or 
uneconomical.</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>The origin of 
  the "handoff trigger" as someone called it, is the </SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>purview of the 
  access</SPAN></FONT><FONT face="Comic Sans MS"><SPAN class=040593422-03012001> 
  network designer, not SeaMoby.</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=040593422-03012001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=040593422-03012001>Gary</SPAN></FONT></DIV>
  <BLOCKQUOTE 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000080 2px solid; MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Kulwinder Atwal 
    [mailto:kulwinder.atwal@zucotto.com]<BR><B>Sent:</B> Wednesday, January 03, 
    2001 12:46 PM<BR><B>To:</B> 'Michael A. Ramalho'; Kenward, Gary 
    [WDLN2:AN10:EXCH]; seamoby@diameter.org<BR><B>Subject:</B> RE: [seamoby] 
    cart-before-seamoby<BR><BR></DIV></FONT><FONT face=Arial color=#0000ff 
    size=2></FONT>
    <DIV><FONT face=Arial color=#0000ff size=2></FONT><FONT face=Arial 
    color=#0000ff size=2></FONT><BR>These seem to be related to a particular 
    network technology, right?<BR><BR>That is ... given a network 
    (radio/spectrum) design ... then "network<BR>handoff triggers" are 
    determined by the network designers ... and these<BR>triggers can use such 
    information to help determine when the<BR>"triggering events" should be 
    requested, right?<BR><SPAN class=121242917-03012001><FONT face=Arial 
    color=#0000ff size=2>&nbsp;</FONT></SPAN></DIV>
    <DIV><SPAN class=121242917-03012001><FONT face=Arial color=#0000ff size=2>Is 
    this not for wireless networks?</FONT></SPAN></DIV>
    <DIV><SPAN class=121242917-03012001><FONT face=Arial color=#0000ff 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=121242917-03012001><FONT face=Arial color=#0000ff size=2>If 
    so, then EVERY wireless network has a RF signal.&nbsp; Not just 
    Bluetooth.</FONT></SPAN></DIV>
    <DIV><SPAN class=121242917-03012001><FONT face=Arial color=#0000ff 
    size=2>And&nbsp;every radio I&nbsp;have ever put my hands in has had a 
    RSSI.</FONT></SPAN></DIV>
    <DIV><SPAN class=121242917-03012001><FONT face=Arial color=#0000ff 
    size=2>This&nbsp;includes Shortwave, VHF, UHF, Microwave, Bluetooth and yes 
    even cell phones.</FONT></SPAN></DIV>
    <DIV><SPAN class=121242917-03012001><FONT face=Arial color=#0000ff 
    size=2>This is how a radio measures </FONT><SPAN 
    class=121242917-03012001><FONT face=Arial color=#0000ff size=2>the signal 
    strength.&nbsp; Some radios called it the Recieve Signal 
    </FONT></SPAN></SPAN></DIV>
    <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
    face=Arial color=#0000ff size=2>Strength Indicator, while others call it the 
    Radio Signal Strength Indicator.</FONT></SPAN></SPAN></DIV>
    <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
    face=Arial color=#0000ff size=2>This is fundemental.&nbsp;&nbsp; Fundemental 
    wireless terminology.</FONT></SPAN></SPAN></DIV>
    <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
    face=Arial color=#0000ff size=2>Look on your cell phone display, you will 
    see it.</FONT></SPAN></SPAN></DIV>
    <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
    face=Arial color=#0000ff size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
    face=Arial color=#0000ff size=2>If you want to come up with a wireless 
    protocol you must be willing and able to learn and use some basic wireless 
    terminology.</FONT></SPAN></SPAN></DIV>
    <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
    face=Arial color=#0000ff size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
    face=Arial color=#0000ff size=2>If you are working on a wired protocol then 
    you should say so.</FONT></SPAN></SPAN></DIV>
    <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
    face=Arial color=#0000ff size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
    face=Arial color=#0000ff size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
    face=Arial color=#0000ff size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
    face=Arial color=#0000ff size=2>- Kulwinder</FONT></SPAN></SPAN></DIV>
    <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
    face=Arial color=#0000ff size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
    <DIV><SPAN 
class=121242917-03012001></SPAN>&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C075D9.530E408D--


From owner-seamoby@diameter.org  Wed Jan  3 20:07:05 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11159
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 20:07:04 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f040LQh04086
	for seamoby-list; Wed, 3 Jan 2001 16:21:26 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f040LNW04081
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 16:21:23 -0800
Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com;
          Wed, 3 Jan 2001 18:28:46 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBPB2N>; Wed, 3 Jan 2001 18:28:53 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8A6A@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>,
        "'James Kempf'" <James.Kempf@eng.sun.com>, mruckstuhl@MeshNetworks.com,
        kulwinder.atwal@herc.zucotto.com, seamoby@diameter.org
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
Date: Wed, 3 Jan 2001 18:28:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C075DC.EAAD1340"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C075DC.EAAD1340
Content-Type: text/plain;
	charset="iso-8859-1"

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. 

   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:kulwinder.atwal@zucotto.com]
Sent: Wednesday, January 03, 2001 6:01 PM
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf';
mruckstuhl@meshnetworks.com; kulwinder.atwal@herc.zucotto.com;
seamoby@diameter.org
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:gkenward@nortelnetworks.com]
Sent: Wednesday, January 03, 2001 5:40 PM
To: 'Kulwinder Atwal'; 'James Kempf'; mruckstuhl@meshnetworks.com;
kulwinder.atwal@herc.zucotto.com; seamoby@diameter.org
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. 
> 

------_=_NextPart_001_01C075DC.EAAD1340
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: [seamoby] MicroMobility Algorithm Outline Revision =
0.0001</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Kulwinder:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; An IP handover solution for real time =
signals over a wireless link can be</FONT>
<BR><FONT SIZE=3D2>designed, if the link is designed to support IP =
packet communications (versus</FONT>
<BR><FONT SIZE=3D2>CBR voice communications), and if the access network =
is designed to support</FONT>
<BR><FONT SIZE=3D2>handover.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; I am not sure what Bluetooth is or isn't =
capable of, but my</FONT>
<BR><FONT SIZE=3D2>point was, if Bluetooth has limitations, then so be =
it. This is not the concern</FONT>
<BR><FONT SIZE=3D2>of SeaMoby, and I do not understand why you bring up =
the issue here. </FONT>
</P>

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

<P><FONT SIZE=3D2>Gary</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Kulwinder Atwal [<A =
HREF=3D"mailto:kulwinder.atwal@zucotto.com">mailto:kulwinder.atwal@zucot=
to.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, January 03, 2001 6:01 PM</FONT>
<BR><FONT SIZE=3D2>To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf'; =
mruckstuhl@meshnetworks.com; kulwinder.atwal@herc.zucotto.com; =
seamoby@diameter.org</FONT></P>

<P><FONT SIZE=3D2>Subject: RE: [seamoby] MicroMobility Algorithm =
Outline Revision 0.0001</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>1. I can't do it with IP over a wireless link.</FONT>
<BR><FONT SIZE=3D2>2. I can do it without IP over a wireless link. =
</FONT>
<BR><FONT SIZE=3D2>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=3D2>4. And with L2 over the Bluetooth wireless =
link.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>- Kulwinder.</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Gary Kenward [<A =
HREF=3D"mailto:gkenward@nortelnetworks.com">mailto:gkenward@nortelnetwor=
ks.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, January 03, 2001 5:40 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Kulwinder Atwal'; 'James Kempf'; =
mruckstuhl@meshnetworks.com; kulwinder.atwal@herc.zucotto.com; =
seamoby@diameter.org</FONT></P>

<P><FONT SIZE=3D2>Subject: RE: [seamoby] MicroMobility Algorithm =
Outline Revision 0.0001</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>If it is true that you cannot perform &quot;real =
time&quot; seamless handover with </FONT>
<BR><FONT SIZE=3D2>Bluetooth because of the link protocol definition, =
then this is a problem with </FONT>
<BR><FONT SIZE=3D2>the Bluetooth design, and naturally SeaMob cannot =
undo limitations of the </FONT>
<BR><FONT SIZE=3D2>wireless subnetwork or link layer design. </FONT>
<BR><FONT SIZE=3D2>I suspect there is an approach involving simulcast =
that would get around </FONT>
<BR><FONT SIZE=3D2>the problem, Kulwinder, but discussion of link layer =
problems and solutions </FONT>
<BR><FONT SIZE=3D2>do not belong on this list. </FONT>
<BR><FONT SIZE=3D2>This does, however, bring up the issue of n-casting =
(where n &gt; 1 and n &lt;=3D all APs), </FONT>
<BR><FONT SIZE=3D2>as possible solution to be addressed when we around =
to working on solutions. </FONT>
<BR><FONT SIZE=3D2>Gary </FONT>
<BR><FONT SIZE=3D2>&gt; You can do SAR. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; But, you CANNOT fit a whole IPv6 packet in one =
slot when you </FONT>
<BR><FONT SIZE=3D2>&gt; have seven </FONT>
<BR><FONT SIZE=3D2>&gt; slaves.&nbsp; Each slave gets one packet per =
one slot per 10 mSec. </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; It will take </FONT>
<BR><FONT SIZE=3D2>&gt; several slots per slave to do one IPv6 =
packet.&nbsp; Therefore, it </FONT>
<BR><FONT SIZE=3D2>&gt; will take </FONT>
<BR><FONT SIZE=3D2>&gt; longer that 10 mSec.&nbsp; For real-time the =
limit is 10 mSec.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; Therefore, within </FONT>
<BR><FONT SIZE=3D2>&gt; 10 mSec the max packet payload is 28 bytes. =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; So if you want to do real-time seamless =
mobility using IPv6 ( </FONT>
<BR><FONT SIZE=3D2>&gt; meaning you </FONT>
<BR><FONT SIZE=3D2>&gt; want to use an IPv6 packet to switch a slave) =
it cannot be </FONT>
<BR><FONT SIZE=3D2>&gt; done because you </FONT>
<BR><FONT SIZE=3D2>&gt; will go well over the 10 mSec time limit. =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; To summerize, SAR yes. </FONT>
<BR><FONT SIZE=3D2>&gt; Real-time Seamless Mobility (switch slaves =
using IPv6 in 10 mSec) </FONT>
<BR><FONT SIZE=3D2>&gt; mathematically not possible. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Also, read my email to follow regarding what =
you saw in the </FONT>
<BR><FONT SIZE=3D2>&gt; June IETF BOF </FONT>
<BR><FONT SIZE=3D2>&gt; for Bluetooth. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; - Kulwinder. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C075DC.EAAD1340--


From owner-seamoby@diameter.org  Wed Jan  3 20:15:38 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11267
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 20:15:36 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f040ToJ04099
	for seamoby-list; Wed, 3 Jan 2001 16:29:50 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f040TmW04094
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 16:29:48 -0800
Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com;
          Wed, 3 Jan 2001 18:37:02 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBPBKM>; Wed, 3 Jan 2001 18:37:09 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8A6B@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>,
        "'Kulwinder Atwal'" <kulwinder.atwal@herc.zucotto.com>,
        "'Michael A. Ramalho'" <mramalho@cisco.com>, seamoby@diameter.org
Subject: RE: [seamoby] cart-before-seamoby
Date: Wed, 3 Jan 2001 18:37:00 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C075DE.11DE3A60"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C075DE.11DE3A60
Content-Type: text/plain;
	charset="iso-8859-1"

Actually, after a quick review of the charter there is no 
specific reference to wireline or wireless, just access networks.
 
There is a paragraph the refers to "3G SDOs", which I do
not believe belongs in the charter. If we are to expect 
requirements input from the various 3G camps (I'm not
even sure what an "SDO" is, could someone remind me).,
then the charter should also identify all the current and potential
sources of input: 2G, ITU, ANSI, IEEE, public wireless LAN operators
(do they have a label yet?), WMF, private wireless LAN providers, etc.
- I think you get the idea.
 
Pat: I'm not sure we are allowed to, but I strongly request that
this paragraph be struck from the charter.
 
Gary
========================================================================== 

-----Original Message-----
From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
Sent: Wednesday, January 03, 2001 6:03 PM
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Kulwinder Atwal'; 'Michael A.
Ramalho'; seamoby@diameter.org
Subject: RE: [seamoby] cart-before-seamoby


Thanks for the backgrounder.  I was not aware this was in our charter.
 
- Kulwinder.

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Wednesday, January 03, 2001 5:50 PM
To: 'Kulwinder Atwal'; 'Michael A. Ramalho'; seamoby@diameter.org
Subject: RE: [seamoby] cart-before-seamoby


Someone at the CRAPS BOF was adamant - and I agree - that
seamless mobility should support handover between access 
networks (full stop).
 
By definition, some of these access networks may be wired. Some
of these access networks may involve wireless links where the
sensing and calculation of RSSI is either meaningless, or uneconomical.
The origin of the "handoff trigger" as someone called it, is the 
purview of the access network designer, not SeaMoby.
 
Gary

-----Original Message-----
From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
Sent: Wednesday, January 03, 2001 12:46 PM
To: 'Michael A. Ramalho'; Kenward, Gary [WDLN2:AN10:EXCH];
seamoby@diameter.org
Subject: RE: [seamoby] cart-before-seamoby




These seem to be related to a particular network technology, right?

That is ... given a network (radio/spectrum) design ... then "network
handoff triggers" are determined by the network designers ... and these
triggers can use such information to help determine when the
"triggering events" should be requested, right?
 
Is this not for wireless networks?
 
If so, then EVERY wireless network has a RF signal.  Not just Bluetooth.
And every radio I have ever put my hands in has had a RSSI.
This includes Shortwave, VHF, UHF, Microwave, Bluetooth and yes even cell
phones.
This is how a radio measures the signal strength.  Some radios called it the
Recieve Signal 
Strength Indicator, while others call it the Radio Signal Strength
Indicator.
This is fundemental.   Fundemental wireless terminology.
Look on your cell phone display, you will see it.
 
If you want to come up with a wireless protocol you must be willing and able
to learn and use some basic wireless terminology.
 
If you are working on a wired protocol then you should say so.
 
 
 
- Kulwinder
 
 


------_=_NextPart_001_01C075DE.11DE3A60
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face="Comic Sans MS"><SPAN class=740422023-03012001>Actually, after a 
quick review of the charter there is no </SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=740422023-03012001>specific 
reference to wireline or wireless, just access networks.</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=740422023-03012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=740422023-03012001>There is a 
paragraph the refers to "3G SDOs", which I do</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=740422023-03012001>not believe 
belongs in the charter. If we are to expect </SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=740422023-03012001>requirements 
input from the various 3G camps (I'm not</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=740422023-03012001>even sure what an 
"SDO" is, could someone remind me).,</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=740422023-03012001>then the charter 
should also identify all the current and potential</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=740422023-03012001>sources of input: 
2G, ITU, ANSI, IEEE, public wireless LAN operators</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=740422023-03012001>(do they have a 
label yet?), WMF, private wireless LAN providers, etc.</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=740422023-03012001>- I think you get 
the idea.</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=740422023-03012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=740422023-03012001>Pat: I'm not sure 
we are allowed to, but I strongly request that</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=740422023-03012001>this paragraph be 
struck from the charter.</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=740422023-03012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=740422023-03012001>Gary</SPAN></FONT><BR><FONT color=#800080 face=Arial 
size=1>==========================================================================</FONT> 
</DIV>
<BLOCKQUOTE dir=ltr 
style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Kulwinder Atwal 
  [mailto:kulwinder.atwal@zucotto.com]<BR><B>Sent:</B> Wednesday, January 03, 
  2001 6:03 PM<BR><B>To:</B> Kenward, Gary [WDLN2:AN10:EXCH]; 'Kulwinder Atwal'; 
  'Michael A. Ramalho'; seamoby@diameter.org<BR><B>Subject:</B> RE: [seamoby] 
  cart-before-seamoby<BR><BR></DIV></FONT>
  <DIV><SPAN class=543050223-03012001><FONT color=#0000ff face=Arial 
  size=2>Thanks for the backgrounder.&nbsp; I was not aware this was in our 
  charter.</FONT></SPAN></DIV>
  <DIV><SPAN class=543050223-03012001><FONT color=#0000ff face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=543050223-03012001><FONT color=#0000ff face=Arial size=2>- 
  Kulwinder.</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=ltr 
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
    [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, January 03, 
    2001 5:50 PM<BR><B>To:</B> 'Kulwinder Atwal'; 'Michael A. Ramalho'; 
    seamoby@diameter.org<BR><B>Subject:</B> RE: [seamoby] 
    cart-before-seamoby<BR><BR></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>Someone at 
    the CRAPS BOF was adamant - and I agree - that</SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>seamless 
    mobility should support handover between access </SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>networks 
    (full stop).</SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN 
    class=040593422-03012001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>By 
    definition, some of these access networks may be wired. 
    Some</SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>of these 
    access networks may involve wireless links where the</SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>sensing and 
    calculation of RSSI is either meaningless, or 
    uneconomical.</SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>The origin of 
    the "handoff trigger" as someone called it, is the </SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=040593422-03012001>purview of 
    the access</SPAN></FONT><FONT face="Comic Sans MS"><SPAN 
    class=040593422-03012001> network designer, not SeaMoby.</SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN 
    class=040593422-03012001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN 
    class=040593422-03012001>Gary</SPAN></FONT></DIV>
    <BLOCKQUOTE 
    style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
      <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
      size=2>-----Original Message-----<BR><B>From:</B> Kulwinder Atwal 
      [mailto:kulwinder.atwal@zucotto.com]<BR><B>Sent:</B> Wednesday, January 
      03, 2001 12:46 PM<BR><B>To:</B> 'Michael A. Ramalho'; Kenward, Gary 
      [WDLN2:AN10:EXCH]; seamoby@diameter.org<BR><B>Subject:</B> RE: [seamoby] 
      cart-before-seamoby<BR><BR></DIV></FONT><FONT color=#0000ff face=Arial 
      size=2></FONT>
      <DIV><FONT color=#0000ff face=Arial size=2></FONT><FONT color=#0000ff 
      face=Arial size=2></FONT><BR>These seem to be related to a particular 
      network technology, right?<BR><BR>That is ... given a network 
      (radio/spectrum) design ... then "network<BR>handoff triggers" are 
      determined by the network designers ... and these<BR>triggers can use such 
      information to help determine when the<BR>"triggering events" should be 
      requested, right?<BR><SPAN class=121242917-03012001><FONT color=#0000ff 
      face=Arial size=2>&nbsp;</FONT></SPAN></DIV>
      <DIV><SPAN class=121242917-03012001><FONT color=#0000ff face=Arial 
      size=2>Is this not for wireless networks?</FONT></SPAN></DIV>
      <DIV><SPAN class=121242917-03012001><FONT color=#0000ff face=Arial 
      size=2></FONT></SPAN>&nbsp;</DIV>
      <DIV><SPAN class=121242917-03012001><FONT color=#0000ff face=Arial 
      size=2>If so, then EVERY wireless network has a RF signal.&nbsp; Not just 
      Bluetooth.</FONT></SPAN></DIV>
      <DIV><SPAN class=121242917-03012001><FONT color=#0000ff face=Arial 
      size=2>And&nbsp;every radio I&nbsp;have ever put my hands in has had a 
      RSSI.</FONT></SPAN></DIV>
      <DIV><SPAN class=121242917-03012001><FONT color=#0000ff face=Arial 
      size=2>This&nbsp;includes Shortwave, VHF, UHF, Microwave, Bluetooth and 
      yes even cell phones.</FONT></SPAN></DIV>
      <DIV><SPAN class=121242917-03012001><FONT color=#0000ff face=Arial 
      size=2>This is how a radio measures </FONT><SPAN 
      class=121242917-03012001><FONT color=#0000ff face=Arial size=2>the signal 
      strength.&nbsp; Some radios called it the Recieve Signal 
      </FONT></SPAN></SPAN></DIV>
      <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
      color=#0000ff face=Arial size=2>Strength Indicator, while others call it 
      the Radio Signal Strength Indicator.</FONT></SPAN></SPAN></DIV>
      <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
      color=#0000ff face=Arial size=2>This is fundemental.&nbsp;&nbsp; 
      Fundemental wireless terminology.</FONT></SPAN></SPAN></DIV>
      <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
      color=#0000ff face=Arial size=2>Look on your cell phone display, you will 
      see it.</FONT></SPAN></SPAN></DIV>
      <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
      color=#0000ff face=Arial size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
      <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
      color=#0000ff face=Arial size=2>If you want to come up with a wireless 
      protocol you must be willing and able to learn and use some basic wireless 
      terminology.</FONT></SPAN></SPAN></DIV>
      <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
      color=#0000ff face=Arial size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
      <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
      color=#0000ff face=Arial size=2>If you are working on a wired protocol 
      then you should say so.</FONT></SPAN></SPAN></DIV>
      <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
      color=#0000ff face=Arial size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
      <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
      color=#0000ff face=Arial size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
      <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
      color=#0000ff face=Arial size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
      <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
      color=#0000ff face=Arial size=2>- Kulwinder</FONT></SPAN></SPAN></DIV>
      <DIV><SPAN class=121242917-03012001><SPAN class=121242917-03012001><FONT 
      color=#0000ff face=Arial size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
      <DIV><SPAN 
  class=121242917-03012001></SPAN>&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C075DE.11DE3A60--


From owner-seamoby@diameter.org  Wed Jan  3 20:17:39 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11292
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 20:17:38 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f040ZT304118
	for seamoby-list; Wed, 3 Jan 2001 16:35:29 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f040ZQW04113
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 16:35:26 -0800
Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com;
          Wed, 3 Jan 2001 18:40:00 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBPBLB>; Wed, 3 Jan 2001 18:40:07 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8A6C@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Michael Thomas'" <mat@cisco.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        James Kempf <James.Kempf@eng.sun.com>, Phil_Neumiller@3Com.com,
        dblair@cisco.com, seamoby@diameter.org
Subject: RE: [seamoby] Micromobility Problem Statement
Date: Wed, 3 Jan 2001 18:39:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C075DE.7C2430F0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C075DE.7C2430F0
Content-Type: text/plain;
	charset="iso-8859-1"

Well, I think we actually agree, if I read your use of "partially"
correct. I am not religiously opposed to signalling over the air -
there may emerge some situations where that is the best solution.
However, I believe that signalling over the air should be minimized,
for many reasons (interference, delay, bandwidth consumption, security,
reliability all come to mind).

Gary

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Wednesday, January 03, 2001 6:07 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Michael Thomas'; Pat Calhoun; James Kempf; 
> Phil_Neumiller@3Com.com;
> dblair@cisco.com; seamoby@diameter.org
> Subject: RE: [seamoby] Micromobility Problem Statement
> 
> 
> Gary Kenward writes:
>  > I think Pat meant "signalling over the air interface", 
> please correct me if
>  > I am 
>  > wrong. This gets back to an earlier discussion of the 
> scarcity of bandwidth
>  > over the
>  > access link (or not, Phil). *Most* people who work in 
> wireless believe that
>  > however scarce
>  > or non-scarce wireless bandwidth might be, it's definitely 
> a heck of a  lot
>  > scarcer then
>  > wireline bandwidth. I suspect the ultimate source of that 
> scarcity is
>  > related to noise and
>  > Shannon's law.
>  > 
>  > I think its a good thing to keep signalling between the 
> host and the network
>  > to a minimum, 
>  > regardless.
> 
>    Back to requirements, I think I disagree -- or at least
>    partially. What's important for seamoby is that the 
>    amount of signaling (number of messages, number of bytes)
>    not interfere with in flight (real time/high priority) 
>    traffic. If messaging is not in the critical
>    path of a handoff, I think it's reasonable to
>    say that that's not seamoby's problem to
>    solve -- there are a lot of reasons why a
>    particular application may not be suitable for
>    a particular technology, after all.
> 
> 		Mike
> 

------_=_NextPart_001_01C075DE.7C2430F0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] Micromobility Problem Statement</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Well, I think we actually agree, if I read your use of &quot;partially&quot;</FONT>
<BR><FONT SIZE=2>correct. I am not religiously opposed to signalling over the air -</FONT>
<BR><FONT SIZE=2>there may emerge some situations where that is the best solution.</FONT>
<BR><FONT SIZE=2>However, I believe that signalling over the air should be minimized,</FONT>
<BR><FONT SIZE=2>for many reasons (interference, delay, bandwidth consumption, security,</FONT>
<BR><FONT SIZE=2>reliability all come to mind).</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Michael Thomas [<A HREF="mailto:mat@cisco.com">mailto:mat@cisco.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, January 03, 2001 6:07 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Cc: 'Michael Thomas'; Pat Calhoun; James Kempf; </FONT>
<BR><FONT SIZE=2>&gt; Phil_Neumiller@3Com.com;</FONT>
<BR><FONT SIZE=2>&gt; dblair@cisco.com; seamoby@diameter.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [seamoby] Micromobility Problem Statement</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Gary Kenward writes:</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; I think Pat meant &quot;signalling over the air interface&quot;, </FONT>
<BR><FONT SIZE=2>&gt; please correct me if</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; I am </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; wrong. This gets back to an earlier discussion of the </FONT>
<BR><FONT SIZE=2>&gt; scarcity of bandwidth</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; over the</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; access link (or not, Phil). *Most* people who work in </FONT>
<BR><FONT SIZE=2>&gt; wireless believe that</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; however scarce</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; or non-scarce wireless bandwidth might be, it's definitely </FONT>
<BR><FONT SIZE=2>&gt; a heck of a&nbsp; lot</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; scarcer then</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; wireline bandwidth. I suspect the ultimate source of that </FONT>
<BR><FONT SIZE=2>&gt; scarcity is</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; related to noise and</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; Shannon's law.</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; I think its a good thing to keep signalling between the </FONT>
<BR><FONT SIZE=2>&gt; host and the network</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; to a minimum, </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; regardless.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Back to requirements, I think I disagree -- or at least</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; partially. What's important for seamoby is that the </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; amount of signaling (number of messages, number of bytes)</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; not interfere with in flight (real time/high priority) </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; traffic. If messaging is not in the critical</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; path of a handoff, I think it's reasonable to</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; say that that's not seamoby's problem to</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; solve -- there are a lot of reasons why a</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; particular application may not be suitable for</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; a particular technology, after all.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mike</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C075DE.7C2430F0--


From owner-seamoby@diameter.org  Wed Jan  3 20:27:10 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11463
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 20:27:10 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f040KWW04079
	for seamoby-list; Wed, 3 Jan 2001 16:20:32 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f040KTW04074
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 16:20:29 -0800
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f03NQu109860;
	Wed, 3 Jan 2001 15:26:56 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104])
	by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f03NRuB15142;
	Wed, 3 Jan 2001 15:27:56 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 882569C9.00810E2E ; Wed, 3 Jan 2001 15:29:37 -0800
X-Lotus-FromDomain: 3COM
From: Phil_Neumiller@3Com.com
To: "Gary Kenward" <gkenward@nortelnetworks.com>, seamoby@diameter.org
Message-ID: <882569C9.00810B5A.00@hqoutbound.ops.3com.com>
Date: Wed, 3 Jan 2001 17:35:01 -0600
Subject: RE: [seamoby] Micromobility Problem Statement
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=2zZPg3NdUDHrB1Oy5ZEYTA0iCzKLjD0LWDX5PWV2bPz6caGm8Y91RvQ6"
Content-Disposition: inline
Sender: owner-seamoby@diameter.org
Precedence: bulk

--0__=2zZPg3NdUDHrB1Oy5ZEYTA0iCzKLjD0LWDX5PWV2bPz6caGm8Y91RvQ6
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline







Sent by:  "Gary Kenward" <gkenward@nortelnetworks.com>



I think Pat meant "signalling over the air interface", please correct me if
I am
wrong. This gets back to an earlier discussion of the scarcity of bandwidth
over the
access link (or not, Phil). *Most* people who work in wireless believe that
however scarce
or non-scarce wireless bandwidth might be, it's definitely a heck of a  lot
scarcer then
wireline bandwidth. I suspect the ultimate source of that scarcity is
related to noise and
Shannon's law.

PDN>I said that scarcity is "created" by those who benefit from selling
PDN>it, not that it did not exist.  More precisly there is a "scarcity"
PDN>inversion which explodes exponentially as the cell size decreases.
PDN>A local wireless technology has almost no scarcity problems given
PDN>sufficient "wired" backhaul. In fact the wireless bandwidth can
PDN>easily surpass the backhaul carrying capacity if one is not careful.
PDN>This can be exploited by technologies like 802.11a, Bluetooth, etc.,
PDN>to deconstruct the cellular business model.  If I were a carrier,
PDN>I would be afraid, VERY AFRAID!!!


--0__=2zZPg3NdUDHrB1Oy5ZEYTA0iCzKLjD0LWDX5PWV2bPz6caGm8Y91RvQ6
Content-type: text/html; 
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U
PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1Mi4zNSI+DQo8VElUTEU+UkU6IFtz
ZWFtb2J5XSBNaWNyb21vYmlsaXR5IFByb2JsZW0gU3RhdGVtZW50PC9USVRMRT4NCjwvSEVBRD4N
CjxCT0RZPg0KDQo8UD48Rk9OVCBTSVpFPTI+SSB0aGluayBQYXQgbWVhbnQgJnF1b3Q7c2lnbmFs
bGluZyBvdmVyIHRoZSBhaXIgaW50ZXJmYWNlJnF1b3Q7LCBwbGVhc2UgY29ycmVjdCBtZSBpZiBJ
IGFtIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+d3JvbmcuIFRoaXMgZ2V0cyBiYWNrIHRvIGFu
IGVhcmxpZXIgZGlzY3Vzc2lvbiBvZiB0aGUgc2NhcmNpdHkgb2YgYmFuZHdpZHRoIG92ZXIgdGhl
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5hY2Nlc3MgbGluayAob3Igbm90LCBQaGlsKS4gKk1v
c3QqIHBlb3BsZSB3aG8gd29yayBpbiB3aXJlbGVzcyBiZWxpZXZlIHRoYXQgaG93ZXZlciBzY2Fy
Y2U8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPm9yIG5vbi1zY2FyY2Ugd2lyZWxlc3MgYmFuZHdp
ZHRoIG1pZ2h0IGJlLCBpdCdzIGRlZmluaXRlbHkgYSBoZWNrIG9mIGEmbmJzcDsgbG90IHNjYXJj
ZXIgdGhlbjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+d2lyZWxpbmUgYmFuZHdpZHRoLiBJIHN1
c3BlY3QgdGhlIHVsdGltYXRlIHNvdXJjZSBvZiB0aGF0IHNjYXJjaXR5IGlzIHJlbGF0ZWQgdG8g
bm9pc2UgYW5kPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TaGFubm9uJ3MgbGF3LjwvRk9OVD4N
CjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkkgdGhpbmsgaXRzIGEgZ29vZCB0aGluZyB0byBrZWVw
IHNpZ25hbGxpbmcgYmV0d2VlbiB0aGUgaG9zdCBhbmQgdGhlIG5ldHdvcmsgdG8gYSBtaW5pbXVt
LCA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnJlZ2FyZGxlc3MuPC9GT05UPg0KPC9QPg0KDQo8
UD48Rk9OVCBTSVpFPTI+R3Vlc3Mgd2hhdCBmb2xrcywgd2UncmUgYmFjayBpbiBzb2x1dGlvbiBz
cGFjZSBhZ2Fpbi48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5HYXJ5PC9GT05UPg0K
PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBGcm9tOiBNaWNoYWVsIFRob21hcyBbPEEgSFJF
Rj0ibWFpbHRvOm1hdEBjaXNjby5jb20iPm1haWx0bzptYXRAY2lzY28uY29tPC9BPl08L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDAzLCAyMDAx
IDE6MDggUE08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgVG86IFBhdCBDYWxob3VuPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IENjOiBKYW1lcyBLZW1wZjsgUGhpbF9OZXVtaWxs
ZXJAM0NvbS5jb207IGRibGFpckBjaXNjby5jb207IEtlbndhcmQsPC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9Mj4mZ3Q7IEdhcnkgW1dETE4yOkFOMTA6RVhDSF07IHNlYW1vYnlAZGlhbWV0ZXIub3Jn
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFN1YmplY3Q6IFJFOiBbc2VhbW9ieV0gTWlj
cm9tb2JpbGl0eSBQcm9ibGVtIFN0YXRlbWVudDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0
OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj4mZ3Q7IFBhdCBDYWxob3VuIHdyaXRlczo8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsm
bmJzcDsgJmd0OyBtb3JlIHNpZ25hbGluZyAhPSBzZWFtbGVzczwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsmbmJzcDsmbmJz
cDsgVGhlcmUgYWluJ3Qgbm8gc3VjaCB0aGluZyBhcyBhIGZyZWUgbHVuY2guIEFsc286IGl0J3Mg
bm90PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVudGly
ZWx5IGNsZWFyIHdoZXRoZXIgTDIgYmxvY2tpbmcgaXMgdXNlZnVsIGhlcmUgb3I8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbm90LiBJZiBpdCBpcywgbW9k
dWxhcml0eSBtYXkgYmUgdGhlIGJldHRlciBkaXJlY3Rpb24uPC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9Mj4mZ3Q7Jm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyAmZ3Q7
IEZvciB0aGF0IG1hdHRlciwgaXQgYXBwZWFycyBhcyBpZiBkaWZmc2VydiBuZWVkcyB0byBiZSA8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgdXNlZCBpbiB0aGUgY29yZS4gTm93LDwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyAmZ3Q7IHBlcmhhcHMgc29tZSBzaWduYWxp
bmcgZnJvbSB0aGUgbW9iaWxlIGlzIG5lZWRlZCB0byBnZXQgPC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9Mj4mZ3Q7IHRoZSBlZGdlIGRldmljZSB0bzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0
OyZuYnNwOyAmZ3Q7ICZxdW90O3Jlc2VydmUmcXVvdDsgdGhlIHJlc291cmNlcy4gVGhpcyBpbmZv
cm1hdGlvbiBjYW4gYmUgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHRyYW5zZmVyZWQg
aW4gdGhlIGNvbnRleHQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsgJmd0OyB0
cmFuc2Zlciwgc28gbm8gbmV3IHNpZ25hbGluZyB3b3VsZCBiZSBuZWVkZWQgYnkgdGhlIG1vYmls
ZS48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgZG9uJ3Qgc2VlIGhvdyBpdCdzIG91ciBjaG9pY2Ug
dG8gbWFuZGF0ZSBkaWZmc2Vydjs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsm
bmJzcDsmbmJzcDsgd2UncmUgbm90IHRoZSBwcm90b2NvbCBwb2xpY2UgYWZ0ZXIgYWxsLiBUaGUg
ZmFjdCBpczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyB0
aGF0IHNvbWUgbmV0d29ya3Mgd2lsbCBiZSBidWlsdCB3aXRoIEludHNlcnYgYW5kL29yPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEludHNlcnYvRGlmZnNl
cnYgbWl4ZXMuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTI+Jmd0OyZuYnNwOyAmZ3Q7IFRoaXMsIG9mIGNvdXJzZSwgYWxzbyBuZWVkcyB0byB3
b3JrIGFjcm9zcyBkb21haW5zLCBzbyB0aGUgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7
IFFvUyBpbmZvIHRyYW5zZmVyZWQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsg
Jmd0OyB3b3VsZCBoYXZlIHRvIGJlICZxdW90O2dlbmVyaWMmcXVvdDssIGFuZCBhYmxlIHRvIGJl
IG1hcHBlZCB0byB0aGUgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGxvY2FsIERTQ1Au
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+
Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBTdXJlLiBUaGUgc2FtZSBnb2VzIGZvciBzaWduYWxlZCBR
b1MgdG9vLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyBNaWtlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjwv
UD4NCg0KPC9CT0RZPg0KPC9IVE1MPg0K

--0__=2zZPg3NdUDHrB1Oy5ZEYTA0iCzKLjD0LWDX5PWV2bPz6caGm8Y91RvQ6--



From owner-seamoby@diameter.org  Wed Jan  3 20:31:54 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11584
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 20:31:51 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f040ao904136
	for seamoby-list; Wed, 3 Jan 2001 16:36:50 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f040alW04131
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 16:36:48 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <ZJFR8VKJ>; Wed, 3 Jan 2001 18:44:23 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B73@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'Kulwinder Atwal'"
	 <kulwinder.atwal@herc.zucotto.com>,
        "'James Kempf'"
	 <James.Kempf@eng.sun.com>,
        mruckstuhl@MeshNetworks.com, kulwinder.atwal@herc.zucotto.com,
        seamoby@diameter.org
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
Date: Wed, 3 Jan 2001 18:44:20 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C075DF.195A16D0"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C075DF.195A16D0
Content-Type: text/plain;
	charset="iso-8859-1"

 

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Wednesday, January 03, 2001 6:29 PM
To: 'Kulwinder Atwal'; 'James Kempf'; mruckstuhl@meshnetworks.com;
kulwinder.atwal@herc.zucotto.com; seamoby@diameter.org
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:kulwinder.atwal@zucotto.com
<mailto:kulwinder.atwal@zucotto.com> ] 
Sent: Wednesday, January 03, 2001 6:01 PM 
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf';
mruckstuhl@meshnetworks.com; kulwinder.atwal@herc.zucotto.com;
seamoby@diameter.org

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:gkenward@nortelnetworks.com
<mailto:gkenward@nortelnetworks.com> ] 
Sent: Wednesday, January 03, 2001 5:40 PM 
To: 'Kulwinder Atwal'; 'James Kempf'; mruckstuhl@meshnetworks.com;
kulwinder.atwal@herc.zucotto.com; seamoby@diameter.org

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


------_=_NextPart_001_01C075DF.195A16D0
Content-Type: text/html;
	charset="iso-8859-1"

<!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:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, January 03, 
  2001 6:29 PM<BR><B>To:</B> 'Kulwinder Atwal'; 'James Kempf'; 
  mruckstuhl@meshnetworks.com; kulwinder.atwal@herc.zucotto.com; 
  seamoby@diameter.org<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:kulwinder.atwal@zucotto.com">mailto:kulwinder.atwal@zucotto.com</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'; 
  mruckstuhl@meshnetworks.com; kulwinder.atwal@herc.zucotto.com; 
  seamoby@diameter.org</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:gkenward@nortelnetworks.com">mailto:gkenward@nortelnetworks.com</A>]</FONT> 
  <BR><FONT size=2>Sent: Wednesday, January 03, 2001 5:40 PM</FONT> <BR><FONT 
  size=2>To: 'Kulwinder Atwal'; 'James Kempf'; mruckstuhl@meshnetworks.com; 
  kulwinder.atwal@herc.zucotto.com; seamoby@diameter.org</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>

------_=_NextPart_001_01C075DF.195A16D0--


From owner-seamoby@diameter.org  Wed Jan  3 20:36:38 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11661
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 20:36:37 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f040iaV04150
	for seamoby-list; Wed, 3 Jan 2001 16:44:36 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f040iXW04145
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 16:44:33 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 3 Jan 2001 18:51:52 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBPBM9>; Wed, 3 Jan 2001 18:51:59 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8A6D@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Phil_Neumiller@3com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
Subject: RE: [seamoby] Micromobility Problem Statement
Date: Wed, 3 Jan 2001 18:51:51 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C075E0.24B1A580"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C075E0.24B1A580
Content-Type: text/plain;
	charset="iso-8859-1"


> -----Original Message-----
> From: Phil_Neumiller@3com.com [mailto:Phil_Neumiller@3com.com]
> Sent: Wednesday, January 03, 2001 6:35 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@diameter.org
> Subject: RE: [seamoby] Micromobility Problem Statement
> 
> 
> 
> 
> 
> 
> 
> 
> Sent by:  "Gary Kenward" <gkenward@nortelnetworks.com>
> 
> 
> 
> I think Pat meant "signalling over the air interface", please 
> correct me if
> I am
> wrong. This gets back to an earlier discussion of the 
> scarcity of bandwidth
> over the
> access link (or not, Phil). *Most* people who work in 
> wireless believe that
> however scarce
> or non-scarce wireless bandwidth might be, it's definitely a 
> heck of a  lot
> scarcer then
> wireline bandwidth. I suspect the ultimate source of that scarcity is
> related to noise and
> Shannon's law.
> 
> PDN>I said that scarcity is "created" by those who benefit 
> from selling
> PDN>it, not that it did not exist.  More precisly there is a 
> "scarcity"
> PDN>inversion which explodes exponentially as the cell size decreases.
> PDN>A local wireless technology has almost no scarcity problems given
> PDN>sufficient "wired" backhaul. In fact the wireless bandwidth can

This is true only if you assume a certain traffic model. I agree that
if you target laptop email users with a 1 meter cell, it is unlikely that
you will use up all the bandwidth (and more likely that infrastructure 
costs will now dominate). The ultimate coverage scenario is a spot beam
per user, however, demand always exceeds supply. 

The fact that certain organizations, government and commercial, have
taken advantage of the scarcity of wireless bandwidth, does not make
the bandwidth any less scarce.

> PDN>easily surpass the backhaul carrying capacity if one is 
> not careful.
> PDN>This can be exploited by technologies like 802.11a, 
> Bluetooth, etc.,
> PDN>to deconstruct the cellular business model.  If I were a carrier,
> PDN>I would be afraid, VERY AFRAID!!!

Who is going to build these 802.11a networks and provide them to users
for free? I agree that the current cellular business models for wireless
data don't make alot of sense. I also have reason to believe that many 
of the executives of these cellular businesses would agree that a better
business model is required. But note, there is not a proven model
for a profitable wireline access provider, never mind wireless access.

Anyway, sorry to press that button. Back on topic.

Gary

------_=_NextPart_001_01C075E0.24B1A580
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] Micromobility Problem Statement</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Phil_Neumiller@3com.com [<A HREF="mailto:Phil_Neumiller@3com.com">mailto:Phil_Neumiller@3com.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, January 03, 2001 6:35 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@diameter.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [seamoby] Micromobility Problem Statement</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Sent by:&nbsp; &quot;Gary Kenward&quot; &lt;gkenward@nortelnetworks.com&gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I think Pat meant &quot;signalling over the air interface&quot;, please </FONT>
<BR><FONT SIZE=2>&gt; correct me if</FONT>
<BR><FONT SIZE=2>&gt; I am</FONT>
<BR><FONT SIZE=2>&gt; wrong. This gets back to an earlier discussion of the </FONT>
<BR><FONT SIZE=2>&gt; scarcity of bandwidth</FONT>
<BR><FONT SIZE=2>&gt; over the</FONT>
<BR><FONT SIZE=2>&gt; access link (or not, Phil). *Most* people who work in </FONT>
<BR><FONT SIZE=2>&gt; wireless believe that</FONT>
<BR><FONT SIZE=2>&gt; however scarce</FONT>
<BR><FONT SIZE=2>&gt; or non-scarce wireless bandwidth might be, it's definitely a </FONT>
<BR><FONT SIZE=2>&gt; heck of a&nbsp; lot</FONT>
<BR><FONT SIZE=2>&gt; scarcer then</FONT>
<BR><FONT SIZE=2>&gt; wireline bandwidth. I suspect the ultimate source of that scarcity is</FONT>
<BR><FONT SIZE=2>&gt; related to noise and</FONT>
<BR><FONT SIZE=2>&gt; Shannon's law.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; PDN&gt;I said that scarcity is &quot;created&quot; by those who benefit </FONT>
<BR><FONT SIZE=2>&gt; from selling</FONT>
<BR><FONT SIZE=2>&gt; PDN&gt;it, not that it did not exist.&nbsp; More precisly there is a </FONT>
<BR><FONT SIZE=2>&gt; &quot;scarcity&quot;</FONT>
<BR><FONT SIZE=2>&gt; PDN&gt;inversion which explodes exponentially as the cell size decreases.</FONT>
<BR><FONT SIZE=2>&gt; PDN&gt;A local wireless technology has almost no scarcity problems given</FONT>
<BR><FONT SIZE=2>&gt; PDN&gt;sufficient &quot;wired&quot; backhaul. In fact the wireless bandwidth can</FONT>
</P>

<P><FONT SIZE=2>This is true only if you assume a certain traffic model. I agree that</FONT>
<BR><FONT SIZE=2>if you target laptop email users with a 1 meter cell, it is unlikely that</FONT>
<BR><FONT SIZE=2>you will use up all the bandwidth (and more likely that infrastructure </FONT>
<BR><FONT SIZE=2>costs will now dominate). The ultimate coverage scenario is a spot beam</FONT>
<BR><FONT SIZE=2>per user, however, demand always exceeds supply. </FONT>
</P>

<P><FONT SIZE=2>The fact that certain organizations, government and commercial, have</FONT>
<BR><FONT SIZE=2>taken advantage of the scarcity of wireless bandwidth, does not make</FONT>
<BR><FONT SIZE=2>the bandwidth any less scarce.</FONT>
</P>

<P><FONT SIZE=2>&gt; PDN&gt;easily surpass the backhaul carrying capacity if one is </FONT>
<BR><FONT SIZE=2>&gt; not careful.</FONT>
<BR><FONT SIZE=2>&gt; PDN&gt;This can be exploited by technologies like 802.11a, </FONT>
<BR><FONT SIZE=2>&gt; Bluetooth, etc.,</FONT>
<BR><FONT SIZE=2>&gt; PDN&gt;to deconstruct the cellular business model.&nbsp; If I were a carrier,</FONT>
<BR><FONT SIZE=2>&gt; PDN&gt;I would be afraid, VERY AFRAID!!!</FONT>
</P>

<P><FONT SIZE=2>Who is going to build these 802.11a networks and provide them to users</FONT>
<BR><FONT SIZE=2>for free? I agree that the current cellular business models for wireless</FONT>
<BR><FONT SIZE=2>data don't make alot of sense. I also have reason to believe that many </FONT>
<BR><FONT SIZE=2>of the executives of these cellular businesses would agree that a better</FONT>
<BR><FONT SIZE=2>business model is required. But note, there is not a proven model</FONT>
<BR><FONT SIZE=2>for a profitable wireline access provider, never mind wireless access.</FONT>
</P>

<P><FONT SIZE=2>Anyway, sorry to press that button. Back on topic.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C075E0.24B1A580--


From owner-seamoby@diameter.org  Wed Jan  3 20:37:36 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11681
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 20:37:34 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f041QfA04339
	for seamoby-list; Wed, 3 Jan 2001 17:26:41 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f041QdW04334
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 17:26:39 -0800
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id QAA11521;
	Wed, 3 Jan 2001 16:30:40 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA20454; Wed, 3 Jan 2001 16:30:40 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14931.50224.321506.272155@thomasm-u1.cisco.com>
Date: Wed, 3 Jan 2001 16:30:40 -0800 (PST)
To: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
Cc: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'Kulwinder Atwal'"
	 <kulwinder.atwal@herc.zucotto.com>,
        "'James Kempf'"
	 <James.Kempf@eng.sun.com>,
        mruckstuhl@MeshNetworks.com, seamoby@diameter.org
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
In-Reply-To: <FC0292EA4D13D34EA2E5FC728D70A8E3078B73@NEPTUNE.zucotto.com>
References: <FC0292EA4D13D34EA2E5FC728D70A8E3078B73@NEPTUNE.zucotto.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


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:
 >  
 > 
 > -----Original Message-----
 > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
 > Sent: Wednesday, January 03, 2001 6:29 PM
 > To: 'Kulwinder Atwal'; 'James Kempf'; mruckstuhl@meshnetworks.com;
 > kulwinder.atwal@herc.zucotto.com; seamoby@diameter.org
 > 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:kulwinder.atwal@zucotto.com
 > <mailto:kulwinder.atwal@zucotto.com> ] 
 > Sent: Wednesday, January 03, 2001 6:01 PM 
 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf';
 > mruckstuhl@meshnetworks.com; kulwinder.atwal@herc.zucotto.com;
 > seamoby@diameter.org
 > 
 > 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:gkenward@nortelnetworks.com
 > <mailto:gkenward@nortelnetworks.com> ] 
 > Sent: Wednesday, January 03, 2001 5:40 PM 
 > To: 'Kulwinder Atwal'; 'James Kempf'; mruckstuhl@meshnetworks.com;
 > kulwinder.atwal@herc.zucotto.com; seamoby@diameter.org
 > 
 > 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. 
 > > 
 > 
 > <!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:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, January 03, 
 >   2001 6:29 PM<BR><B>To:</B> 'Kulwinder Atwal'; 'James Kempf'; 
 >   mruckstuhl@meshnetworks.com; kulwinder.atwal@herc.zucotto.com; 
 >   seamoby@diameter.org<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:kulwinder.atwal@zucotto.com">mailto:kulwinder.atwal@zucotto.com</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'; 
 >   mruckstuhl@meshnetworks.com; kulwinder.atwal@herc.zucotto.com; 
 >   seamoby@diameter.org</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:gkenward@nortelnetworks.com">mailto:gkenward@nortelnetworks.com</A>]</FONT> 
 >   <BR><FONT size=2>Sent: Wednesday, January 03, 2001 5:40 PM</FONT> <BR><FONT 
 >   size=2>To: 'Kulwinder Atwal'; 'James Kempf'; mruckstuhl@meshnetworks.com; 
 >   kulwinder.atwal@herc.zucotto.com; seamoby@diameter.org</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>


From owner-seamoby@diameter.org  Wed Jan  3 20:52:18 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11883
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 20:52:18 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f041KfU04299
	for seamoby-list; Wed, 3 Jan 2001 17:20:41 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f041KcW04294
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 17:20:38 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <ZJFR8VK9>; Wed, 3 Jan 2001 19:28:13 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B74@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        Gary Kenward
	 <gkenward@nortelnetworks.com>
Cc: "'Kulwinder Atwal'" <kulwinder.atwal@herc.zucotto.com>,
        "'Michael A. Ramalho'" <mramalho@cisco.com>, seamoby@diameter.org
Subject: RE: [seamoby] cart-before-seamoby
Date: Wed, 3 Jan 2001 19:28:12 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

I think it should be removed.  We all know 3G means 3G cellular.
3G cellular is not the only access technology.
Maybe the reviewers had not considered Bluetooth?

- Kulwinder.

> -----Original Message-----
> From: Pat Calhoun [mailto:Pat.Calhoun@Eng.Sun.COM]
> Sent: Wednesday, January 03, 2001 6:40 PM
> To: Gary Kenward
> Cc: 'Kulwinder Atwal'; 'Kulwinder Atwal'; 'Michael A. Ramalho';
> seamoby@diameter.org
> Subject: RE: [seamoby] cart-before-seamoby
> 
> 
> > There is a paragraph the refers to "3G SDOs", which I do
> > not believe belongs in the charter. If we are to expect 
> > requirements input from the various 3G camps (I'm not
> > even sure what an "SDO" is, could someone remind me).,
> 
> SDO = Standards Defining Organization (e.g. TIA, ETSI, IEEE)
> 
> >
> > Pat: I'm not sure we are allowed to, but I strongly request that
> > this paragraph be struck from the charter.
> 
> I think that the paragraph was added to show certain possible 
> ties with some
> SDOs. It was not meant to be complete, and in no way ties us 
> to specific
> technologies. If people want it removed, I can talk to the 
> ADs and see what
> they think (but it did pass IESG review, and they know what 
> an SDO is :)
> 
> PatC
> 


From owner-seamoby@diameter.org  Wed Jan  3 21:30:10 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12435
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 21:30:09 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f041PH904316
	for seamoby-list; Wed, 3 Jan 2001 17:25:17 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from ns.kreative.net (root@ns.kreative.net [216.181.1.200])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f041PCW04307
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 17:25:13 -0800
Received: from david (laurelp-187.dsdial.net [216.181.253.187])
	by ns.kreative.net (8.9.3/8.9.3) with SMTP id TAA14212;
	Wed, 3 Jan 2001 19:41:48 -0500
Message-ID: <003501c075e6$628539c0$0100000a@david>
From: "Dave Martin" <dmartin@kreative.net>
To: "Kulwinder Atwal" <kulwinder.atwal@zucotto.com>,
        "'Michael A. Ramalho'" <mramalho@cisco.com>,
        "'Gary Kenward'" <gkenward@nortelnetworks.com>, <seamoby@diameter.org>
References: <FC0292EA4D13D34EA2E5FC728D70A8E3078B69@NEPTUNE.zucotto.com>
Subject: Re: [seamoby] cart-before-seamoby
Date: Wed, 3 Jan 2001 19:36:30 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0032_01C075BC.78D4FE60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-seamoby@diameter.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0032_01C075BC.78D4FE60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<Technical diatribe on RSSI>
I think we need to be careful when talking about RSSI.  My =
interpretation of RSSI is the received RF power as measured by the =
mobile of one or more of the base station carriers it is monitoring.  =
The mobile does not know that the RF power is generated by a particular =
base station, only that RF power exists in a band that those base =
stations operate in.  In the In some technologies (e.g., CDMA), the RF =
power received in a mobile's carrier frequency does not necessarily =
correlate to the performance (e.g., bit error rate).  RSSI is only a =
good indication of RF in situations where there is low or no =
interference.  In high interference situations (dense urban environments =
or having several ISM band CDMA products co-located) *raw* RSSI may not =
be a good indication of the best serving base station.  A better metric =
than RSSI would be some Signal to Noise (actually Signal to =
Noise+Interference) metric, however this requires that the signal be =
demodulated first and then compared to the ambient noise+interference.  =
A fairly costly (from the power perspective) thing to be doing =
constantly.
</Technical diatribe on RSSI>

Now a question ... I am having trouble understanding why layer 3 need to =
be invoved in physical layer metrics?  I would not expect a wireline =
router to route on some bit error rate metric, but would rather have the =
layer 2 protocols deal in their own way with bit errors, resulting in a =
throughput and latency metric, which I do think is valid for L3 =
decisions. For the wireless environment, I am not convinced that =
enhancing L3 to overcome shortcomings of poor (from the wirless mobility =
perspective) L2 protocols is the right approach.
  ----- Original Message -----=20
  From: Kulwinder Atwal=20
  To: 'Michael A. Ramalho' ; 'Gary Kenward' ; seamoby@diameter.org=20
  Sent: Wednesday, January 03, 2001 12:46 PM
  Subject: RE: [seamoby] cart-before-seamoby



  These seem to be related to a particular network technology, right?

  That is ... given a network (radio/spectrum) design ... then "network
  handoff triggers" are determined by the network designers ... and =
these
  triggers can use such information to help determine when the
  "triggering events" should be requested, right?
  =20
  Is this not for wireless networks?
  =20
  If so, then EVERY wireless network has a RF signal.  Not just =
Bluetooth.
  And every radio I have ever put my hands in has had a RSSI.
  This includes Shortwave, VHF, UHF, Microwave, Bluetooth and yes even =
cell phones.
  This is how a radio measures the signal strength.  Some radios called =
it the Recieve Signal=20
  Strength Indicator, while others call it the Radio Signal Strength =
Indicator.
  This is fundemental.   Fundemental wireless terminology.
  Look on your cell phone display, you will see it.
  =20
  If you want to come up with a wireless protocol you must be willing =
and able to learn and use some basic wireless terminology.
  =20
  If you are working on a wired protocol then you should say so.
  =20
  =20
  =20
  - Kulwinder
  =20
  =20

------=_NextPart_000_0032_01C075BC.78D4FE60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>&lt;Technical diatribe on =
RSSI&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I think we need to be careful when =
talking about=20
RSSI.&nbsp; My interpretation of RSSI is the&nbsp;received RF power as =
measured=20
by the mobile&nbsp;of&nbsp;one or more of the base station carriers it =
is=20
monitoring.&nbsp; The mobile does not know that the RF power is =
generated by a=20
particular base station, only that RF power exists in a band that those =
base=20
stations operate in.&nbsp; In the In some technologies (e.g., CDMA), the =
RF=20
power received in a mobile's carrier frequency does not necessarily =
correlate to=20
the performance (e.g., bit error rate).&nbsp; RSSI is only a good =
indication of=20
RF in situations where there is low or no interference.&nbsp; In high=20
interference situations (dense urban environments&nbsp;or having several =
ISM=20
band CDMA products co-located) *raw* RSSI may not be a good indication =
of the=20
best serving base station.&nbsp; A better metric than RSSI would be some =
Signal=20
to Noise (actually Signal to Noise+Interference) metric, however this =
requires=20
that the signal be demodulated first and then compared to the ambient=20
noise+interference.&nbsp; A fairly costly (from the power perspective) =
thing to=20
be doing constantly.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&lt;/Technical diatribe on =
RSSI&gt;</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Now a question ... I&nbsp;am having =
trouble=20
understanding why layer 3 need to be invoved in physical layer =
metrics?&nbsp; I=20
would not expect a wireline router to route on some bit error rate =
metric, but=20
would rather have the layer 2 protocols deal in their own way with bit =
errors,=20
resulting in a throughput and latency metric, which I do think is valid =
for L3=20
decisions.&nbsp;For the wireless environment, I am not convinced that =
enhancing=20
L3 to overcome shortcomings of poor (from the wirless mobility =
perspective) L2=20
protocols is the right approach.</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:kulwinder.atwal@zucotto.com"=20
  title=3Dkulwinder.atwal@zucotto.com>Kulwinder Atwal</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
href=3D"mailto:mramalho@cisco.com"=20
  title=3Dmramalho@cisco.com>'Michael A. Ramalho'</A> ; <A=20
  href=3D"mailto:gkenward@nortelnetworks.com"=20
  title=3Dgkenward@nortelnetworks.com>'Gary Kenward'</A> ; <A=20
  href=3D"mailto:seamoby@diameter.org"=20
  title=3Dseamoby@diameter.org>seamoby@diameter.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, January 03, =
2001 12:46=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: [seamoby]=20
  cart-before-seamoby</DIV>
  <DIV><BR></DIV><FONT color=3D#0000ff face=3DArial size=3D2></FONT>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2></FONT><FONT =
color=3D#0000ff=20
  face=3DArial size=3D2></FONT><BR>These seem to be related to a =
particular network=20
  technology, right?<BR><BR>That is ... given a network (radio/spectrum) =
design=20
  ... then "network<BR>handoff triggers" are determined by the network =
designers=20
  ... and these<BR>triggers can use such information to help determine =
when=20
  the<BR>"triggering events" should be requested, right?<BR><SPAN=20
  class=3D121242917-03012001><FONT color=3D#0000ff face=3DArial=20
  size=3D2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D121242917-03012001><FONT color=3D#0000ff =
face=3DArial size=3D2>Is=20
  this not for wireless networks?</FONT></SPAN></DIV>
  <DIV><SPAN class=3D121242917-03012001><FONT color=3D#0000ff =
face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D121242917-03012001><FONT color=3D#0000ff =
face=3DArial size=3D2>If=20
  so, then EVERY wireless network has a RF signal.&nbsp; Not just=20
  Bluetooth.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D121242917-03012001><FONT color=3D#0000ff =
face=3DArial=20
  size=3D2>And&nbsp;every radio I&nbsp;have ever put my hands in has had =
a=20
  RSSI.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D121242917-03012001><FONT color=3D#0000ff =
face=3DArial=20
  size=3D2>This&nbsp;includes Shortwave, VHF, UHF, Microwave, Bluetooth =
and yes=20
  even cell phones.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D121242917-03012001><FONT color=3D#0000ff =
face=3DArial size=3D2>This=20
  is how a radio measures </FONT><SPAN class=3D121242917-03012001><FONT=20
  color=3D#0000ff face=3DArial size=3D2>the signal strength.&nbsp; Some =
radios called=20
  it the Recieve Signal </FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=3D121242917-03012001><SPAN =
class=3D121242917-03012001><FONT=20
  color=3D#0000ff face=3DArial size=3D2>Strength Indicator, while others =
call it the=20
  Radio Signal Strength Indicator.</FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=3D121242917-03012001><SPAN =
class=3D121242917-03012001><FONT=20
  color=3D#0000ff face=3DArial size=3D2>This is fundemental.&nbsp;&nbsp; =
Fundemental=20
  wireless terminology.</FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=3D121242917-03012001><SPAN =
class=3D121242917-03012001><FONT=20
  color=3D#0000ff face=3DArial size=3D2>Look on your cell phone display, =
you will see=20
  it.</FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=3D121242917-03012001><SPAN =
class=3D121242917-03012001><FONT=20
  color=3D#0000ff face=3DArial =
size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D121242917-03012001><SPAN =
class=3D121242917-03012001><FONT=20
  color=3D#0000ff face=3DArial size=3D2>If you want to come up with a =
wireless=20
  protocol you must be willing and able to learn and use some basic =
wireless=20
  terminology.</FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=3D121242917-03012001><SPAN =
class=3D121242917-03012001><FONT=20
  color=3D#0000ff face=3DArial =
size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D121242917-03012001><SPAN =
class=3D121242917-03012001><FONT=20
  color=3D#0000ff face=3DArial size=3D2>If you are working on a wired =
protocol then=20
  you should say so.</FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=3D121242917-03012001><SPAN =
class=3D121242917-03012001><FONT=20
  color=3D#0000ff face=3DArial =
size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D121242917-03012001><SPAN =
class=3D121242917-03012001><FONT=20
  color=3D#0000ff face=3DArial =
size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D121242917-03012001><SPAN =
class=3D121242917-03012001><FONT=20
  color=3D#0000ff face=3DArial =
size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D121242917-03012001><SPAN =
class=3D121242917-03012001><FONT=20
  color=3D#0000ff face=3DArial size=3D2>- =
Kulwinder</FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=3D121242917-03012001><SPAN =
class=3D121242917-03012001><FONT=20
  color=3D#0000ff face=3DArial =
size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN=20
class=3D121242917-03012001>&nbsp;</SPAN></DIV></BLOCKQUOTE></BODY></HTML>=


------=_NextPart_000_0032_01C075BC.78D4FE60--



From owner-seamoby@diameter.org  Wed Jan  3 21:33:15 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12527
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 21:33:14 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f041kRL04357
	for seamoby-list; Wed, 3 Jan 2001 17:46:27 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f041kPW04352
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 17:46:25 -0800
Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com;
          Wed, 3 Jan 2001 19:46:15 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBPB4Y>; Wed, 3 Jan 2001 19:46:22 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8A71@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Dave Martin'" <dmartin@kreative.net>,
        Kulwinder Atwal <kulwinder.atwal@zucotto.com>,
        "'Michael A. Ramalho'" <mramalho@cisco.com>,
        seamoby <seamoby@diameter.org>
Subject: RE: [seamoby] cart-before-seamoby
Date: Wed, 3 Jan 2001 19:46:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C075E7.BD2A3910"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C075E7.BD2A3910
Content-Type: text/plain;
	charset="iso-8859-1"

-----Original Message-----
From: Dave Martin [mailto:dmartin@kreative.net]
Sent: Wednesday, January 03, 2001 7:37 PM
To: Kulwinder Atwal; 'Michael A. Ramalho'; Kenward, Gary [WDLN2:AN10:EXCH];
seamoby
Subject: Re: [seamoby] cart-before-seamoby


<Technical diatribe on RSSI>
I think we need to be careful when talking about RSSI.  My interpretation of
RSSI is the received RF power as measured by the mobile of one or more of
the base station carriers it is monitoring.  The mobile does not know that
the RF power is generated by a particular base station, only that RF power
exists in a band that those base stations operate in.  In the In some
technologies (e.g., CDMA), the RF power received in a mobile's carrier
frequency does not necessarily correlate to the performance (e.g., bit error
rate).  RSSI is only a good indication of RF in situations where there is
low or no interference.  In high interference situations (dense urban
environments or having several ISM band CDMA products co-located) *raw* RSSI
may not be a good indication of the best serving base station.  A better
metric than RSSI would be some Signal to Noise (actually Signal to
Noise+Interference) metric, however this requires that the signal be
demodulated first and then compared to the ambient noise+interference.  A
fairly costly (from the power perspective) thing to be doing constantly.
</Technical diatribe on RSSI>
 
Now a question ... I am having trouble understanding why layer 3 need to be
invoved in physical layer metrics?  I  
 
Layer 3 is not supposed to be involved with a particular physical layer
metric. That's how
this discussion began. I would prefer us to agree upon a "handoff trigger"
event delivered to layer 3 from layer 2, as an abstraction of the possible
layer 1-2 phenomena that actually might trigger a real handoff.
 
 would not expect a wireline router to route on some bit error rate metric,
but would rather have the layer 2 protocols deal in their own way with bit
errors, resulting in a throughput and latency metric, which I do think is
valid for L3 decisions. For the wireless environment, I am not convinced
that enhancing L3 to overcome shortcomings of poor (from the wirless
mobility perspective) L2 protocols is the right approach.  
Actually, good point. I recall vaguely from a previous life, reading about
failover in routers. Some interfaces keep track of physical layer quality
(sometimes BER, sometimes simply dc signals), and report a link failure
event, but not the quality measurement used to indicate link failure. I
think there is an analogy here.
 
Gary


------_=_NextPart_001_01C075E7.BD2A3910
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2314.1000" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<BLOCKQUOTE 
style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Dave Martin 
  [mailto:dmartin@kreative.net]<BR><B>Sent:</B> Wednesday, January 03, 2001 7:37 
  PM<BR><B>To:</B> Kulwinder Atwal; 'Michael A. Ramalho'; Kenward, Gary 
  [WDLN2:AN10:EXCH]; seamoby<BR><B>Subject:</B> Re: [seamoby] 
  cart-before-seamoby<BR><BR></DIV></FONT>
  <DIV><FONT face=Arial size=2>&lt;Technical diatribe on RSSI&gt;</FONT></DIV>
  <DIV><FONT face=Arial size=2>I think we need to be careful when talking about 
  RSSI.&nbsp; My interpretation of RSSI is the&nbsp;received RF power as 
  measured by the mobile&nbsp;of&nbsp;one or more of the base station carriers 
  it is monitoring.&nbsp; The mobile does not know that the RF power is 
  generated by a particular base station, only that RF power exists in a band 
  that those base stations operate in.&nbsp; In the In some technologies (e.g., 
  CDMA), the RF power received in a mobile's carrier frequency does not 
  necessarily correlate to the performance (e.g., bit error rate).&nbsp; RSSI is 
  only a good indication of RF in situations where there is low or no 
  interference.&nbsp; In high interference situations (dense urban 
  environments&nbsp;or having several ISM band CDMA products co-located) *raw* 
  RSSI may not be a good indication of the best serving base station.&nbsp; A 
  better metric than RSSI would be some Signal to Noise (actually Signal to 
  Noise+Interference) metric, however this requires that the signal be 
  demodulated first and then compared to the ambient noise+interference.&nbsp; A 
  fairly costly (from the power perspective) thing to be doing 
  constantly.</FONT></DIV>
  <DIV><FONT face=Arial size=2>&lt;/Technical diatribe on RSSI&gt;</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>Now a question ... I&nbsp;am having trouble 
  understanding why layer 3 need to be invoved in physical layer metrics?&nbsp; 
  I&nbsp;<SPAN class=750532800-04012001><FONT face="Comic Sans MS" 
  size=3>&nbsp;</FONT></SPAN></FONT></DIV>
  <DIV><FONT face=Arial size=2><SPAN 
  class=750532800-04012001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=750532800-04012001>Layer 3 is not 
  supposed to be involved with a particular physical layer metric. That's 
  how<BR>this discussion began. I would prefer us to agree upon a "handoff 
  trigger" event delivered to layer 3 from layer 2, as an abstraction of the 
  possible layer 1-2 phenomena that actually might trigger a real 
  handoff.</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=750532800-04012001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2><SPAN class=750532800-04012001>&nbsp;</SPAN>would 
  not expect a wireline router to route on some bit error rate metric, but would 
  rather have the layer 2 protocols deal in their own way with bit errors, 
  resulting in a throughput and latency metric, which I do think is valid for L3 
  decisions.&nbsp;For the wireless environment, I am not convinced that 
  enhancing L3 to overcome shortcomings of poor (from the wirless mobility 
  perspective) L2 protocols is the right approach.<FONT face="Comic Sans MS" 
  size=3><SPAN class=750532800-04012001>&nbsp;</SPAN></FONT></FONT><FONT 
  face=Arial size=2><FONT face="Comic Sans MS" size=3><SPAN 
  class=750532800-04012001>&nbsp;</SPAN></FONT></FONT></DIV>
  <DIV><FONT face=Arial size=2><FONT face="Comic Sans MS" size=3><SPAN 
  class=750532800-04012001>Actually, good point. I recall vaguely from a 
  previous life, reading about failover in routers. Some interfaces keep track 
  of physical layer quality (sometimes BER, sometimes simply dc signals), and 
  report a link failure event, but not the quality measurement used to indicate 
  link failure. I think there is an analogy here.</SPAN></FONT></FONT></DIV>
  <DIV><FONT face=Arial size=2><FONT face="Comic Sans MS" size=3><SPAN 
  class=750532800-04012001></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2><FONT face="Comic Sans MS" size=3><SPAN 
  class=750532800-04012001>Gary</SPAN></FONT></FONT></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C075E7.BD2A3910--


From owner-seamoby@diameter.org  Wed Jan  3 21:36:09 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13509
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 21:36:09 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f041PG104315
	for seamoby-list; Wed, 3 Jan 2001 17:25:16 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f041PCW04305
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 17:25:12 -0800
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA14419;
	Wed, 3 Jan 2001 16:32:40 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA24728;
	Wed, 3 Jan 2001 16:32:37 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA28881;
	Wed, 3 Jan 2001 16:32:29 -0800 (PST)
Date: Wed, 3 Jan 2001 16:28:59 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: RE: [seamoby] cart-before-seamoby
To: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
Cc: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        Gary Kenward <gkenward@nortelnetworks.com>,
        "'Kulwinder Atwal'" <kulwinder.atwal@herc.zucotto.com>,
        "'Michael A. Ramalho'" <mramalho@cisco.com>, seamoby@diameter.org
In-Reply-To: "Your message with ID" <FC0292EA4D13D34EA2E5FC728D70A8E3078B74@NEPTUNE.zucotto.com>
Message-ID: <Roam.SIMC.2.0.6.978568139.8656.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

> I think it should be removed.  We all know 3G means 3G cellular.
> 3G cellular is not the only access technology.
> Maybe the reviewers had not considered Bluetooth?

<hat>
I checked with one of our esteemed ADs, and the charter cannot be changed at
this time. Having said that, no one is considering alienating any other
wireless technology. So, given that we are all friends here (well, most of the
time :), we can just assume that the charter does allow for ANY wireless
technology. </hat>


PatC



From owner-seamoby@diameter.org  Wed Jan  3 21:44:30 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13572
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 21:44:30 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f041rfb04387
	for seamoby-list; Wed, 3 Jan 2001 17:53:41 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f041rcW04382
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 17:53:38 -0800
Received: (cpmta 8054 invoked from network); 3 Jan 2001 17:01:09 -0800
Received: from dsl-64-193-0-129.telocity.com (HELO telocity.com) (64.193.0.129)
  by smtp.telocity.com (209.228.33.217) with SMTP; 3 Jan 2001 17:01:09 -0800
X-Sent: 4 Jan 2001 01:01:09 GMT
Message-ID: <3A53CBBF.E130800A@telocity.com>
Date: Wed, 03 Jan 2001 19:02:55 -0600
From: Phil Neumiller <neumiller@telocity.com>
Organization: 3Com
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: seamoby@diameter.org
Subject: Re: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
References: <FC0292EA4D13D34EA2E5FC728D70A8E3078B71@NEPTUNE.zucotto.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello Kulwinder,  comments follow.

> Kulwinder Atwal wrote:
> 
> 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.

Your argument about 10 ms only holds if you assume break before make.
Now I know of a little bit of IPR (from a previous employer) that I
worked on that lets a FHSS radio (such as Bluetooth) scan multiple
hop sequences simultaneously.  This particular modification to FHSS
allows make before break (i.e. softhandover on FHSS radios), since
the L2 can be in communication with two or more base stations
simultaneously.  Whether this IPR can be used in the Bluetooth SIG is
another issue and up to Motorola, Inc.

I don't understand something.  In previous posts you suggested that the
IP biding to the Bluetooth air interface would be amenable to change.
Now you are saying no?  My suggestion would be to look at the binding
between 802.11 and IP, and pattern Bluetooth after that.  I understand
that the RFCOMM/L2CAP was intended to be a cheap serial port
replacement.
However, its not going to cut it for a general purpose IP binding.  
Let's say that the Bluetooth SIG decides to do this, and possibly modify
the radio slightly, then do your issues go away?

Thanks,

Phil


From owner-seamoby@diameter.org  Wed Jan  3 21:46:11 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13587
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 21:46:10 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f041x9X04396
	for seamoby-list; Wed, 3 Jan 2001 17:59:09 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (witbier.cisco.com [171.71.152.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f041x6W04391
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 17:59:06 -0800
Received: from Ramalho-Family (rtp-vpn-12.cisco.com [10.82.192.12])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id RAA26619;
	Wed, 3 Jan 2001 17:06:32 -0800 (PST)
Message-Id: <4.1.20010103200344.00a32200@witbier.cisco.com>
X-Sender: mramalho@witbier.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 03 Jan 2001 20:08:41 -0500
To: "Gary Kenward" <gkenward@nortelnetworks.com>,
        "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>,
        seamoby@diameter.org
From: "Michael A. Ramalho" <mramalho@cisco.com>
Subject: RE: [seamoby] cart-before-seamoby
In-Reply-To: <13E2EF604DE5D111B2E50000F80824E8057A8A67@zwdld001.ca.norte
 l.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_42342695==_.ALT"
Sender: owner-seamoby@diameter.org
Precedence: bulk

--=====================_42342695==_.ALT
Content-Type: text/plain; charset="us-ascii"

At 05:49 PM 1/3/01 -0500, Gary Kenward wrote: 
>
> Someone at the CRAPS BOF was adamant - and I agree - that
> seamless mobility should support handover between access 
> networks (full stop).
>  
> By definition, some of these access networks may be wired. Some
> of these access networks may involve wireless links where the
> sensing and calculation of RSSI is either meaningless, or uneconomical.
> The origin of the "handoff trigger" as someone called it, is the 
> purview of the access network designer, not SeaMoby.


Our draft agrees ... for the case of a "network generated handoff trigger".
Our draft also admits the possibility of a "mobile node generated handoff
trigger". The "handoff decision" could be made by the access network
or the mobile node or either ... depending on the particular technology
involved.

>
>  
> Gary
>>
>> -----Original Message-----
>> From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
>> Sent: Wednesday, January 03, 2001 12:46 PM
>> To: 'Michael A. Ramalho'; Kenward, Gary [WDLN2:AN10:EXCH];
>> seamoby@diameter.org
>> Subject: RE: [seamoby] cart-before-seamoby
>>
>>
>> These seem to be related to a particular network technology, right?
>>
>> That is ... given a network (radio/spectrum) design ... then "network
>> handoff triggers" are determined by the network designers ... and these
>> triggers can use such information to help determine when the
>> "triggering events" should be requested, right?
>>  
>> Is this not for wireless networks?
>>  
>> If so, then EVERY wireless network has a RF signal.  Not just Bluetooth.
>> And every radio I have ever put my hands in has had a RSSI.
>> This includes Shortwave, VHF, UHF, Microwave, Bluetooth and yes even cell
>> phones.
>> This is how a radio measures the signal strength.  Some radios called it the
>> Recieve Signal 
>> Strength Indicator, while others call it the Radio Signal Strength
>> Indicator.
>> This is fundemental.   Fundemental wireless terminology.
>> Look on your cell phone display, you will see it.
>>  
>> If you want to come up with a wireless protocol you must be willing and able
>> to learn and use some basic wireless terminology.
>>  
>> If you are working on a wired protocol then you should say so.
>>  
>>  
>>  
>> - Kulwinder
>>  
>>  
>




Michael A. Ramalho, Ph.D.
Office email: mramalho@cisco.com
Personal email: mar42@cornell.edu
Office: +1.732.449.5762
Cell: +1.732.809.0188
Pager: +1.800.365.4578 
--=====================_42342695==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 05:49 PM 1/3/01 -0500, Gary Kenward wrote: <br>
<font face="Comic Sans MS"><blockquote type=cite cite>Someone at the
CRAPS BOF was adamant - and I agree - that</font><br>
seamless mobility should support handover between access <br>
networks (full stop).<br>
&nbsp;<br>
<font face="Comic Sans MS">By definition, some of these access networks
may be wired. Some</font><br>
of these access networks may involve wireless links where the<br>
sensing and calculation of RSSI is either meaningless, or
uneconomical.<br>
The origin of the &quot;handoff trigger&quot; as someone called it, is
the <br>
purview of the access network designer, not SeaMoby.</blockquote><br>
Our draft agrees ... for the case of a &quot;network generated handoff
trigger&quot;.<br>
Our draft also admits the possibility of a &quot;mobile node generated
handoff<br>
trigger&quot;. The &quot;handoff decision&quot; could be made by the
access network<br>
or the mobile node or either ... depending on the particular
technology<br>
involved.<br>
<br>
<blockquote type=cite cite>&nbsp;<br>
<font face="Comic Sans MS">Gary</font><br>
<font face="tahoma" size=2><blockquote type=cite cite>-----Original
Message-----<br>
<b>From:</b> Kulwinder Atwal
[<a href="mailto:kulwinder.atwal@zucotto.com" eudora="autourl">mailto:kulwinder.atwal@zucotto.com</a>]<br>
<b>Sent:</b> Wednesday, January 03, 2001 12:46 PM<br>
<b>To:</b> 'Michael A. Ramalho'; Kenward, Gary [WDLN2:AN10:EXCH];
seamoby@diameter.org<br>
<b>Subject:</b> RE: [seamoby] cart-before-seamoby<br>
<br>
</font><br>
These seem to be related to a particular network technology, right?<br>
<br>
That is ... given a network (radio/spectrum) design ... then
&quot;network<br>
handoff triggers&quot; are determined by the network designers ... and
these<br>
triggers can use such information to help determine when the<br>
&quot;triggering events&quot; should be requested, right?<br>
<font face="arial" size=2 color="#0000FF">&nbsp;</font><br>
Is this not for wireless networks?<br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">If so, then EVERY wireless
network has a RF signal.&nbsp; Not just Bluetooth.</font><br>
And every radio I have ever put my hands in has had a RSSI.<br>
This includes Shortwave, VHF, UHF, Microwave, Bluetooth and yes even cell
phones.<br>
This is how a radio measures the signal strength.&nbsp; Some radios
called it the Recieve Signal <br>
Strength Indicator, while others call it the Radio Signal Strength
Indicator.<br>
This is fundemental.&nbsp;&nbsp; Fundemental wireless terminology.<br>
Look on your cell phone display, you will see it.<br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">If you want to come up with a
wireless protocol you must be willing and able to learn and use some
basic wireless terminology.</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">If you are working on a wired
protocol then you should say so.</font><br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">- Kulwinder</font><br>
&nbsp;<br>
&nbsp;</blockquote></blockquote><br>
<br>
<br>
<div>Michael A. Ramalho, Ph.D.</div>
<div>Office email: mramalho@cisco.com</div>
<div>Personal email: mar42@cornell.edu</div>
<div>Office: +1.732.449.5762</div>
<div>Cell: +1.732.809.0188</div>
Pager: +1.800.365.4578
</html>

--=====================_42342695==_.ALT--



From owner-seamoby@diameter.org  Wed Jan  3 21:47:10 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13601
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 21:47:09 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f041pxF04369
	for seamoby-list; Wed, 3 Jan 2001 17:51:59 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f041puW04364
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 17:51:56 -0800
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23543
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 16:59:32 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA12070
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 16:59:31 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA00245
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 16:59:29 -0800 (PST)
Date: Wed, 3 Jan 2001 16:55:58 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: [seamoby] The RFC 822 subject field
To: seamoby@diameter.org
Message-ID: <Roam.SIMC.2.0.6.978569758.27155.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

Could I please ask that people insert an appropriate subject name into the
subject field when sending e-mails to the list. I, for one, find it most
difficult to follow threads when discussions digress, but the subject field
remains static.

If you are in the process of replying, but see that you are diverging from the
original topic of the thread, you could change the subject from:
	cart-before-seamoby
to:
	physical layer stuff (was: cart-before-seamoby)

Thanks,

PatC



From owner-seamoby@diameter.org  Wed Jan  3 21:49:42 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13632
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 21:49:40 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f041FmC04273
	for seamoby-list; Wed, 3 Jan 2001 17:15:48 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f041FjW04268
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 17:15:45 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 3 Jan 2001 19:13:59 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBPBQT>; Wed, 3 Jan 2001 19:14:06 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8A6E@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>,
        "'Kulwinder Atwal'" <kulwinder.atwal@herc.zucotto.com>,
        "'James Kempf'" <James.Kempf@eng.sun.com>, mruckstuhl@MeshNetworks.com,
        kulwinder.atwal@herc.zucotto.com, seamoby@diameter.org
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
Date: Wed, 3 Jan 2001 19:13:56 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C075E3.3A9D30A0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C075E3.3A9D30A0
Content-Type: text/plain;
	charset="iso-8859-1"

-----Original Message-----
From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
Sent: Wednesday, January 03, 2001 6:44 PM
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Kulwinder Atwal'; 'James Kempf';
mruckstuhl@meshnetworks.com; kulwinder.atwal@herc.zucotto.com;
seamoby@diameter.org
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001


 

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Wednesday, January 03, 2001 6:29 PM
To: 'Kulwinder Atwal'; 'James Kempf'; mruckstuhl@meshnetworks.com;
kulwinder.atwal@herc.zucotto.com; seamoby@diameter.org
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". 

Well, SeaMob isn't here today. . . but seriously, I was making the 
case for generality, not for some "future" network.

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.  

Hmmm. This is exactly what I was saying, but my personal view is that this
shouldn't take the form of, for example, "extensions to SeaMoby to support
Bluetooth", or whatever the link technology is. As Phil pointed out, the
wireless
world is very dynamic, and if link specific extensions are required to make 
SeaMoby work, this group will never finish its work.

Regardless, I am confused by the debate: you state that real time handover
must be
performed in the Bluetooth link layer. Fine, SeaMoby must work transparently
with any access network that provides its own handover capability (e.g.
CDMA2000,
UMTS, GSM, . . . ).

  It sounds like you already have a 'future" network in mind.   

Oh, I do indeed, it's a network that supports wireless access to the
Internet, in-
building, outdoors, walking, running, riding a train - with one device. It's
a wireless
inter-network that supports *my* favourite Internet application
transparently, with seamless mobility across a variety of wireless
technologies tailored to work well in a specific environment, without
requiring me to switch PC cards, reload protocol stacks, or reconfigure or
restart my application. It's a network where I really cannot tell that my
application is running over a wireless or wired access.

SeaMoby will hopefully be one step in this direction. 

 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. 

I have no idea where this came from. You are reading ideas into my emails
that are either not there, or contradict what I wrote.  

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

Yes. But, IMHO, not by producing specific solutions for each link layer
technology.
I believe the charter states that SeaMoby is concerned with handover between
access
points, at the IP layer (the later may not be explicit, but this is an IETF
wg after all). 

    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:kulwinder.atwal@zucotto.com
<mailto:kulwinder.atwal@zucotto.com> ] 
Sent: Wednesday, January 03, 2001 6:01 PM 
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf';
mruckstuhl@meshnetworks.com; kulwinder.atwal@herc.zucotto.com;
seamoby@diameter.org

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:gkenward@nortelnetworks.com
<mailto:gkenward@nortelnetworks.com> ] 
Sent: Wednesday, January 03, 2001 5:40 PM 
To: 'Kulwinder Atwal'; 'James Kempf'; mruckstuhl@meshnetworks.com;
kulwinder.atwal@herc.zucotto.com; seamoby@diameter.org

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


------_=_NextPart_001_01C075E3.3A9D30A0
Content-Type: text/html;
	charset="iso-8859-1"

<!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.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<BLOCKQUOTE dir=ltr 
style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Kulwinder Atwal 
  [mailto:kulwinder.atwal@zucotto.com]<BR><B>Sent:</B> Wednesday, January 03, 
  2001 6:44 PM<BR><B>To:</B> Kenward, Gary [WDLN2:AN10:EXCH]; 'Kulwinder Atwal'; 
  'James Kempf'; mruckstuhl@meshnetworks.com; kulwinder.atwal@herc.zucotto.com; 
  seamoby@diameter.org<BR><B>Subject:</B> RE: [seamoby] MicroMobility Algorithm 
  Outline Revision 0.0001<BR><BR></DIV></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2></FONT>&nbsp;</DIV>
  <BLOCKQUOTE dir=ltr 
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
    [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, January 03, 
    2001 6:29 PM<BR><B>To:</B> 'Kulwinder Atwal'; 'James Kempf'; 
    mruckstuhl@meshnetworks.com; kulwinder.atwal@herc.zucotto.com; 
    seamoby@diameter.org<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 color=#0000ff 
    face=Arial>I don't think we should be designing some idealized protocol to 
    be used "in the future".<FONT color=#000080 face="Comic Sans MS" 
    size=3><SPAN 
    class=120224423-03012001>&nbsp;</SPAN></FONT></FONT></SPAN></FONT></P>
    <P><FONT size=2><SPAN class=623133623-03012001><FONT color=#0000ff 
    face=Arial><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
    class=120224423-03012001>Well, SeaMob&nbsp;isn't here today. . . but 
    seriously,&nbsp;</SPAN></FONT></FONT></SPAN></FONT><FONT size=2><SPAN 
    class=623133623-03012001><FONT color=#0000ff face=Arial><FONT color=#000080 
    face="Comic Sans MS" size=3><SPAN class=120224423-03012001>I was making the 
    <BR>case for&nbsp;generality, not for some "future" 
    network.</SPAN></FONT></FONT></SPAN></FONT></P>
    <P><FONT size=2><SPAN class=623133623-03012001><FONT color=#0000ff 
    face=Arial>We have real problems here today.&nbsp; I don't see why it can't 
    have optional features that</FONT></SPAN></FONT><FONT face=Arial 
    size=2><SPAN class=623133623-03012001><SPAN 
    class=120224423-03012001><BR></SPAN><FONT color=#0000ff>are left up each 
    network type to choose to implement.&nbsp;<SPAN 
    class=120224423-03012001><FONT color=#000080 face="Comic Sans MS" 
    size=3>&nbsp;</FONT></SPAN></FONT></SPAN></FONT></P>
    <P><FONT face=Arial size=2><SPAN class=623133623-03012001><SPAN 
    class=120224423-03012001><FONT face="Comic Sans MS" size=3>Hmmm. This is 
    exactly what I was saying, but my personal view is that this<BR>shouldn't 
    take the form of, for example, "extensions to SeaMoby to 
    support<BR>Bluetooth", or whatever the link technology is. As&nbsp;Phil 
    pointed out,&nbsp;the wireless<BR>world is very&nbsp;dynamic, and&nbsp;if 
    link specific extensions are required to make <BR>SeaMoby work, this group 
    will never finish its work<FONT 
    color=#0000ff>.</FONT></FONT></SPAN></SPAN></FONT></P>
    <P><FONT face=Arial size=2><SPAN class=623133623-03012001><SPAN 
    class=120224423-03012001><FONT face="Comic Sans MS" 
    size=3>Regardless,&nbsp;I am confused by the&nbsp;debate: you&nbsp;state 
    that real time handover must be<BR>performed in the Bluetooth link layer. 
    Fine, SeaMoby must&nbsp;work 
    transparently<BR></FONT></SPAN></SPAN></FONT><FONT face=Arial size=2><SPAN 
    class=623133623-03012001><SPAN class=120224423-03012001><FONT 
    face="Comic Sans MS" size=3>with any access network that provides&nbsp;its 
    own handover capability (e.g. CDMA2000,<BR>UMTS, GSM, . . . 
    ).</FONT></SPAN></SPAN></FONT><FONT face=Arial size=2><SPAN 
    class=623133623-03012001><SPAN class=120224423-03012001><FONT 
    face="Comic Sans MS" size=3><BR><BR><FONT 
    color=#0000ff>&nbsp;</FONT></FONT></SPAN><FONT color=#0000ff> It sounds like 
    you already have a 'future" network in mind.&nbsp;&nbsp;</FONT><SPAN 
    class=120224423-03012001><FONT face="Comic Sans MS" size=3><FONT 
    color=#0000ff>&nbsp;</FONT></FONT></SPAN></SPAN></FONT></P>
    <P><FONT face="Comic Sans MS"><SPAN class=623133623-03012001><SPAN 
    class=120224423-03012001>Oh, I do indeed, it's a network that supports 
    wireless access to the Internet, in-<BR>building, outdoors, walking, 
    running, riding a train - with one device. It's a wireless<BR>inter-network 
    that supports *my* favourite Internet application transparently, with 
    seamless mobility across a variety of wireless technologies tailored to work 
    well in a specific environment, without requiring me to switch PC cards, 
    reload protocol stacks, or reconfigure or restart my application. It's a 
    network where I really cannot tell that my application is running over a 
    wireless or wired access.</SPAN></SPAN></FONT></P>
    <P><FONT face="Comic Sans MS"><SPAN class=623133623-03012001><SPAN 
    class=120224423-03012001>SeaMoby&nbsp;will hopefully be one step in this 
    direction. </SPAN></SPAN></FONT><FONT face=Arial size=2><SPAN 
    class=623133623-03012001><SPAN class=120224423-03012001><FONT 
    face="Comic Sans MS" size=3><BR><BR>&nbsp;</FONT></SPAN>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.<FONT face="Comic Sans MS" size=3><SPAN 
    class=120224423-03012001>&nbsp;</SPAN></FONT></SPAN></FONT></P>
    <P><FONT face=Arial size=2><SPAN class=623133623-03012001><FONT 
    face="Comic Sans MS" size=3><SPAN class=120224423-03012001>I have no idea 
    where this came from. You are reading&nbsp;ideas into my emails 
    that&nbsp;are either not there, or contradict what I wrote. 
    &nbsp;</SPAN></FONT></SPAN></FONT></P>
    <P><FONT color=#0000ff face=Arial size=2><SPAN class=623133623-03012001>Are 
    we not trying to get the widest number of cases?<FONT color=#000080 
    face="Comic Sans MS" size=3><SPAN 
    class=120224423-03012001>&nbsp;</SPAN></FONT></SPAN></FONT></P>
    <P><FONT color=#0000ff face=Arial size=2><SPAN 
    class=623133623-03012001><FONT color=#000080 face="Comic Sans MS" 
    size=3><SPAN class=120224423-03012001>Yes. But, IMHO,&nbsp;not by producing 
    specific solutions&nbsp;for&nbsp;each link layer 
    technology.</SPAN></FONT></SPAN></FONT><FONT color=#0000ff face=Arial 
    size=2><SPAN class=623133623-03012001><FONT color=#000080 
    face="Comic Sans MS" size=3><SPAN class=120224423-03012001><BR>I believe the 
    charter states that&nbsp;SeaMoby is concerned with handover between 
    access<BR>points, at the IP layer (the later may&nbsp;not be explicit, but 
    this is&nbsp;an IETF wg after all).&nbsp;</SPAN></FONT></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 color=#0000ff 
    face=Arial>&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:kulwinder.atwal@zucotto.com">mailto:kulwinder.atwal@zucotto.com</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'; 
    mruckstuhl@meshnetworks.com; kulwinder.atwal@herc.zucotto.com; 
    seamoby@diameter.org</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:gkenward@nortelnetworks.com">mailto:gkenward@nortelnetworks.com</A>]</FONT> 
    <BR><FONT size=2>Sent: Wednesday, January 03, 2001 5:40 PM</FONT> <BR><FONT 
    size=2>To: 'Kulwinder Atwal'; 'James Kempf'; mruckstuhl@meshnetworks.com; 
    kulwinder.atwal@herc.zucotto.com; seamoby@diameter.org</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></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C075E3.3A9D30A0--


From owner-seamoby@diameter.org  Wed Jan  3 22:08:28 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13785
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 22:08:27 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f042aho04432
	for seamoby-list; Wed, 3 Jan 2001 18:36:43 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from ns.kreative.net (root@ns.kreative.net [216.181.1.200])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f042afW04427
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 18:36:41 -0800
Received: from david (laurelp-187.dsdial.net [216.181.253.187])
	by ns.kreative.net (8.9.3/8.9.3) with SMTP id UAA16945;
	Wed, 3 Jan 2001 20:53:36 -0500
Message-ID: <006901c075f0$5f6f3ba0$0100000a@david>
From: "Dave Martin" <dmartin@kreative.net>
To: "Pat Calhoun" <Pat.Calhoun@eng.sun.com>,
        "David Frascone" <dave@frascone.com>
Cc: <seamoby@diameter.org>
References: <Roam.SIMC.2.0.6.978556498.18348.pcalhoun@nasnfs>
Subject: Re: [seamoby] Micromobility Problem Statement
Date: Wed, 3 Jan 2001 20:48:00 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

<snipping stuff about problem statement needed>

Here's a crack at one problem I would like to see solved.

Mobile IP does a decent job of tracking mobility, but it needs some
improvements to support certain types of applications.  When a mobile node
crosses from on FA cloud to another, the network will likely lose several
packets while the network is updated with the mobiles new location.
Furthermore this period of "unreachability" while in the transitioning phase
generally lasts too long for time sensitive applications (e.g., duplex
voice, etc).  A mechanism is needed that will allow mobile nodes
unrestrained mobility while minimizing (eliminating?) packet loss and
latency.

It probably needs some word-smithing.



From owner-seamoby@diameter.org  Wed Jan  3 22:08:31 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13795
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 22:08:29 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f041qeU04378
	for seamoby-list; Wed, 3 Jan 2001 17:52:40 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f041qbW04373
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 17:52:38 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <ZJFR8VMP>; Wed, 3 Jan 2001 20:00:13 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B75@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'James Kempf'"
	 <James.Kempf@eng.sun.com>,
        mruckstuhl@MeshNetworks.com, kulwinder.atwal@herc.zucotto.com,
        seamoby@diameter.org
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
Date: Wed, 3 Jan 2001 20:00:05 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C075E9.B17FC795"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C075E9.B17FC795
Content-Type: text/plain;
	charset="iso-8859-1"

 

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Wednesday, January 03, 2001 7:14 PM
To: 'Kulwinder Atwal'; 'Kulwinder Atwal'; 'James Kempf';
mruckstuhl@meshnetworks.com; kulwinder.atwal@herc.zucotto.com;
seamoby@diameter.org
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001


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

Yes. But, IMHO, not by producing specific solutions for each link layer
technology.
I believe the charter states that SeaMoby is concerned with handover between
access
points, at the IP layer (the later may not be explicit, but this is an IETF
wg after all).  

I am NOT saying adding.  I am saying omitting.  

I can send IP over Bluetooth to all seven slaves at 22.4kbps, or to one
slave at 723.2 kbps.  

I can send IP between APs over landline to co-ordinate the switching of
packet flows.  

I can use L2 for real-time switching of packet flows over the air. 

I cannot use IP for real-time switching of packet flows over the air.

My last email was a little extreme, but I do not what Bluetooth to be
designed out of our 

solution.

 

- Kulwinder.

 


------_=_NextPart_001_01C075E9.B17FC795
Content-Type: text/html;
	charset="iso-8859-1"

<!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:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, January 03, 
  2001 7:14 PM<BR><B>To:</B> 'Kulwinder Atwal'; 'Kulwinder Atwal'; 'James 
  Kempf'; mruckstuhl@meshnetworks.com; kulwinder.atwal@herc.zucotto.com; 
  seamoby@diameter.org<BR><B>Subject:</B> RE: [seamoby] MicroMobility Algorithm 
  Outline Revision 0.0001<BR></FONT></DIV>
  <BLOCKQUOTE dir=ltr 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000080 2px solid; MARGIN-RIGHT: 0px">
    <BLOCKQUOTE dir=ltr 
    style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
      <P><FONT face=Arial color=#0000ff size=2><SPAN 
      class=623133623-03012001>Are we not trying to get the widest number of 
      cases?<FONT face="Comic Sans MS" color=#000080 size=3><SPAN 
      class=120224423-03012001>&nbsp;</SPAN></FONT></SPAN></FONT></P>
      <P><FONT face=Arial color=#0000ff size=2><SPAN 
      class=623133623-03012001><FONT face="Comic Sans MS" color=#000080 
      size=3><SPAN class=120224423-03012001>Yes. But, IMHO,&nbsp;not by 
      producing specific solutions&nbsp;for&nbsp;each link layer 
      technology.</SPAN></FONT></SPAN></FONT><FONT face=Arial color=#0000ff 
      size=2><SPAN class=623133623-03012001><FONT face="Comic Sans MS" 
      color=#000080 size=3><SPAN class=120224423-03012001><BR>I believe the 
      charter states that&nbsp;SeaMoby is concerned with handover between 
      access<BR>points, at the IP layer (the later may&nbsp;not be explicit, but 
      this is&nbsp;an IETF wg after all).&nbsp;<SPAN 
      class=887044500-04012001><FONT face=Arial color=#0000ff 
      size=2>&nbsp;</FONT></SPAN></SPAN></FONT></SPAN></FONT></P>
      <P><FONT face=Arial color=#0000ff size=2><SPAN 
      class=623133623-03012001><FONT face="Comic Sans MS" color=#000080 
      size=3><SPAN class=120224423-03012001><SPAN class=887044500-04012001><FONT 
      face=Arial color=#0000ff size=2>I am NOT saying adding.&nbsp; I am saying 
      omitting.&nbsp; </FONT></SPAN></SPAN></FONT></SPAN></FONT></P>
      <P><FONT face=Arial color=#0000ff size=2><SPAN 
      class=623133623-03012001><FONT face="Comic Sans MS" color=#000080 
      size=3><SPAN class=120224423-03012001><SPAN class=887044500-04012001><FONT 
      face=Arial color=#0000ff size=2>I can send IP&nbsp;over Bluetooth to all 
      seven slaves at 22.4kbps, or to one slave at 723.2 kbps.&nbsp; 
      </FONT></SPAN></SPAN></FONT></SPAN></FONT></P>
      <P><FONT face=Arial color=#0000ff size=2><SPAN 
      class=623133623-03012001><FONT face="Comic Sans MS" color=#000080 
      size=3><SPAN class=120224423-03012001><SPAN class=887044500-04012001><FONT 
      face=Arial color=#0000ff size=2>I can send IP between APs over landline to 
      co-ordinate the switching of&nbsp;packet flows.&nbsp; 
      </FONT></SPAN></SPAN></FONT></SPAN></FONT></P>
      <P><FONT face=Arial color=#0000ff size=2><SPAN 
      class=623133623-03012001><FONT face="Comic Sans MS" color=#000080 
      size=3><SPAN class=120224423-03012001><SPAN class=887044500-04012001><FONT 
      face=Arial color=#0000ff size=2>I can use L2 for real-time switching of 
      packet flows over the air.</FONT></SPAN></SPAN></FONT></SPAN></FONT><FONT 
      face=Arial color=#0000ff size=2><SPAN class=623133623-03012001><FONT 
      face="Comic Sans MS" color=#000080 size=3><SPAN 
      class=120224423-03012001><SPAN 
      class=887044500-04012001>&nbsp;</SPAN></SPAN></FONT></SPAN></FONT></P>
      <P><FONT face=Arial color=#0000ff size=2><SPAN 
      class=623133623-03012001><FONT face="Comic Sans MS" color=#000080 
      size=3><SPAN class=120224423-03012001><SPAN class=887044500-04012001><FONT 
      face=Arial color=#0000ff size=2>I cannot use&nbsp;IP for real-time 
      switching of packet flows over the 
      air.</FONT></SPAN></SPAN></FONT></SPAN></FONT></P>
      <P><SPAN class=623133623-03012001><FONT face=Arial color=#0000ff 
      size=2><SPAN class=120224423-03012001><SPAN class=887044500-04012001>My 
      last email was a little extreme, but I do not what Bluetooth to be 
      designed out of our </SPAN></SPAN></FONT></SPAN></P>
      <P><SPAN class=623133623-03012001><FONT face=Arial color=#0000ff 
      size=2><SPAN class=120224423-03012001><SPAN 
      class=887044500-04012001>solution.</SPAN></SPAN></FONT></SPAN></P>
      <P><SPAN class=623133623-03012001><FONT face=Arial color=#0000ff 
      size=2><SPAN class=120224423-03012001><SPAN 
      class=887044500-04012001></SPAN></SPAN></FONT></SPAN>&nbsp;</P>
      <P><SPAN class=623133623-03012001><FONT face=Arial color=#0000ff 
      size=2><SPAN class=120224423-03012001><SPAN class=887044500-04012001>- 
      Kulwinder.</SPAN></SPAN></FONT></SPAN></P>
      <P><FONT face=Arial color=#0000ff size=2><SPAN 
      class=623133623-03012001><FONT face="Comic Sans MS" color=#000080 
      size=3><SPAN class=120224423-03012001><SPAN class=887044500-04012001><FONT 
      face=Arial color=#0000ff size=2><SPAN class=623133623-03012001><FONT 
      face="Comic Sans MS" color=#000080 size=3><SPAN 
      class=120224423-03012001><SPAN 
      class=887044500-04012001>&nbsp;</SPAN></SPAN></FONT></SPAN></FONT></SPAN></SPAN></FONT></SPAN></FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C075E9.B17FC795--


From owner-seamoby@diameter.org  Wed Jan  3 22:09:28 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13808
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 22:09:27 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f042HB504416
	for seamoby-list; Wed, 3 Jan 2001 18:17:11 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (witbier.cisco.com [171.71.152.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f042H8W04411
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 18:17:08 -0800
Received: from Ramalho-Family (rtp-vpn-12.cisco.com [10.82.192.12])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id RAA01757;
	Wed, 3 Jan 2001 17:21:09 -0800 (PST)
Message-Id: <4.1.20010103201013.00a34f10@witbier.cisco.com>
X-Sender: mramalho@witbier.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 03 Jan 2001 20:23:18 -0500
To: "Gary Kenward" <gkenward@nortelnetworks.com>,
        Kulwinder Atwal <kulwinder.atwal@zucotto.com>, seamoby@diameter.org
From: "Michael A. Ramalho" <mramalho@cisco.com>
Subject: RE: [seamoby] cart-before-seamoby
In-Reply-To: <13E2EF604DE5D111B2E50000F80824E8057A8A69@zwdld001.ca.norte
 l.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_43219396==_.ALT"
Sender: owner-seamoby@diameter.org
Precedence: bulk

--=====================_43219396==_.ALT
Content-Type: text/plain; charset="us-ascii"

Gary,

Not sure of where we are going here .. but it is fun.

At 06:04 PM 1/3/01 -0500, Gary Kenward wrote: 

>
> Michael: 
>
> Assuming at least wide sense stationary signal and noise 
> characteristics, which is reasonable for CBR over the air, 
> but yet to be rationalized for VBR, in particular, bursty 
> traffic over the air. 


Something is either w.s.s. (over a time period that the
Heisenberg principle would apply for an acceptable
certainty/confidence) or it is not.

>
> And, in anticipation, it is not my personal belief that adding 
> information to bursty traffic to make it appear wide sense 
> stationary so that you can manage the radio resources in a 
> circuit switched manner is an efficient solution. 


Clearly one does not add "stuff" that has no information
content to a signal just to make it w.s.s. This would
obviously be a waste of capacity (in an information theoretic
sense). Shannon's capacity theorem still applies; no
one that I know has disproved it since he proved it in
January 1949 (yes .. I have the Proc. IRE reference).

Ciao,

Michael


>
> Cheers, 
> Gary Kenward, O.C.G. 
>
> > I can transform any power metric you desire to use via 
> > first principals and Parseval's Theorem between any 
> > relevant engineering transform domains, if you would like. 
>
> > Michael A. Ramalho, Ph.D. 
> > Office email: mramalho@cisco.com 
> > Personal email: mar42@cornell.edu 
> > Office: +1.732.449.5762 
> > Cell: +1.732.809.0188 
> > Pager: +1.800.365.4578 




Michael A. Ramalho, Ph.D.
Office email: mramalho@cisco.com
Personal email: mar42@cornell.edu
Office: +1.732.449.5762
Cell: +1.732.809.0188
Pager: +1.800.365.4578 
--=====================_43219396==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Gary,<br>
<br>
Not sure of where we are going here .. but it is fun.<br>
<br>
At 06:04 PM 1/3/01 -0500, Gary Kenward wrote: <br>
<br>
<font size=2><blockquote type=cite cite>Michael:</font> <br>
<br>
<font size=2>Assuming at least wide sense stationary signal and
noise</font> <br>
<font size=2>characteristics, which is reasonable for CBR over the
air,</font> <br>
<font size=2>but yet to be rationalized for VBR, in particular,
bursty</font> <br>
<font size=2>traffic over the air. <br>
</font></blockquote><br>
Something is either w.s.s. (over a time period that the<br>
Heisenberg principle would apply for an acceptable<br>
certainty/confidence) or it is not.<br>
<br>
<font size=2><blockquote type=cite cite>And, in anticipation, it is not
my personal belief that adding</font> <br>
<font size=2>information to bursty traffic to make it appear wide
sense</font> <br>
<font size=2>stationary so that you can manage the radio resources in
a</font> <br>
<font size=2>circuit switched manner is an efficient solution. <br>
</font></blockquote><br>
Clearly one does not add &quot;stuff&quot; that has no information<br>
content to a signal just to make it w.s.s. This would<br>
obviously be a waste of capacity (in an information theoretic<br>
sense). Shannon's capacity theorem still applies; no<br>
one that I know has disproved it since he proved it in<br>
January 1949 (yes .. I have the Proc. IRE reference).<br>
<br>
Ciao,<br>
<br>
Michael<br>
<br>
<br>
<font size=2><blockquote type=cite cite>Cheers,</font> <br>
<font size=2>Gary Kenward, O.C.G.</font> <br>
<br>
<font size=2>&gt; I can transform any power metric you desire to use
via</font> <br>
<font size=2>&gt; first principals and Parseval's Theorem between
any</font> <br>
<font size=2>&gt; relevant engineering transform domains, if you would
like.</font> <br>
<br>
<font size=2>&gt; Michael A. Ramalho, Ph.D.</font> <br>
<font size=2>&gt; Office email: mramalho@cisco.com</font> <br>
<font size=2>&gt; Personal email: mar42@cornell.edu</font> <br>
<font size=2>&gt; Office: +1.732.449.5762</font> <br>
<font size=2>&gt; Cell: +1.732.809.0188</font> <br>
<font size=2>&gt; Pager: +1.800.365.4578 </font></blockquote><br>
<br>
<br>
<div>Michael A. Ramalho, Ph.D.</div>
<div>Office email: mramalho@cisco.com</div>
<div>Personal email: mar42@cornell.edu</div>
<div>Office: +1.732.449.5762</div>
<div>Cell: +1.732.809.0188</div>
Pager: +1.800.365.4578
</html>

--=====================_43219396==_.ALT--



From owner-seamoby@diameter.org  Wed Jan  3 22:33:14 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14970
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 22:33:13 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0435dA04456
	for seamoby-list; Wed, 3 Jan 2001 19:05:39 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0435bW04451
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 19:05:37 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <ZJFR8VNZ>; Wed, 3 Jan 2001 21:13:13 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B78@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Michael A. Ramalho'" <mramalho@cisco.com>,
        "'Gary Kenward'"
	 <gkenward@nortelnetworks.com>, seamoby@diameter.org
Subject: RE: [seamoby] cart-before-seamoby
Date: Wed, 3 Jan 2001 21:13:12 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C075F3.E45107DA"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C075F3.E45107DA
Content-Type: text/plain;
	charset="iso-8859-1"

I have had a chance to go back and re-read.  Now that the email barrage has
lightened.

-----Original Message-----
From: Michael A. Ramalho [mailto:mramalho@cisco.com]
Sent: Wednesday, January 03, 2001 11:01 AM
To: Kulwinder Atwal; 'Gary Kenward'; 'Kulwinder Atwal'; seamoby@diameter.org
Subject: RE: [seamoby] cart-before-seamoby



Fine ... engineering a particular network technology to measure these things
are
precisely what equipment manufacturers design. Is there any reason why
access points
that service a particular network technology uses cannot communicate this
information
to the point(s) in the network responsible for the (network, in your case)
decision.

I agree. 
 
That is, what of the above discussion is required to be specified by
seamoby?

We have a lot of signaling transport and control protocols at our disposal
for
this .... I see no reason why seamoby needs to (re)specify them.

In other words ... seamoby should not specify *network design* ... the
market
will decide which manufacturers/designs work the best .... or other
standards
bodies will offer design recommendations ... I think seamoby should steer
clear
of such political rat-holes!

I agree.  My only comment is instead of saying "particular network
technology" twenty times, that it may have been more communicative to say
wireless or wired.  The problem with the charter is that it devotes a
paragraph mentioning the interests of 3G cellular, giving their interests
additional weight.  Whereas, LANs get a single mention.


Again, I'd like to thank Kulwinder for the opportunity to comment ... but
these
comments highlight the need for a seamoby "problem statement" that we
can all rally behind.
 
Absolutely.  I put that out there to generate discussion.  Apparently, too
much discussion.  I have recieved about one additional personally addressed
email for every email posted to this list.
 
My hope is that such a problem statement will not suggest to the world that
we are effectively re-designing (ONLY) cellular network behavior over IP. I
would
like equipment manufacturers to do that specific job .. preferably using
(unified) design principles that are in seamoby's charter or framework
document.

Yes, and I would like commend Michael for stating some fine points.   
 
 - Kulwinder 
 
Stepping off my soapbox.




Michael A. Ramalho, Ph.D.
Office email: mramalho@cisco.com
Personal email: mar42@cornell.edu
Office: +1.732.449.5762
Cell: +1.732.809.0188
Pager: +1.800.365.4578 


------_=_NextPart_001_01C075F3.E45107DA
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=783184401-04012001>I have 
had a chance to go back and re-read.&nbsp; Now that the email barrage has 
lightened.</SPAN></FONT></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> Michael A. Ramalho 
  [mailto:mramalho@cisco.com]<BR><B>Sent:</B> Wednesday, January 03, 2001 11:01 
  AM<BR><B>To:</B> Kulwinder Atwal; 'Gary Kenward'; 'Kulwinder Atwal'; 
  seamoby@diameter.org<BR><B>Subject:</B> RE: [seamoby] 
  cart-before-seamoby<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2></FONT><FONT face=Arial 
  color=#0000ff size=2></FONT><FONT face=Arial color=#0000ff size=2></FONT><FONT 
  face=Arial color=#0000ff size=2></FONT><FONT face=Arial color=#0000ff 
  size=2></FONT><FONT face=Arial color=#0000ff size=2></FONT><BR>Fine ... 
  engineering a particular network technology to measure these things 
  are<BR>precisely what equipment manufacturers design. Is there any reason why 
  access points<BR>that service a particular network technology uses cannot 
  communicate this information<BR>to the point(s) in the network responsible for 
  the (network, in your case) decision.<BR><SPAN class=783184401-04012001><FONT 
  face=Arial color=#0000ff size=2></FONT></SPAN></DIV>
  <DIV><SPAN class=783184401-04012001><FONT face=Arial color=#0000ff size=2>I 
  agree.</FONT>&nbsp;</SPAN></DIV>
  <DIV><SPAN class=783184401-04012001>&nbsp;</SPAN><BR>That is, what of the 
  above discussion is required to be specified by seamoby?<BR><BR>We have a lot 
  of signaling transport and control protocols at our disposal for<BR>this .... 
  I see no reason why seamoby needs to (re)specify them.<BR><BR>In other words 
  ... seamoby should not specify *network design* ... the market<BR>will decide 
  which manufacturers/designs work the best .... or other standards<BR>bodies 
  will offer design recommendations ... I think seamoby should steer clear<BR>of 
  such political rat-holes!<BR><SPAN class=783184401-04012001><FONT face=Arial 
  color=#0000ff size=2></FONT></SPAN></DIV>
  <DIV><SPAN class=783184401-04012001><FONT face=Arial color=#0000ff size=2>I 
  agree.&nbsp; My only comment is instead of saying "particular 
  network&nbsp;technology" twenty times, that it may 
  have&nbsp;been&nbsp;more&nbsp;communicative to&nbsp;say wireless or 
  wired.&nbsp; The problem with the&nbsp;charter is that it&nbsp;devotes a 
  paragraph&nbsp;mentioning the&nbsp;interests of 3G cellular, giving their 
  interests additional weight.&nbsp; Whereas, LANs get a single 
  mention.</FONT></SPAN></DIV><FONT face=Arial color=#0000ff size=2></FONT>
  <DIV><BR>Again, I'd like to thank Kulwinder for the opportunity to comment ... 
  but these<BR>comments highlight the need for a seamoby "problem statement" 
  that we<BR>can all rally behind.<BR><SPAN class=783184401-04012001><FONT 
  face=Arial color=#0000ff size=2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=783184401-04012001><FONT face=Arial color=#0000ff 
  size=2>Absolutely.&nbsp; I put that out there to generate discussion.&nbsp; 
  Apparently, too much discussion.&nbsp; I have recieved about one additional 
  personally addressed&nbsp;email for every email posted to this 
  list.</FONT></SPAN></DIV>
  <DIV><SPAN class=783184401-04012001>&nbsp;</SPAN><BR>My hope is that such a 
  problem statement will not suggest to the world that<BR>we are effectively 
  re-designing (ONLY) cellular network behavior over IP. I would<BR>like 
  equipment manufacturers to do that specific job .. preferably 
  using<BR>(unified) design principles that are in seamoby's charter or 
  framework document.<BR><SPAN class=783184401-04012001><FONT face=Arial 
  color=#0000ff size=2></FONT></SPAN></DIV>
  <DIV><SPAN class=783184401-04012001><FONT face=Arial color=#0000ff size=2>Yes, 
  and I would like commend Michael for stating some fine points.&nbsp; 
  </FONT>&nbsp;</SPAN></DIV>
  <DIV><SPAN class=783184401-04012001>&nbsp;</SPAN></DIV>
  <DIV><SPAN class=783184401-04012001></SPAN><SPAN 
  class=783184401-04012001><FONT face=Arial color=#0000ff size=2>&nbsp;- 
  Kulwinder&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=783184401-04012001>&nbsp;</SPAN><BR>Stepping off my 
  soapbox.<BR><BR><BR></DIV>
  <BLOCKQUOTE>
    <DIV>Michael A. Ramalho, Ph.D.</DIV>
    <DIV>Office email: mramalho@cisco.com</DIV>
    <DIV>Personal email: mar42@cornell.edu</DIV>
    <DIV>Office: +1.732.449.5762</DIV>
    <DIV>Cell: +1.732.809.0188</DIV>Pager: +1.800.365.4578 
</BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C075F3.E45107DA--


From owner-seamoby@diameter.org  Wed Jan  3 22:48:40 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15172
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 22:48:40 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f043EdB04468
	for seamoby-list; Wed, 3 Jan 2001 19:14:39 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f043EbW04463
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 19:14:37 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <ZJFR8VN8>; Wed, 3 Jan 2001 21:22:13 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B79@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'Phil_Neumiller@3com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
Subject: RE: [seamoby] Micromobility Problem Statement
Date: Wed, 3 Jan 2001 21:22:03 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C075F5.2634D794"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C075F5.2634D794
Content-Type: text/plain;
	charset="iso-8859-1"

> PDN>easily surpass the backhaul carrying capacity if one is 
> not careful. 
> PDN>This can be exploited by technologies like 802.11a, 
> Bluetooth, etc., 
> PDN>to deconstruct the cellular business model.  If I were a carrier, 
> PDN>I would be afraid, VERY AFRAID!!! 

Who is going to build these 802.11a networks and provide them to users 
for free? 

Employers can provide them in the work place for work place mobility.  

This will cut down on wireless charges for the case where people work in 

an office, factory, outdoor worksite, but carry and use a cell at work.

- Kulwinder.

 

  I agree that the current cellular business models for wireless 
data don't make alot of sense. I also have reason to believe that many 
of the executives of these cellular businesses would agree that a better 
business model is required. But note, there is not a proven model 
for a profitable wireline access provider, never mind wireless access. 

Anyway, sorry to press that button. Back on topic. 

Gary 


------_=_NextPart_001_01C075F5.2634D794
Content-Type: text/html;
	charset="iso-8859-1"

<!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 Problem Statement</TITLE>

<META content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT size=2>&gt; PDN&gt;easily surpass the backhaul carrying capacity if 
one is </FONT><BR><FONT size=2>&gt; not careful.</FONT> <BR><FONT size=2>&gt; 
PDN&gt;This can be exploited by technologies like 802.11a, </FONT><BR><FONT 
size=2>&gt; Bluetooth, etc.,</FONT> <BR><FONT size=2>&gt; PDN&gt;to deconstruct 
the cellular business model.&nbsp; If I were a carrier,</FONT> <BR><FONT 
size=2>&gt; PDN&gt;I would be afraid, VERY AFRAID!!!</FONT> </DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <P><FONT size=2>Who is going to build these 802.11a networks and provide them 
  to users</FONT> <BR><FONT size=2>for free?<SPAN class=989111502-04012001><FONT 
  face=Arial color=#0000ff>&nbsp;</FONT></SPAN></FONT></P>
  <P><FONT size=2><SPAN class=989111502-04012001>Employers can provide them in 
  the work place for work place mobility.&nbsp; </SPAN></FONT></P>
  <P><FONT size=2><SPAN class=989111502-04012001>This will cut down 
  on&nbsp;wireless charges </SPAN></FONT><FONT size=2><SPAN 
  class=989111502-04012001>for the case where people work in </SPAN></FONT></P>
  <P><FONT size=2><SPAN class=989111502-04012001>an office, factory, outdoor 
  worksite,&nbsp;but carry and use a cell at work.</SPAN></FONT></P>
  <P><FONT size=2><SPAN class=989111502-04012001>- Kulwinder.</SPAN></FONT></P>
  <P><FONT size=2><SPAN class=989111502-04012001></SPAN></FONT><FONT 
  size=2><SPAN class=989111502-04012001>&nbsp;</SPAN></FONT></P>
  <P><FONT size=2><SPAN class=989111502-04012001>&nbsp;</SPAN> I agree that the 
  current cellular business models for wireless</FONT> <BR><FONT size=2>data 
  don't make alot of sense. I also have reason to believe that many 
  </FONT><BR><FONT size=2>of the executives of these cellular businesses would 
  agree that a better</FONT> <BR><FONT size=2>business model is required. But 
  note, there is not a proven model</FONT> <BR><FONT size=2>for a profitable 
  wireline access provider, never mind wireless access.</FONT> </P>
  <P><FONT size=2>Anyway, sorry to press that button. Back on topic.</FONT> </P>
  <P><FONT size=2>Gary</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C075F5.2634D794--


From owner-seamoby@diameter.org  Wed Jan  3 23:45:24 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15980
	for <seamoby-archive@odin.ietf.org>; Wed, 3 Jan 2001 23:45:24 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0440dZ04496
	for seamoby-list; Wed, 3 Jan 2001 20:00:39 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0440bW04491
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 20:00:37 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <ZJFR8V3K>; Wed, 3 Jan 2001 22:08:13 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B7A@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Phil Neumiller'" <neumiller@telocity.com>, seamoby@diameter.org
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
Date: Wed, 3 Jan 2001 22:08:10 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk



> -----Original Message-----
> From: Phil Neumiller [mailto:neumiller@telocity.com]
> Sent: Wednesday, January 03, 2001 8:03 PM
> To: seamoby@diameter.org
> Subject: Re: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
> 
> 
> Hello Kulwinder,  comments follow.
> 
> > Kulwinder Atwal wrote:
> > 
> > 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.
> 
> Your argument about 10 ms only holds if you assume break before make.
> Now I know of a little bit of IPR (from a previous employer) that I
> worked on that lets a FHSS radio (such as Bluetooth) scan multiple
> hop sequences simultaneously.  This particular modification to FHSS
> allows make before break (i.e. softhandover on FHSS radios), since
> the L2 can be in communication with two or more base stations
> simultaneously.  Whether this IPR can be used in the Bluetooth SIG is
> another issue and up to Motorola, Inc.
> 
> I don't understand something.  In previous posts you 
> suggested that the
> IP biding to the Bluetooth air interface would be amenable to change.
> Now you are saying no?

I gave all the numbers in two previous emails today.  You may want to go
back and review.
 
But, basically in 10 mSec I can talk to all seven slaves at least once, with
one Master/Slave slot pair left over.  I would like to use this slot pair to
do the switch.  It is not whether I can SAR longer packets than my one slot
MTU size of 28 bytes.  But, is it not more efficient and simple to have
Seamoby sit at the access point, and for me to translate Seamoby/IP packets
to link layer packets?  But, allowing non-Seamoby end user IP packets
through to the mobile?  

So the there are three cases:

1. Seamoby sits at the access point.  It is used by the Bluetooth Host to
communicate to other Seamoby capable devices over the wired link to affect a
hand-off.  

2. Seamoby sits at the access point.  Seamoby is translated by the Bluetooth
Host into link layer signalling over the Bluetooth air link to affect a
hand-off.

3. IP sits at the access point and mobile.  It is used by both to
communicate non-Seamoby traffic (ie. end user data).  Basically, IP over
Bluetooth Host Controller.

If no one has any objections, I would like to make all three cases true.

- Kulwinder.

>  My suggestion would be to look at the binding
> between 802.11 and IP, and pattern Bluetooth after that.  I understand
> that the RFCOMM/L2CAP was intended to be a cheap serial port
> replacement.
> However, its not going to cut it for a general purpose IP binding.  
> Let's say that the Bluetooth SIG decides to do this, and 
> possibly modify
> the radio slightly, then do your issues go away?
> 
> Thanks,
> 
> Phil
> 


From owner-seamoby@diameter.org  Thu Jan  4 02:42:35 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29993
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 02:42:35 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0472K504644
	for seamoby-list; Wed, 3 Jan 2001 23:02:20 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f04713W04639
	for <seamoby@diameter.org>; Wed, 3 Jan 2001 23:01:03 -0800
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id WAA15122;
	Wed, 3 Jan 2001 22:08:35 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id WAA20463; Wed, 3 Jan 2001 22:08:34 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14932.4962.628296.426144@thomasm-u1.cisco.com>
Date: Wed, 3 Jan 2001 22:08:34 -0800 (PST)
To: "Gary Kenward" <gkenward@nortelnetworks.com>
Cc: "'Phil_Neumiller@3com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
Subject: RE: [seamoby] Micromobility Problem Statement
In-Reply-To: <13E2EF604DE5D111B2E50000F80824E8057A8A6D@zwdld001.ca.nortel.com>
References: <13E2EF604DE5D111B2E50000F80824E8057A8A6D@zwdld001.ca.nortel.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Gary Kenward writes:
 > Who is going to build these 802.11a networks and provide them to users
 > for free? 

<flip>

Supermarkets looking for a 2k version of Green Stamps?

</flip>

		Mike, not entirely flippant


From owner-seamoby@diameter.org  Thu Jan  4 10:20:10 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06796
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 10:20:10 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f04EDxN05214
	for seamoby-list; Thu, 4 Jan 2001 06:13:59 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f04ECxW05209
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 06:13:00 -0800
Received: from glandon.inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id OAA02510;
	Thu, 4 Jan 2001 14:20:27 +0100 (MET)
Received: from inrialpes.fr (localhost [127.0.0.1])
	by glandon.inrialpes.fr (8.8.7/8.8.5) with ESMTP id OAA24694;
	Thu, 4 Jan 2001 14:20:25 +0100 (MET)
Message-ID: <3A547899.9CFA9167@inrialpes.fr>
Date: Thu, 04 Jan 2001 14:20:25 +0100
From: Claude Castelluccia <claude.castelluccia@inrialpes.fr>
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: James.Kempf@eng.sun.com
CC: Michael Thomas <mat@cisco.com>, seamoby-paging@egroups.com,
        Phil_Neumiller@3Com.com, seamoby@diameter.org,
        ramjee@dnrc.bell-labs.com
Subject: Re: [seamoby] Some thoughts on paging problem
References: <200012272022.MAA13006@nasnfs.eng.sun.com>
Content-Type: multipart/alternative;
 boundary="------------F2DA9833D3AF4719775BE7F3"
Sender: owner-seamoby@diameter.org
Precedence: bulk


--------------F2DA9833D3AF4719775BE7F3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hello James,

James Kempf wrote:

> > > You don't have to query multiple FAs. When
> > > a mobile transfers from one FA to another in dormant mode (determined
> > > because the L2 paging area boundry is crossed while the mobile is
> > > in dormant mode and the FA is monitoring the L2 trigger) the new FA
> > > assigns a new CoA for the mobile and
> > > informs the GFA.

yes, but the FA have to send a BU to the GFA each time the MN moves...
In IP Paging we also try to limit the number of BUs sent over the network
when a MN is dormant...

>
> >
> >   I don't understand this. How can a FA know that a mobile
> >   has moved passed the L2 paging area if the mobile is not
> >   speaking to the FA (ie, it's dormant). If the answer is
> >   that the mobile tells the FA, then I don't see why this
> >   situation is any different than wake-mode. If it doesn't,
> >   I'm at a loss as to how FA figures that out.
> >
>
> It's different because the mobile comes up, sends a short registration
> message to the RAN on a control channel (not a traffic channel), then
> goes back to sleep again. The FA figures out because the RAN via
> L2 tells it that a mobile has just moved into its paging area.
> Minimizing traffic channel usage for this kind of signalling is
> a requirement for some operators.

You actually make the assumption that some L2 paging is provided...
I don't think that we should make such assumption (or build systems that
make this assumption) in Seamboby...
If L2 paging is used, it should of course be used as an optimization...


regards,

Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------F2DA9833D3AF4719775BE7F3
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>Hello James,
<p>James Kempf wrote:
<blockquote TYPE=CITE>> > You don't have to query multiple FAs. When
<br>> > a mobile transfers from one FA to another in dormant mode (determined
<br>> > because the L2 paging area boundry is crossed while the mobile
is
<br>> > in dormant mode and the FA is monitoring the L2 trigger) the new
FA
<br>> > assigns a new CoA for the mobile and
<br>> > informs the GFA.</blockquote>
yes, but the FA have to send a BU&nbsp;to the GFA each time the MN&nbsp;moves...
<br>In IP&nbsp;Paging we also try to limit the number of BUs sent over
the network
<br>when a MN&nbsp;is dormant...&nbsp;&nbsp; 
<blockquote TYPE=CITE>&nbsp;
<br>>
<br>>&nbsp;&nbsp; I don't understand this. How can a FA know that a mobile
<br>>&nbsp;&nbsp; has moved passed the L2 paging area if the mobile is
not
<br>>&nbsp;&nbsp; speaking to the FA (ie, it's dormant). If the answer
is
<br>>&nbsp;&nbsp; that the mobile tells the FA, then I don't see why this
<br>>&nbsp;&nbsp; situation is any different than wake-mode. If it doesn't,
<br>>&nbsp;&nbsp; I'm at a loss as to how FA figures that out.
<br>>
<p>It's different because the mobile comes up, sends a short registration
<br>message to the RAN on a control channel (not a traffic channel), then
<br>goes back to sleep again. The FA figures out because the RAN via
<br>L2 tells it that a mobile has just moved into its paging area.
<br>Minimizing traffic channel usage for this kind of signalling is
<br>a requirement for some operators.</blockquote>
You actually make the assumption that some L2&nbsp;paging is provided...
<br>I don't think that we should make such assumption (or build systems
that
<br>make this assumption)&nbsp;in Seamboby...
<br>If L2 paging is used, it should of course be used as an optimization...
<br>&nbsp;
<p>regards,
<p>Claude.
<pre></pre>

<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------F2DA9833D3AF4719775BE7F3--



From owner-seamoby@diameter.org  Thu Jan  4 11:39:53 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09611
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 11:39:52 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f04G1f905370
	for seamoby-list; Thu, 4 Jan 2001 08:01:41 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f04G0gW05365
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 08:00:42 -0800
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26123;
	Thu, 4 Jan 2001 07:08:13 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA24740;
	Thu, 4 Jan 2001 07:08:12 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA20752;
	Thu, 4 Jan 2001 07:08:10 -0800 (PST)
Date: Thu, 4 Jan 2001 07:04:39 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [seamoby] Micromobility Problem Statement
To: Dave Martin <dmartin@kreative.net>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>, David Frascone <dave@frascone.com>,
        seamoby@diameter.org
In-Reply-To: "Your message with ID" <006901c075f0$5f6f3ba0$0100000a@david>
Message-ID: <Roam.SIMC.2.0.6.978620679.19351.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

> <snipping stuff about problem statement needed>
> 
> Here's a crack at one problem I would like to see solved.
> 
> Mobile IP does a decent job of tracking mobility, but it needs some
> improvements to support certain types of applications.  When a mobile node
> crosses from on FA cloud to another, the network will likely lose several
> packets while the network is updated with the mobiles new location.
> Furthermore this period of "unreachability" while in the transitioning phase
> generally lasts too long for time sensitive applications (e.g., duplex
> voice, etc).  A mechanism is needed that will allow mobile nodes
> unrestrained mobility while minimizing (eliminating?) packet loss and
> latency.
> 
> It probably needs some word-smithing.
> 
Dave,

Maybe it does, but it certainly is a good start. The question I have here,
though, is whether the fast handoff work in Mobile IP actually solves this
problem. I believe that it does. What do others think?

PatC



From owner-seamoby@diameter.org  Thu Jan  4 11:55:15 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10014
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 11:55:14 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f04GQec05419
	for seamoby-list; Thu, 4 Jan 2001 08:26:40 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (witbier.cisco.com [171.71.152.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f04GQIW05414
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 08:26:18 -0800
Received: from Ramalho-Family (rtp-vpn-35.cisco.com [10.82.192.35])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id HAA18598;
	Thu, 4 Jan 2001 07:32:38 -0800 (PST)
Message-Id: <4.1.20010104101917.00a09a80@witbier.cisco.com>
X-Sender: mramalho@witbier.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 04 Jan 2001 10:34:48 -0500
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>, Dave Martin <dmartin@kreative.net>
From: "Michael A. Ramalho" <mramalho@cisco.com>
Subject: Re: [seamoby] Micromobility Problem Statement
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>, David Frascone <dave@frascone.com>,
        seamoby@diameter.org
In-Reply-To: <Roam.SIMC.2.0.6.978620679.19351.pcalhoun@nasnfs>
References: <"Your message with ID" <006901c075f0$5f6f3ba0$0100000a@david>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Dave/Pat,

Some comments below.

Michael

At 07:04 AM 1/4/01 -0800, Pat Calhoun wrote:
>> <snipping stuff about problem statement needed>
>> 
>> Here's a crack at one problem I would like to see solved.
>> 
>> Mobile IP does a decent job of tracking mobility, but it needs some
>> improvements to support certain types of applications.  When a mobile node
>> crosses from on FA cloud to another, the network will likely lose several
>> packets while the network is updated with the mobiles new location.
>> Furthermore this period of "unreachability" while in the transitioning phase
>> generally lasts too long for time sensitive applications (e.g., duplex
>> voice, etc).  A mechanism is needed that will allow mobile nodes
>> unrestrained mobility while minimizing (eliminating?) packet loss and
>> latency.
>> 
>> It probably needs some word-smithing.
>> 
>Dave,
>
>Maybe it does, but it certainly is a good start. The question I have here,
>though, is whether the fast handoff work in Mobile IP actually solves this
>problem. I believe that it does. What do others think?

Partially. Within a trusted network boundary (a Trust Domain, in our
parlance) ... the fast handoff work in Mobile IP may be sufficient.
Especially if your network is over-engineered (no special QoS context
transfer needed) and you do not require re-authentication on the
network (because the next access router trusts anything that is
requested of it - like forwarding requests - from the previous router).

But ... I am hoping that seamoby addresses the larger, perhaps
cross-service provider problem. In which case one must also address
whether access routers in either service provider domain trust each
other when requests are made of it to do such-and-such (i.e., the
AAA/security issues). Then add to that the QoS "context" issue.
Then you have seamoby?

>
>PatC
>

BTW - Dana has been quiet on the list ... but what ever happened
to the Problem Statement in our draft as a start .... which was:

1.1 Problem Description

Mobility solutions require that packets be redirected to the current
location of a mobile device.  The Mobile IPv6 Binding Update [MIPv6] is
sufficient to accomplish this for best effort traffic.  However,
realtime applications require coordination of admission control,
security associations, and Quality of Service guarantees to minimize
packet loss and jitter to satisfy the expectations of realtime
applications.

Considered independently, admission control, Security Associations,
Quality of Service signaling, and Binding Updates could significantly
delay the transition from one access link to another, thus degrading the
performance of realtime applications.

[... Then a statement of what seamoby wants to accomplish here ... ].

Dave - Is this kind of where you were going?

Michael

Michael A. Ramalho, Ph.D.
Office email: mramalho@cisco.com
Personal email: mar42@cornell.edu
Office: +1.732.449.5762
Cell: +1.732.809.0188
Pager: +1.800.365.4578


From owner-seamoby@diameter.org  Thu Jan  4 12:30:39 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10908
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 12:30:38 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f04GlQ805444
	for seamoby-list; Thu, 4 Jan 2001 08:47:26 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f04GlOW05439
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 08:47:24 -0800
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id HAA22110;
	Thu, 4 Jan 2001 07:54:57 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA20690; Thu, 4 Jan 2001 07:54:57 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14932.40144.858096.874966@thomasm-u1.cisco.com>
Date: Thu, 4 Jan 2001 07:54:56 -0800 (PST)
To: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
Cc: "'Phil Neumiller'" <neumiller@telocity.com>, seamoby@diameter.org
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
In-Reply-To: <FC0292EA4D13D34EA2E5FC728D70A8E3078B7A@NEPTUNE.zucotto.com>
References: <FC0292EA4D13D34EA2E5FC728D70A8E3078B7A@NEPTUNE.zucotto.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


Kulwinder Atwal writes:
 > But, basically in 10 mSec I can talk to all seven slaves at least once, with
 > one Master/Slave slot pair left over.  I would like to use this slot pair to
 > do the switch.  It is not whether I can SAR longer packets than my one slot
 > MTU size of 28 bytes.  But, is it not more efficient and simple to have
 > Seamoby sit at the access point, and for me to translate Seamoby/IP packets
 > to link layer packets?  But, allowing non-Seamoby end user IP packets
 > through to the mobile?  

   I have serious doubts that you're going to be able
   to do anything useful in 28 bytes. If nothing else,
   the identity of the device must be proven to the
   new access router which normally takes between
   16 and 20 bytes plus whatever the device's DN
   is. Minimum. No protocol glue, no nothing else.
   And like v6 BU's, the hijacking attack here is so 
   obvious and so trivial, that security cannot be
   handwaved away.

   The problem here is not with IP or the seamoby.
   The problem is with the L2, or at least the way
   your proposing to use the L2.

		  Mike


From owner-seamoby@diameter.org  Thu Jan  4 13:29:16 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12388
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 13:29:16 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f04I6oE05575
	for seamoby-list; Thu, 4 Jan 2001 10:06:50 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f04I6mW05570
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 10:06:48 -0800
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f04HDL119119;
	Thu, 4 Jan 2001 09:13:21 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104])
	by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f04HELB29239;
	Thu, 4 Jan 2001 09:14:21 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 882569CA.005ED76E ; Thu, 4 Jan 2001 09:15:55 -0800
X-Lotus-FromDomain: 3COM
From: Phil_Neumiller@3Com.com
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
cc: seamoby@diameter.org
Message-ID: <882569CA.005ECE45.00@hqoutbound.ops.3com.com>
Date: Thu, 4 Jan 2001 11:19:34 -0600
Subject: Re: [seamoby] Micromobility Problem Statement
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-seamoby@diameter.org
Precedence: bulk



with zero deployment time on fast hand off how can we make an accurate assesment
of what it does and does not solve?  IMHO if it is not solving the problem at
the edge
of the Internet like we propose in seamoby its probably broken.

-pdn




From owner-seamoby@diameter.org  Thu Jan  4 13:36:14 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12576
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 13:36:13 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f04INag05609
	for seamoby-list; Thu, 4 Jan 2001 10:23:36 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f04INYW05604
	for <seamoby@cdma-2000.org>; Thu, 4 Jan 2001 10:23:34 -0800
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11280
	for <seamoby@cdma-2000.org>; Thu, 4 Jan 2001 09:31:11 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA25591
	for <seamoby@cdma-2000.org>; Thu, 4 Jan 2001 09:31:11 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA25773
	for <seamoby@cdma-2000.org>; Thu, 4 Jan 2001 09:31:09 -0800 (PST)
Date: Thu, 4 Jan 2001 09:27:36 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: [seamoby] Discussion on physical/link layers
To: seamoby@cdma-2000.org
Message-ID: <Roam.SIMC.2.0.6.978629256.8876.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

<hat>
Could we perhaps move the discussions on physical and link layer
architectures, their pros/cons, how the standard bodies could have done a
better job, how efficient they are, theories of power measurements, etc., to
another list? We really need to focus on our charter items. </hat>

For those of you that DO wish to continue these discussions, which are quite
interesting, could I convince you to make use of the cellular interest list?
Although bluetooth is not cellular, it does include lots of wireless expertise
(I suppose I should have called it wireless instead :(. The list can be found
at cellular@cdma-2000.org. You can register at cellular-request@cdma-2000.org.

Thanks,

PatC



From owner-seamoby@diameter.org  Thu Jan  4 13:49:33 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12867
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 13:49:33 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f04IKB705600
	for seamoby-list; Thu, 4 Jan 2001 10:20:11 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f04IK9W05595
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 10:20:09 -0800
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id JAA24109;
	Thu, 4 Jan 2001 09:27:37 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA20706; Thu, 4 Jan 2001 09:27:37 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14932.45705.30049.885313@thomasm-u1.cisco.com>
Date: Thu, 4 Jan 2001 09:27:37 -0800 (PST)
To: <James.Kempf@eng.sun.com>
Cc: "Michael Thomas" <mat@cisco.com>, <seamoby-paging@egroups.com>,
        <Phil_Neumiller@3Com.com>, <seamoby@diameter.org>,
        <ramjee@dnrc.bell-labs.com>
Subject: Re: [seamoby] Some thoughts on paging problem
In-Reply-To: <200012272022.MAA13006@nasnfs.eng.sun.com>
References: <200012272022.MAA13006@nasnfs.eng.sun.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

James Kempf writes:
 > It's different because the mobile comes up, sends a short registration
 > message to the RAN on a control channel (not a traffic channel), then
 > goes back to sleep again. The FA figures out because the RAN via
 > L2 tells it that a mobile has just moved into its paging area.
 > Minimizing traffic channel usage for this kind of signalling is
 > a requirement for some operators.

   I've gotten the impression that you cannot count on the
   mobile always re-registering mainly because to require
   it to do so is not efficient batterywise (and probably
   other reasons). I thought this was the ships-in-the-night
   problem.

   Reality check: I've been running on the assumption that
   the paging problem to be solved is where the
   last FA loses track of the exact location of
   the MN, and may in fact not be attached to the
   same interface and may not even be listening to 
   the same technology's control channel. Are we
   in sync here?

		Mike


From owner-seamoby@diameter.org  Thu Jan  4 13:50:23 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12919
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 13:50:23 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f04ISlC05628
	for seamoby-list; Thu, 4 Jan 2001 10:28:47 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f04ISiW05623
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 10:28:44 -0800
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15138;
	Thu, 4 Jan 2001 09:36:19 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA27142;
	Thu, 4 Jan 2001 09:36:18 -0800 (PST)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA26120;
	Thu, 4 Jan 2001 09:36:17 -0800 (PST)
Message-Id: <200101041736.JAA26120@nasnfs.eng.sun.com>
Date: Thu, 4 Jan 2001 09:36:34 -0800 (PST)
From: James Kempf <James.Kempf@eng.sun.com>
Reply-To: James Kempf <James.Kempf@eng.sun.com>
Subject: Re: [seamoby] Some thoughts on paging problem
To: James.Kempf@eng.sun.com, mat@cisco.com
Cc: mat@cisco.com, seamoby-paging@egroups.com, Phil_Neumiller@3Com.com,
        seamoby@diameter.org, ramjee@dnrc.bell-labs.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: ivIjnXXUVNgy+daolXamjA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Michael,

What I've described is basically the way CDMA works.

		jak
		
>From: Michael Thomas <mat@cisco.com>
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>Date: Thu, 4 Jan 2001 09:27:37 -0800 (PST)
>To: <James.Kempf@eng.sun.com>
>Cc: "Michael Thomas" <mat@cisco.com>, <seamoby-paging@egroups.com>, 
<Phil_Neumiller@3Com.com>, <seamoby@diameter.org>, <ramjee@dnrc.bell-labs.com>
>Subject: Re: [seamoby] Some thoughts on paging problem
>X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk 
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd 
bUcI'1!
>
>James Kempf writes:
> > It's different because the mobile comes up, sends a short registration
> > message to the RAN on a control channel (not a traffic channel), then
> > goes back to sleep again. The FA figures out because the RAN via
> > L2 tells it that a mobile has just moved into its paging area.
> > Minimizing traffic channel usage for this kind of signalling is
> > a requirement for some operators.
>
>   I've gotten the impression that you cannot count on the
>   mobile always re-registering mainly because to require
>   it to do so is not efficient batterywise (and probably
>   other reasons). I thought this was the ships-in-the-night
>   problem.
>
>   Reality check: I've been running on the assumption that
>   the paging problem to be solved is where the
>   last FA loses track of the exact location of
>   the MN, and may in fact not be attached to the
>   same interface and may not even be listening to 
>   the same technology's control channel. Are we
>   in sync here?
>
>		Mike



From owner-seamoby@diameter.org  Thu Jan  4 13:50:29 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12931
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 13:50:28 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f04IPWT05619
	for seamoby-list; Thu, 4 Jan 2001 10:25:32 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f04IPUW05614
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 10:25:30 -0800
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12740;
	Thu, 4 Jan 2001 09:33:05 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA26240;
	Thu, 4 Jan 2001 09:33:04 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA25860;
	Thu, 4 Jan 2001 09:33:02 -0800 (PST)
Date: Thu, 4 Jan 2001 09:29:32 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [seamoby] Some thoughts on paging problem
To: Michael Thomas <mat@cisco.com>
Cc: James.Kempf@eng.sun.com, seamoby-paging@egroups.com,
        Phil_Neumiller@3Com.com, seamoby@diameter.org,
        ramjee@dnrc.bell-labs.com
In-Reply-To: "Your message with ID" <14932.45705.30049.885313@thomasm-u1.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.978629372.24115.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

> James Kempf writes:
>  > It's different because the mobile comes up, sends a short registration
>  > message to the RAN on a control channel (not a traffic channel), then
>  > goes back to sleep again. The FA figures out because the RAN via
>  > L2 tells it that a mobile has just moved into its paging area.
>  > Minimizing traffic channel usage for this kind of signalling is
>  > a requirement for some operators.
> 
>    I've gotten the impression that you cannot count on the
>    mobile always re-registering mainly because to require
>    it to do so is not efficient batterywise (and probably
>    other reasons). I thought this was the ships-in-the-night
>    problem.
> 
>    Reality check: I've been running on the assumption that
>    the paging problem to be solved is where the
>    last FA loses track of the exact location of
>    the MN, and may in fact not be attached to the
>    same interface and may not even be listening to 
>    the same technology's control channel. Are we
>    in sync here?

I believe that we are in sync. I believe that Jim's point is that some recent
activities in the Mobile IP WG does allow for the mobile to be tracked without
requiring that it registers with the network. This is the proactive work. So
the main question is whether this proposal is sufficient, or whether there are
situations where additional paging work is required.

PatC



From owner-seamoby@diameter.org  Thu Jan  4 13:54:44 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12971
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 13:54:44 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f04IIO905588
	for seamoby-list; Thu, 4 Jan 2001 10:18:24 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f04IILW05583
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 10:18:21 -0800
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07108;
	Thu, 4 Jan 2001 09:25:57 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA23715;
	Thu, 4 Jan 2001 09:25:57 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA25354;
	Thu, 4 Jan 2001 09:25:55 -0800 (PST)
Date: Thu, 4 Jan 2001 09:22:25 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [seamoby] Micromobility Problem Statement
To: Phil_Neumiller@3Com.com
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>, seamoby@diameter.org
In-Reply-To: "Your message with ID" <882569CA.005ECE45.00@hqoutbound.ops.3com.com>
Message-ID: <Roam.SIMC.2.0.6.978628945.20059.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

> 
> 
> with zero deployment time on fast hand off how can we make an accurate
> assesment of what it does and does not solve? 
It certainly is closer to deployment than our current non-specified proposal,
right? :)

Seriously, what is needed is not deployment, but careful definition of the
problem statement, *then* requirements. At that point, any possible solution
can be matched up against any requirements and evaluated.

> IMHO if it is not solving the
> problem at the edge
> of the Internet like we propose in seamoby its probably broken.

It is on the edge of the Internet.

PatC



From owner-seamoby@diameter.org  Thu Jan  4 14:55:17 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14567
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 14:55:17 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f04JUG805730
	for seamoby-list; Thu, 4 Jan 2001 11:30:16 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f04JU9W05725
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 11:30:09 -0800
Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com;
          Thu, 4 Jan 2001 13:34:47 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBPPJ9>; Thu, 4 Jan 2001 13:32:44 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8069FF51C@zwdld001.ca.nortel.com>
From: "Guilhem Tardy" <guilhem.tardy@nortelnetworks.com>
To: "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>,
        "'Michael Ruckstuhl'" <mruckstuhl@MeshNetworks.com>,
        seamoby@diameter.org
Subject: RE: [seamoby] cart-before-seamoby
Date: Thu, 4 Jan 2001 13:32:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0767C.B5213AD0"
X-Orig: <guilhem.tardy@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0767C.B5213AD0
Content-Type: text/plain;
	charset="iso-8859-1"

I seriously doubt that plug-in interfaces require the same level of seamless
mobility as RF (aka "Electromagnetic Radiation" ;) equipments. Assuming
there is a RF datapath on, then if you plug an ethernet card into some local
LAN, you can surely wait another second until the ethernet card becomes your
primary datapath. Without a RF datapath, you were entirely disconnected
prior to plugging in, which leads to the same conclusion. I dare to write
here that Mobile-IP is plenty enough for this type of mobility.
 
Guilhem.

  -----Original Message-----
From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
Sent: Wednesday, January 03, 2001 5:19 PM
To: 'Michael Ruckstuhl'; seamoby@diameter.org
Subject: RE: [seamoby] cart-before-seamoby


My definition of RF includes near infra-red. Call it Electromagnetic
Radiation if you prefer. Maxwell's equations still apply. 
 
Whether it is:
 
- IR
- 802.11
 
We still can measure a signal strength.
 
But, you make a good point about switching between being plugged and
unplugged.
 
This suggests to me that L2 should handle roaming (seamless mobility) in a
homogenous network, because some networks like a LAN do not roam.
 
- Kulwinder. 

-----Original Message-----
From: Michael Ruckstuhl [mailto:mruckstuhl@meshnetworks.com]
Sent: Wednesday, January 03, 2001 3:24 PM
To: seamoby@diameter.org
Subject: RE: [seamoby] cart-before-seamoby


Wait a minute - are we assuming it's RF? I'm thinking I have my laptop with
an 802.11 card and an ethernet card - when I can plug into the local LAN, I
do, and that becomes my primary datapath. When I unplug, the 802.11 card
becomes my primary datapath. Maybe I have an IR transport of some kind. I
don't know, but the point is that mobility has to handle any kind of
transport, and should seamless mobility assume RF?
 
 
 


------_=_NextPart_001_01C0767C.B5213AD0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.50.4134.600" name=GENERATOR></HEAD>
<BODY>
<DIV>
<DIV>
<DIV><SPAN class=729100818-04012001><FONT face=Arial color=#0000ff size=2>I 
seriously doubt that plug-in interfaces require the same level of seamless 
mobility as RF&nbsp;<SPAN class=702202718-04012001>(aka 
"Electromagnetic&nbsp;Radiation" ;) </SPAN>equipments. Assuming there is a RF 
datapath on, then if you plug&nbsp;an ethernet card into some local LAN, you can 
surely wait another second until the ethernet card becomes your primary 
datapath.&nbsp;<SPAN class=702202718-04012001>Without a RF datapath, you 
were&nbsp;entirely disconnected prior to plugging in, which leads to the same 
conclusion. </SPAN>I dare to write here that Mobile-IP is plenty enough for this 
type of mobility.</FONT></SPAN></DIV>
<DIV><SPAN class=729100818-04012001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=729100818-04012001><FONT face=Arial color=#0000ff size=2><SPAN 
class=702202718-04012001>Guilhem.</SPAN></FONT></SPAN></DIV></DIV></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><FONT 
  size=2><SPAN class=702202718-04012001><FONT face=Arial 
  color=#0000ff>&nbsp;</FONT></SPAN></FONT></FONT><FONT face=Tahoma><FONT 
  size=2><SPAN class=702202718-04012001>&nbsp;</SPAN>-----Original 
  Message-----<BR><B>From:</B> Kulwinder Atwal 
  [mailto:kulwinder.atwal@zucotto.com]<BR><B>Sent:</B> Wednesday, January 03, 
  2001 5:19 PM<BR><B>To:</B> 'Michael Ruckstuhl'; 
  seamoby@diameter.org<BR><B>Subject:</B> RE: [seamoby] 
  cart-before-seamoby<BR><BR></DIV></FONT></FONT>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=835380722-03012001>My 
  definition of RF includes near infra-red. Call it 
  Electromagnetic&nbsp;Radiation if you prefer.&nbsp;Maxwell's equations still 
  apply.&nbsp;</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=835380722-03012001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=835380722-03012001>Whether it&nbsp;is:</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=835380722-03012001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=835380722-03012001>- 
  IR</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=835380722-03012001>- 
  802.11</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=835380722-03012001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=835380722-03012001>We 
  still can measure a signal strength.</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=835380722-03012001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=835380722-03012001>But, 
  you&nbsp;make a good point about switching between being plugged and 
  unplugged.</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=835380722-03012001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=835380722-03012001>This 
  suggests&nbsp;to me that L2 should handle roaming (seamless mobility)&nbsp;in 
  a homogenous network, because some&nbsp;</SPAN></FONT><FONT face=Arial 
  color=#0000ff size=2><SPAN class=835380722-03012001>networks like a&nbsp;LAN 
  do&nbsp;not roam.</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=835380722-03012001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=835380722-03012001>-&nbsp;Kulwinder.&nbsp;</SPAN></FONT></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> Michael Ruckstuhl 
    [mailto:mruckstuhl@meshnetworks.com]<BR><B>Sent:</B> Wednesday, January 03, 
    2001 3:24 PM<BR><B>To:</B> seamoby@diameter.org<BR><B>Subject:</B> RE: 
    [seamoby] cart-before-seamoby<BR><BR></FONT></DIV>
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
    class=138091420-03012001>Wait a minute -&nbsp;are we assuming&nbsp;it's RF? 
    I'm thinking I have my laptop with an 802.11 card and an ethernet card - 
    when I can plug into the local LAN, I do, and that becomes my primary 
    datapath. When I unplug, the 802.11 card becomes my primary datapath. Maybe 
    I have an IR transport of some kind. I don't know, but the point is that 
    mobility has to handle any kind of transport, and should seamless mobility 
    assume RF?</SPAN></FONT></DIV>
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
    class=138091420-03012001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
    class=138091420-03012001></SPAN></FONT>&nbsp;</DIV>
    <DIV><SPAN class=121242917-03012001><FONT face=Arial color=#0000ff 
    size=2></FONT></SPAN>&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0767C.B5213AD0--


From owner-seamoby@diameter.org  Thu Jan  4 14:55:47 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14603
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 14:55:46 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f04IsC905680
	for seamoby-list; Thu, 4 Jan 2001 10:54:12 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f04Is9W05675
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 10:54:09 -0800
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id KAA24892;
	Thu, 4 Jan 2001 10:01:41 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA20719; Thu, 4 Jan 2001 10:01:41 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14932.47749.224086.21973@thomasm-u1.cisco.com>
Date: Thu, 4 Jan 2001 10:01:41 -0800 (PST)
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: Michael Thomas <mat@cisco.com>, James.Kempf@eng.sun.com,
        seamoby-paging@egroups.com, Phil_Neumiller@3Com.com,
        seamoby@diameter.org, ramjee@dnrc.bell-labs.com
Subject: Re: [seamoby] Some thoughts on paging problem
In-Reply-To: <Roam.SIMC.2.0.6.978629372.24115.pcalhoun@nasnfs>
References: <14932.45705.30049.885313@thomasm-u1.cisco.com>
	<Roam.SIMC.2.0.6.978629372.24115.pcalhoun@nasnfs>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat Calhoun writes:
 > I believe that we are in sync. I believe that Jim's point is that some recent
 > activities in the Mobile IP WG does allow for the mobile to be tracked without
 > requiring that it registers with the network. This is the proactive work. So
 > the main question is whether this proposal is sufficient, or whether there are
 > situations where additional paging work is required.

   Proactive implies that the access point knows or has a 
   good guess as to where the mobile will move. My personal
   take is that that is probably not sufficient, especially
   if you want to deal with the vagueries of mixed technology.
   It seems exceedingly ugly, but doesn't the more general
   case require some sort of search?

		Mike


From owner-seamoby@diameter.org  Thu Jan  4 16:28:50 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16508
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 16:28:49 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f04KrRG05920
	for seamoby-list; Thu, 4 Jan 2001 12:53:27 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f04KrPW05915
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 12:53:25 -0800
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id NAA16285 for <seamoby@diameter.org>; Thu, 4 Jan 2001 13:01:03 -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id MAA02809 for <seamoby@diameter.org>; Thu, 4 Jan 2001 12:57:37 -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2651.58)
	id <Y4LX43C7>; Thu, 4 Jan 2001 14:01:03 -0600
Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A0498FDA1@il27exm02.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'campbell@comet.columbia.edu'" <campbell@comet.columbia.edu>
Cc: James Kempf <James.Kempf@eng.sun.com>, Phil_Neumiller@3Com.com,
        dblair@cisco.com, seamoby@diameter.org, cellularip@comet.columbia.edu
Subject: RE: [seamoby] Some thoughts and issues
Date: Thu, 4 Jan 2001 14:00:52 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C07689.0A9ECBB0"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C07689.0A9ECBB0
Content-Type: text/plain;
	charset="iso-8859-1"

Sorry for the really late reply. I am catching up with the email. I agree
with Gary here. Having a trigger for context transfer and the actual context
transfer are two different things. I thought one of the issues that we are
trying to solve in Seamoby was micromobility or handover while CoA does not
change, a problem that MIP does not deal with, so why are mentioning mobile
IP handoff solutions. Furthormore, as far as I know (maybe this info needs
to updated) fast handoff drafts do not address or provide a solution for the
context transfer problem.
 
 
Madjid

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Thursday, December 21, 2000 9:36 AM
To: 'campbell@comet.columbia.edu'
Cc: James Kempf; Phil_Neumiller@3Com.com; dblair@cisco.com;
seamoby@diameter.org; cellularip@comet.columbia.edu
Subject: RE: [seamoby] Some thoughts and issues



> -----Original Message----- 
> From: Andrew T. Campbell [ mailto:campbell@comet.columbia.edu
<mailto:campbell@comet.columbia.edu> ] 
> Sent: Thursday, December 21, 2000 7:06 AM 
> To: Kenward, Gary [WDLN2:AN10:EXCH] 
> Cc: James Kempf; Phil_Neumiller@3Com.com; dblair@cisco.com; 
> seamoby@diameter.org; cellularip@comet.columbia.edu 
> Subject: Re: [seamoby] Some thoughts and issues 
> 
> 
> 
> Gary: 
> 
> Thanks for the clarification. Comment below. 
> 
* snip * 

> > I agree with your observation, but I'm uncomfortable with the 
> > idea of a multitude of protocols firing up during an AP handover 
> > each transferring a piece of the context. To begin with, there is 
> > a state relationship between many of these many "individual" 
> > protocols. 
> > For example, it does not make sense to transfer authentication state 
> > after QoS. 
> > 
> 
> Since Mobile IP signaling (excuse the label) is central to 
> handoff execution I would argue that it is THE context transfer 
> protocol? That is, Mobile IP signaling should drive the 
> 'distributed network functions' (e.g., QOS, AAA, security, 
> policy, etc.) 
> to move (and possibly change or renegotiate) their state. 
> 
> You sort of want a context transfer extension to the 
> Mobile IP signaling to simply trigger the 
> distributed network functions to move their 
> state rather than have the Mobile IP signaling do all 
> the leg work. Why is that: 
> 
> Well, the complexity of how state is managed when moved is 
> very specific 
> to the distributed network functions and semantics of 
> the state (e.g., an adaptive wireless 
> QOS algorithms may be told 'move this state' but in the process of 
> handoff 
> the state may ne changed due to limited available resources, poorer 
> channel, etc.). Embedding that knowledge into a context transfer 
> protocol that really would be part of the Mobil IP signaling 
> may be way too complex a way to go? It bloats the handoff 
> signaling too. 
> Better to have the Mobile IP signaling for handoff trigger the 
> function that 'context' needs to be shifted and then it gets on 
> with its job of making mobility transparent on a session bases. 
> 
> Granted state is rather complex to get one head around without 
> specifics. Some state may be 'local' for distributed network 
> functions X and 'distributed' for function Y. State can also be 
> remain 'unchanged' with mobility (i.e., it does not change with 
> location) 
> while other state may be 'changed' (e.g., QOS). 
> 
> Seems to me that the context transfer mechanism that is driven by 
> Mobile IP (during, before or after handoff) 
> needs only to triggered that state transfer should take 
> place letting the appropriate distributed network functions do the job 
> in 
> a network function specific manner; since each network function 
> is aware of state attributes to mobility (i.e., 
> local/distributed, unchanged/changed). And, more importantly, 
> those functions are the only interpreters of the semantics 
> of that state with mobility. 
> 
> Warning: this note is sure speculation BTW. 
> 

Andrew: 

   As I was writing up my previous response I could foresee the suggestion
to 
use MIP. I can hardly object with the concept, if for no other reason then
contect 
transfer is required for MIP, and there will need to be an interaction. I
can envision 
scenarios where MIP invokes context transfer, and where a local handover
event 
triggers context transfer and MIP. The first scenario fits the MIP model
better, 
and the latter model really depends upon whether there is a legitimate
rationale 
for a micromobility solution. 

    I think we agree that MIP is not the right solution for taking care of
the actual 
context transfer. Hence, I think I hear you supporting some sort of context
transfer 
(note: I'm all for protocol reuse, but cringe at pasting features onto a
protocol that 
wasn't designed for the purpose). 

    Perhaps the issue that you are highlighting is really describing one
source of the 
"handoff trigger" as someone has described it. The issue of what triggers
context 
handover and when is, in my mind, involved. MIP is fine for proactive
context 
transfer (i.e. the context is to be replicated at potential target APs); I
feel that MIP 
would have problems with reactive transfer (e.g. what Pat C. was describing
at the 
wg meeting: the link is dissappearing as context is being transfered). 

   One issue to point out: some people have asked for a MIP free solution
for 
micromobility and context handover. This requirement is worth addressing, as
it 
could provide a more flexible architecture, and it should be compatible with
MIP 
interworking. 

   Lot's of text. I think I need to work on a time sequence diagram. For
January. 
Have a great holiday! 

Gary 


------_=_NextPart_001_01C07689.0A9ECBB0
Content-Type: text/html;
	charset="iso-8859-1"

<!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] Some thoughts and issues</TITLE>

<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=925035719-04012001>Sorry 
for the really late reply. I am catching up with the email. I agree with Gary 
here. Having a trigger for context transfer and the actual context transfer are 
two different things. I thought one of the issues that we are trying to solve in 
Seamoby was micromobility or handover while CoA does not change, a problem that 
MIP does not deal with, so why are mentioning mobile IP handoff solutions. 
Furthormore, as far as I know (maybe this info needs to updated) fast handoff 
drafts do not address or provide a solution for the context transfer 
problem.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=925035719-04012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=925035719-04012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=925035719-04012001>Madjid</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
  [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Thursday, December 21, 
  2000 9:36 AM<BR><B>To:</B> 'campbell@comet.columbia.edu'<BR><B>Cc:</B> James 
  Kempf; Phil_Neumiller@3Com.com; dblair@cisco.com; seamoby@diameter.org; 
  cellularip@comet.columbia.edu<BR><B>Subject:</B> RE: [seamoby] Some thoughts 
  and issues<BR><BR></DIV></FONT>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  From: Andrew T. Campbell [<A 
  href="mailto:campbell@comet.columbia.edu">mailto:campbell@comet.columbia.edu</A>]</FONT> 
  <BR><FONT size=2>&gt; Sent: Thursday, December 21, 2000 7:06 AM</FONT> 
  <BR><FONT size=2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]</FONT> <BR><FONT 
  size=2>&gt; Cc: James Kempf; Phil_Neumiller@3Com.com; dblair@cisco.com;</FONT> 
  <BR><FONT size=2>&gt; seamoby@diameter.org; 
  cellularip@comet.columbia.edu</FONT> <BR><FONT size=2>&gt; Subject: Re: 
  [seamoby] Some thoughts and issues</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; Gary:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  Thanks for the clarification. Comment below.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>* snip *</FONT> </P>
  <P><FONT size=2>&gt; &gt; I agree with your observation, but I'm uncomfortable 
  with the</FONT> <BR><FONT size=2>&gt; &gt; idea of a multitude of protocols 
  firing up during an AP handover</FONT> <BR><FONT size=2>&gt; &gt; each 
  transferring a piece of the context. To begin with, there is</FONT> <BR><FONT 
  size=2>&gt; &gt; a state relationship between many of these many 
  "individual"</FONT> <BR><FONT size=2>&gt; &gt; protocols.</FONT> <BR><FONT 
  size=2>&gt; &gt; For example, it does not make sense to transfer 
  authentication state</FONT> <BR><FONT size=2>&gt; &gt; after QoS.</FONT> 
  <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; Since Mobile IP signaling (excuse the label) is central to</FONT> 
  <BR><FONT size=2>&gt; handoff execution I would argue that it is THE context 
  transfer</FONT> <BR><FONT size=2>&gt; protocol? That is, Mobile IP signaling 
  should drive the </FONT><BR><FONT size=2>&gt; 'distributed network functions' 
  (e.g., QOS, AAA, security, </FONT><BR><FONT size=2>&gt; policy, etc.) 
  </FONT><BR><FONT size=2>&gt; to move (and possibly change or renegotiate) 
  their state. </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; You 
  sort of want a context transfer extension to the </FONT><BR><FONT size=2>&gt; 
  Mobile IP signaling to simply trigger the </FONT><BR><FONT size=2>&gt; 
  distributed network functions to move their </FONT><BR><FONT size=2>&gt; state 
  rather than have the Mobile IP signaling do all</FONT> <BR><FONT size=2>&gt; 
  the leg work. Why is that:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; Well, the complexity of how state is managed when moved is 
  </FONT><BR><FONT size=2>&gt; very specific</FONT> <BR><FONT size=2>&gt; to the 
  distributed network functions and semantics of</FONT> <BR><FONT size=2>&gt; 
  the state (e.g., an adaptive wireless </FONT><BR><FONT size=2>&gt; QOS 
  algorithms may be told 'move this state' but in the process of</FONT> 
  <BR><FONT size=2>&gt; handoff</FONT> <BR><FONT size=2>&gt; the state may ne 
  changed due to limited available resources, poorer</FONT> <BR><FONT 
  size=2>&gt; channel, etc.). Embedding that knowledge into a context 
  transfer</FONT> <BR><FONT size=2>&gt; protocol that really would be part of 
  the Mobil IP signaling</FONT> <BR><FONT size=2>&gt; may be way too complex a 
  way to go? It bloats the handoff </FONT><BR><FONT size=2>&gt; signaling 
  too.</FONT> <BR><FONT size=2>&gt; Better to have the Mobile IP signaling for 
  handoff trigger the</FONT> <BR><FONT size=2>&gt; function that 'context' needs 
  to be shifted and then it gets on</FONT> <BR><FONT size=2>&gt; with its job of 
  making mobility transparent on a session bases.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; Granted state is rather complex to get one head 
  around without</FONT> <BR><FONT size=2>&gt; specifics. Some state may be 
  'local' for distributed network </FONT><BR><FONT size=2>&gt; functions X and 
  'distributed' for function Y. State can also be </FONT><BR><FONT size=2>&gt; 
  remain 'unchanged' with mobility (i.e., it does not change with</FONT> 
  <BR><FONT size=2>&gt; location)</FONT> <BR><FONT size=2>&gt; while other state 
  may be 'changed' (e.g., QOS). </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; Seems to me that the context transfer mechanism that is driven 
  by</FONT> <BR><FONT size=2>&gt; Mobile IP (during, before or after handoff) 
  </FONT><BR><FONT size=2>&gt; needs only to triggered that state transfer 
  should take</FONT> <BR><FONT size=2>&gt; place letting the appropriate 
  distributed network functions do the job</FONT> <BR><FONT size=2>&gt; in 
  </FONT><BR><FONT size=2>&gt; a network function specific manner; since each 
  network function </FONT><BR><FONT size=2>&gt; is aware of state attributes to 
  mobility (i.e., </FONT><BR><FONT size=2>&gt; local/distributed, 
  unchanged/changed). And, more importantly,</FONT> <BR><FONT size=2>&gt; those 
  functions are the only interpreters of the semantics</FONT> <BR><FONT 
  size=2>&gt; of that state with mobility.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; Warning: this note is sure speculation 
  BTW.</FONT> <BR><FONT size=2>&gt; </FONT></P>
  <P><FONT size=2>Andrew:</FONT> </P>
  <P><FONT size=2>&nbsp;&nbsp; As I was writing up my previous response I could 
  foresee the suggestion to</FONT> <BR><FONT size=2>use MIP. I can hardly object 
  with the concept, if for no other reason then contect</FONT> <BR><FONT 
  size=2>transfer is required for MIP, and there will need to be an interaction. 
  I can envision</FONT> <BR><FONT size=2>scenarios where MIP invokes context 
  transfer, and where a local handover event</FONT> <BR><FONT size=2>triggers 
  context transfer and MIP. The first scenario fits the MIP model better,</FONT> 
  <BR><FONT size=2>and the latter model really depends upon whether there is a 
  legitimate rationale</FONT> <BR><FONT size=2>for a micromobility 
  solution.</FONT> </P>
  <P><FONT size=2>&nbsp;&nbsp;&nbsp; I think we agree that MIP is not the right 
  solution for taking care of the actual </FONT><BR><FONT size=2>context 
  transfer. Hence, I think I hear you supporting some sort of context 
  transfer</FONT> <BR><FONT size=2>(note: I'm all for protocol reuse, but cringe 
  at pasting features onto a protocol that </FONT><BR><FONT size=2>wasn't 
  designed for the purpose). </FONT></P>
  <P><FONT size=2>&nbsp;&nbsp;&nbsp; Perhaps the issue that you are highlighting 
  is really describing one source of the</FONT> <BR><FONT size=2>"handoff 
  trigger" as someone has described it. The issue of what triggers 
  context</FONT> <BR><FONT size=2>handover and when is, in my mind, involved. 
  MIP is fine for proactive context </FONT><BR><FONT size=2>transfer (i.e. the 
  context is to be replicated at potential target APs); I feel that MIP</FONT> 
  <BR><FONT size=2>would have problems with reactive transfer (e.g. what Pat C. 
  was describing at the</FONT> <BR><FONT size=2>wg meeting: the link is 
  dissappearing as context is being transfered). </FONT></P>
  <P><FONT size=2>&nbsp;&nbsp; One issue to point out: some people have asked 
  for a MIP free solution for </FONT><BR><FONT size=2>micromobility and context 
  handover. This requirement is worth addressing, as it</FONT> <BR><FONT 
  size=2>could provide a more flexible architecture, and it should be compatible 
  with MIP</FONT> <BR><FONT size=2>interworking.</FONT> </P>
  <P><FONT size=2>&nbsp;&nbsp; Lot's of text. I think I need to work on a time 
  sequence diagram. For January.</FONT> <BR><FONT size=2>Have a great 
  holiday!</FONT> </P>
  <P><FONT size=2>Gary</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C07689.0A9ECBB0--


From owner-seamoby@diameter.org  Thu Jan  4 16:51:31 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17013
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 16:51:31 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f04LPck05992
	for seamoby-list; Thu, 4 Jan 2001 13:25:38 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f04LPaW05987
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 13:25:36 -0800
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Thu Jan  4 15:30:31 EST 2001
Received: from dnrc.bell-labs.com (IDENT:21257@ramjeepc [135.180.240.106])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id PAA06837;
	Thu, 4 Jan 2001 15:31:38 -0500 (EST)
Message-ID: <3A54DD0E.5AD4C0CF@dnrc.bell-labs.com>
Date: Thu, 04 Jan 2001 20:29:02 +0000
From: Ramachandran Ramjee <ramjee@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: seamoby-paging@egroups.com
CC: Michael Thomas <mat@cisco.com>, James.Kempf@eng.sun.com,
        Phil_Neumiller@3Com.com, seamoby@diameter.org
Subject: Re: [seamoby-paging] Re: [seamoby] Some thoughts on paging problem
References: <Roam.SIMC.2.0.6.978629372.24115.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pat,

The conclusion that myself and Jim arrived at a few days ago was that
IP paging could be circumvented IF a single FA always covered one
whole paging area (the movement outside which an L2 update must be sent
-
this L2 update could then be used instead of a Mobile IP registration
to update the network). However, I am not sure one FA will always
map onto one paging area...in fact, this assumption really precludes
implementing a network that has one FA per base station because
paging areas typically consist of a set of base stations.

To summarize, IP paging is needed if mobiles could move
from the coverage of one FA to another FA without sending any updates
(L2 or L3) - in this case, some messages need to be examined among
the FAs to find the FA that currently serves the mobile.

Hope this clarifies.

Cheers,
Ram



> I believe that we are in sync. I believe that Jim's point is that some recent
> activities in the Mobile IP WG does allow for the mobile to be tracked without
> requiring that it registers with the network. This is the proactive work. So
> the main question is whether this proposal is sufficient, or whether there are
> situations where additional paging work is required.
> 
> PatC
> 
> To unsubscribe from this group, send an email to:
> seamoby-paging-unsubscribe@egroups.com


From owner-seamoby@diameter.org  Thu Jan  4 17:39:02 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17590
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 17:39:00 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f04LoMd06047
	for seamoby-list; Thu, 4 Jan 2001 13:50:22 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f04LoKW06042
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 13:50:20 -0800
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25366;
	Thu, 4 Jan 2001 12:57:54 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA20246;
	Thu, 4 Jan 2001 12:57:37 -0800 (PST)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA03592;
	Thu, 4 Jan 2001 12:57:20 -0800 (PST)
Message-Id: <200101042057.MAA03592@nasnfs.eng.sun.com>
Date: Thu, 4 Jan 2001 12:57:37 -0800 (PST)
From: James Kempf <James.Kempf@eng.sun.com>
Reply-To: James Kempf <James.Kempf@eng.sun.com>
Subject: Re: [seamoby-paging] Re: [seamoby] Some thoughts on paging problem
To: seamoby-paging@egroups.com, ramjee@dnrc.bell-labs.com
Cc: mat@cisco.com, James.Kempf@eng.sun.com, Phil_Neumiller@3Com.com,
        seamoby@diameter.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: Z8b/k3n9JwFOlfW/wHc3ow==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Ram,


>
>The conclusion that myself and Jim arrived at a few days ago was that
>IP paging could be circumvented IF a single FA always covered one
>whole paging area (the movement outside which an L2 update must be sent
>-
>this L2 update could then be used instead of a Mobile IP registration
>to update the network). However, I am not sure one FA will always
>map onto one paging area...in fact, this assumption really precludes
>implementing a network that has one FA per base station because
>paging areas typically consist of a set of base stations.
>
>To summarize, IP paging is needed if mobiles could move
>from the coverage of one FA to another FA without sending any updates
>(L2 or L3) - in this case, some messages need to be examined among
>the FAs to find the FA that currently serves the mobile.
>
>Hope this clarifies.

This is essentially correct. The one to one mapping of a paging
area to a subnet is required to use pro-active for paging.

Examining the other two cases we have:

1) Multiple FAs per paging area.

2) Multiple paging areas per FA.

Note that the first one would not work with proactive because if
the mobile is in dormant mode when it moves from one FA to another
there will be no L2 signal because it did not cross a paging
area boundary. When it does cross a paging boundary, it doesn't
cross a subnet boundary so there is no way for the FA to find
out where to send an incoming packet.

However, the second one would work. The reason is because when
the mobile moves from one paging area to another, L2 could take care of
updating the link address to CoA binding within the subnet, as
discussed in response to Gopal's scenario. Proactive isn't involved in
this case because the mobile is not moving subnets, but it
is still possible to cause the local subnet forwarding info
to be updated so the mobile is tracked at L3.

Comments?

		jak

 



From owner-seamoby@diameter.org  Thu Jan  4 18:26:49 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18199
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 18:26:48 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f04NATh06335
	for seamoby-list; Thu, 4 Jan 2001 15:10:29 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from c007.snv.cp.net (c007-h008.c007.snv.cp.net [209.228.33.214])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f04NAPW06329
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 15:10:26 -0800
Received: (cpmta 16916 invoked from network); 4 Jan 2001 14:13:06 -0800
Received: from dsl-64-193-0-129.telocity.com (HELO telocity.com) (64.193.0.129)
  by smtp.telocity.com (209.228.33.214) with SMTP; 4 Jan 2001 14:13:06 -0800
X-Sent: 4 Jan 2001 22:13:06 GMT
Message-ID: <3A54F5E3.95A8B60C@telocity.com>
Date: Thu, 04 Jan 2001 16:14:59 -0600
From: Phil Neumiller <neumiller@telocity.com>
Organization: 3Com
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: seamoby@diameter.org
Subject: [seamoby] cbyap registered www.seamoby.org!!!
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

I noticed that a person, Chern Nam Yap (cny.ieee.org)
that occasionally posts on the seamoby list with name
"cnyap" has chosen to unilaterally register the domain:

www.seamoby.org

Nice job buddy. It points to information that has no 
mention of seamoby.  You didn't ASK the seamoby list.
You did not TELL the seamoby list.  You did not inform
the IETF.  I hope everybody on the list will send cnyap
an expression of their gratitude for this act.

Sheesh,

Phil Neumiller


From owner-seamoby@diameter.org  Thu Jan  4 18:43:29 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18317
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 18:43:28 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f04NEhK06382
	for seamoby-list; Thu, 4 Jan 2001 15:14:43 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f04NClW06364
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 15:12:47 -0800
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27024;
	Thu, 4 Jan 2001 14:20:25 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA13214;
	Thu, 4 Jan 2001 14:20:25 -0800 (PST)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA06856;
	Thu, 4 Jan 2001 14:20:24 -0800 (PST)
Message-Id: <200101042220.OAA06856@nasnfs.eng.sun.com>
Date: Thu, 4 Jan 2001 14:20:41 -0800 (PST)
From: James Kempf <James.Kempf@eng.sun.com>
Reply-To: James Kempf <James.Kempf@eng.sun.com>
Subject: [seamoby] Paging List moved
To: seamoby@diameter.org
Cc: mscorson@popd.ix.netcom.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 28H07llNMQ8drC4MzOqu0g==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

We've moved the paging list to seamoby-paging@diameter.org, due to
complaints about the intrusive nature of egroups' questions. 

Please try to move discussion of paging to this list, until we've
got a definitive problem statement. Thanx.

		jak



From owner-seamoby@diameter.org  Thu Jan  4 19:29:42 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18832
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 19:29:42 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f050G6r06586
	for seamoby-list; Thu, 4 Jan 2001 16:16:06 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f050G2W06581
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 16:16:02 -0800
Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com;
          Thu, 4 Jan 2001 18:21:29 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBPXDS>; Thu, 4 Jan 2001 18:21:30 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8A7E@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Michael Thomas'" <mat@cisco.com>
Cc: "'Phil_Neumiller@3com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
Subject: RE: [seamoby] Micromobility Problem Statement
Date: Thu, 4 Jan 2001 18:21:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C076A5.0FD591B0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C076A5.0FD591B0
Content-Type: text/plain;
	charset="iso-8859-1"

<flop>

Or DisneyWorld

</flow>


> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Thursday, January 04, 2001 1:09 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Phil_Neumiller@3com.com'; seamoby@diameter.org
> Subject: RE: [seamoby] Micromobility Problem Statement
> 
> 
> Gary Kenward writes:
>  > Who is going to build these 802.11a networks and provide 
> them to users
>  > for free? 
> 
> <flip>
> 
> Supermarkets looking for a 2k version of Green Stamps?
> 
> </flip>
> 
> 		Mike, not entirely flippant
> 

------_=_NextPart_001_01C076A5.0FD591B0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] Micromobility Problem Statement</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>&lt;flop&gt;</FONT>
</P>

<P><FONT SIZE=2>Or DisneyWorld</FONT>
</P>

<P><FONT SIZE=2>&lt;/flow&gt;</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Michael Thomas [<A HREF="mailto:mat@cisco.com">mailto:mat@cisco.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, January 04, 2001 1:09 AM</FONT>
<BR><FONT SIZE=2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Cc: 'Phil_Neumiller@3com.com'; seamoby@diameter.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [seamoby] Micromobility Problem Statement</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Gary Kenward writes:</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; Who is going to build these 802.11a networks and provide </FONT>
<BR><FONT SIZE=2>&gt; them to users</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; for free? </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &lt;flip&gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Supermarkets looking for a 2k version of Green Stamps?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &lt;/flip&gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mike, not entirely flippant</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C076A5.0FD591B0--


From owner-seamoby@diameter.org  Thu Jan  4 20:10:48 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19114
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 20:10:47 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f050SSf06599
	for seamoby-list; Thu, 4 Jan 2001 16:28:28 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f050SPW06594
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 16:28:25 -0800
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id QAA08922 for <seamoby@diameter.org>; Thu, 4 Jan 2001 16:36:05 -0700 (MST)]
Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id QAA07414 for <seamoby@diameter.org>; Thu, 4 Jan 2001 16:36:04 -0700 (MST)]
Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2651.58)
	id <ZN1PFRZ6>; Thu, 4 Jan 2001 17:36:04 -0600
Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A0498FDAC@il27exm02.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Phil_Neumiller@3Com.com'" <Phil_Neumiller@3Com.com>
Cc: seamoby@diameter.org,
        Nakhjiri Madjid-MNAKHJI1
	 <Madjid.Nakhjiri@motorola.com>
Subject: [seamoby] Contract net protocol (phil's draft)
Date: Thu, 4 Jan 2001 17:36:02 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain
Sender: owner-seamoby@diameter.org
Precedence: bulk

Phil,

I went through your draft. The idea of contract net and bidding is very interesting. There were somethings that were not clear to me, My questions are

1-How many mobility agent would you have per access point.

2-What does the call anchor do? Is it any different than the context? You have one call anchor per call and you have several call anchors per mobility agent and you have transfer the call anchor to the new access point when you handover, so why is this different from saying that you have a context (or what you call contract) and you transfer the context. 
Also what is a call?

3-What if nobody's bid is within your satisfaction (your system quality is the highest as far as QoS, AAA and others)? then what? You excluded the possibility of negotiation.
What you mean by best AP? How do you provide a ranking? Also you cannot apply a constant neighbour ranking that applies to all the users, different users might have different level of demands, hence the ranking would be different.

4-By adding all the what you call "attributes" in the contract, I assume you are suggesting a lumped context transfer of all the states (which is I guess fine)


Thanks and Regards,

Madjid Nakhjiri

-----Original Message-----
From: Phil_Neumiller@3Com.com [mailto:Phil_Neumiller@3Com.com]
Sent: Tuesday, January 02, 2001 3:43 PM
To: Michael Ruckstuhl
Cc: seamoby@diameter.org
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001




Hi Michael,

I think you have cut to the chase here with Occam's razor (micromobility is
moving from
medieval to modern thought).  What I really like about your thinking is that you
see
that inter-domain, inter-operator, inter-mobile, inter AP, and inter-XYZ all
will have seamoby
requirements and just maybe a generalized solution may exist.  Its not your
father's
micro-mobility in the "classical" sense anymore.  I would like to twist your
ideas a bit further.

There will be cases where the "same" service provider provides different air
interfaces that
overlap in coverage on both different and the same subnets and in any possible
permutation
on this you can dream up. My argument is that the number of these "now weird"
combinations
is going to go up, not down.  A particular base station may "want" to do things
one way,
whereas a particular mobile may "want" do things another way due too their
perspective.
This is why, we need  (here goes Phil again!!!) something like a contract
bidding algorithm
running between the interested parties (mobility agents? (overloaded term)).

If you think this idea holds any water at all, you may be curious enough to read
the
(albeit a very rough and not ready draft) I-D:

http://www.ietf.org/internet-drafts/draft-neumiller-seamoby-cnpmobility-00.txt

W/respect to RSSI gradients, to me this is just fine tuning, and a much more
serious
problem is that RF coverage in general is spotty.  Its a fading environment full
of
holes, shadows, reflections, etc.  The real problem in my mind is keeping up
multiple
air interfaces until the other one is ready to go and not fading in and out
forcing
ping-poging etc.  I believe handover reliability will go up enourmously if
SeaMoby
institutes a try to do make-before-break before anything else policy.  I realize
this
will not always be possible, but lets build towards this goal.  Also, you can do
some
nifty multi-homing transport things with SCTP should we get far enough along
to discuss that.

BTW, I don't like the term micro-mobility, but we are probably stuck with it.
The
SeaMoby flavor of micromobility IMHO would be more appropriately called Edge
Mobility, since it involves the communication between edge devices like access
points and base stations and mobile nodes (all apologies to the EMA guys!).

Thanks,

Phil




Sent by:  Michael Ruckstuhl <mruckstuhl@MeshNetworks.com>


To:   "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>, seamoby@diameter.org
cc:    (Phil Neumiller/MW/US/3Com)
Subject:  RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001



One of the things I got out of Erik Anderlind's comments (12/20) was the
idea of separating handover on the local service network from selection of
'the (current) best' service network. The MN has its own ideas of best -
billing cost, battery cost, bandwidth cost, etc. However, if micromobility
can satisfy our needs on the current service network, we don't have to jump
through hoops to know all the RSSI gradient information. For the times (and
there will be some) when the current service network cannot maintain our QoS
needs following the handover, notification of this degradation of service
must be propagated to the correct layer on the MN, which would then
re-evaluate local service networks, and choose the 'best'.

I would like to see a segregation of inter- and intra- service network
handovers.

I think that the intra- handovers should be covered by whatever cost
agreements exist between the service provider and the subscriber, presenting
an 'homogenous' network, requiring no real awareness of Full Radio Map
(other networks) by the MN. I think that inter- handovers are more
complicated because the subscriber wants the 'best deal' and may have cost
vs. QoS vs. bandwidth tradeoffs affecting network selection.

Thus, intra-network handover can be made to maintain some BE support while
the MN realizes that an inter-network handover is now required per the
subscriber's configuration. I think the intra-network handover is what
everyone is discussing as micromobility?


mruckstuhl

-----Original Message-----
From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
Sent: Thursday, December 28, 2000 6:02 PM
To: 'Michael Thomas'; seamoby@diameter.org
Cc: Dave Oran; mankin@east.isi.edu
Subject: [seamoby] MicroMobility Algorithm Outline Revision 0.0001


Ok, I couldn't hold it in any longer.  Here it is.  My first crack this
problem.

MicroMobility Outline:

Tri-cell map: upto three of the nearest endpoints in hetro net.
Bi-cell map: upto two of the nearest endpoints in hetro net.
Radio map: a collection of bi-cells or tri-cells forming a hetro net.
Golden min: The minumum RSSI value that will trigger pro-active hand-off.
GUID: unque id for a tri-cell, or bi-cell.


Partial Radio Map Discovery
     Go thru Radio interfaces in preferred order  /* see if we are in a
radio map that we know
          Tx SeaMoby_Tri-cell_GUID       /* transmit the last GUIDS
that we knew current net
                              /* EP will respond with GUID
if correct, or tri-cell map
                              /* and new GUID
     Go until one acceptable QoS is found
Setup Connection                   /* Get up and running on one
good known link first.
Full Radio Map Discovery
     Send a SeaMoby Discovery packet with IDs for the different nets we
may want links for
     Wait for SeaMoby RSSI packets to come back with two RSSI
values,timestamps,QoS per AP
     and the relative position of homogenous APs

we have our relative position of APs and velocity vectors for MN to do
pro-active handoff.
Now we are ready for normal operation

If RSSI is less than Golden value then
Use Seamoby RSSI packets to monitor our relative position to discovered APs
We need at least a bi-cell within the radio map to track our change in
position.
This will tell us which AP is AP (N+1)

Handoff sequence Triggers:

T (Gold_min): The time that RSSI = Golden min
T (Start_ApNew): The trigger to start the microflows on AP(N+1)
T (MnSw_Start): The MN starts switching to the new AP(N+1).
T(MnSw_Stop): The MN finishes switching to AP(N+1).
T(Stop_ApOld): The trigger to stop the microflows on AP

I am ready.  Release the hounds!

- Kulwinder.










From owner-seamoby@diameter.org  Thu Jan  4 20:35:16 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19302
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 20:35:16 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f050qe506653
	for seamoby-list; Thu, 4 Jan 2001 16:52:40 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f050qcW06648
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 16:52:38 -0800
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA21142;
	Thu, 4 Jan 2001 16:00:12 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA14238;
	Thu, 4 Jan 2001 16:00:11 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA10135;
	Thu, 4 Jan 2001 16:00:05 -0800 (PST)
Date: Thu, 4 Jan 2001 15:56:35 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: RE: [seamoby] Some thoughts and issues
To: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
Cc: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'campbell@comet.columbia.edu'" <campbell@comet.columbia.edu>,
        James Kempf <James.Kempf@eng.sun.com>, Phil_Neumiller@3Com.com,
        dblair@cisco.com, seamoby@diameter.org, cellularip@comet.columbia.edu
In-Reply-To: "Your message with ID" <0DF9920C9AD8D211AB0C0008C7CF1C9A0498FDA1@il27exm02.cig.mot.com>
Message-ID: <Roam.SIMC.2.0.6.978652595.18651.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

> Sorry for the really late reply. I am catching up with the email. I agree
> with Gary here. Having a trigger for context transfer and the actual context
> transfer are two different things. I thought one of the issues that we are
> trying to solve in Seamoby was micromobility or handover while CoA does not
> change, a problem that MIP does not deal with, so why are mentioning mobile
> IP handoff solutions. Furthormore, as far as I know (maybe this info needs
> to updated) fast handoff drafts do not address or provide a solution for the
> context transfer problem.
>  
I believe that Raj's point was more along the lines that it is possible to
re-use Mobile IP messages to "transport" opaque context information during a
handoff. Now, I believe that we really do care about Mobile IP, because it
DOES provide fast handoff without requiring a CoA change. Now, the
micro-mobility folks (whose list was just setup and will be announced
shortly), need to specify what problem exists that Mobile IP does not. This is
something that the IESG folks are really interested in hearing, so we owe it
to them.

Whether protocol foo, or bar, it used to transport the context information is
actually irrelevent at the moment. What we need to provide is what is the
problem that causes state to be transfered from A to B, and why doing it
between the network nodes (as opposed to having the mobile redo it all) is
worthwhile.

Hope this clears up any possible confusion,

PatC



From owner-seamoby@diameter.org  Thu Jan  4 22:02:29 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20784
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 22:02:29 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0529Z006763
	for seamoby-list; Thu, 4 Jan 2001 18:09:35 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0528uW06758
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 18:08:56 -0800
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02395;
	Thu, 4 Jan 2001 17:16:31 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA03297;
	Thu, 4 Jan 2001 17:16:30 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id RAA12564;
	Thu, 4 Jan 2001 17:16:28 -0800 (PST)
Date: Thu, 4 Jan 2001 17:12:58 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: RE: [seamoby] Micromobility Problem Statement ISSUE 2
To: Gary Kenward <gkenward@nortelnetworks.com>
Cc: "'Phil_Neumiller@3Com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
In-Reply-To: "Your message with ID" <13E2EF604DE5D111B2E50000F80824E8057A8A66@zwdld001.ca.nortel.com>
Message-ID: <Roam.SIMC.2.0.6.978657178.24160.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

> Well stated Phil.
> 
> At the very least, the suite of IP mobility solutions should not impose
> topology restrictions - such as the number of hops between the MIP
> mobility agents and the AP - upon the network. 
> 
ok, so it looks like we are heading in a general direction. I do find Phil's
comments most interesting, but of course we cannot, in seamoby, redo layer 1
functions over IP (but perhaps someone should be looking at this). In any
case, one "problem" with micro-mobility are the number of hops between the
mobile and the mobility agent. 

Mobile IP restricts the number of hops to one. So an AP, in the traditional
802.11 sense, that acts as a bridge can allow Mobile IP to work through it,
assuming that a Foreign Agent is on the wired subnet. However, such an AP
working as a "router" would not work, since the Mobility Agents would not be
forwarded on the wireless link.

One discussion that I brought up in the paging sublist to describe a problem
where paging may be useful, in probably in fact a micro-mobility problem and
not a paging one (as James Kempf pointed out).

Here is the problem:

Imagine two wireless networks, each with their own AP. Each AP has two or more
Foreign Agents on the wired side to support the mobile nodes on the wireless
nets. Now let's assume that a mobile is on wireless net A, and is using
Foreign Agent X (on Net A). The mobile node moves to Net B, and the AP is
notified of the transition. Now the AP must somehow notify the FA of the
existence of the mobile. There is currently no protocol to do this. In the
cdma-2000 world, a bastardized version of Mobile IP is used (called the RP
interface). However, if such an environment needs to be supported, something
is required.

Now, whether or not the AP acts as a bridge, or a router, using the above
scenario, let's assume that the FA is (somehow) notified of the new mobile's
presence, and it finds out that the mobile moved from the AP on Net A. How
would the Foreign Agent know *which* FA supported the mobile on Net A? Looks
like something is required there.

I suppose the following questions should be asked:
1. Can we safely assume that Mobile IP is used on the mobile? I would hope
that the answer is yes, given that some mobility protocol needs to be
designed, and I would hate to have to go through the same History the MIP WG
went through :) if so,
2. Do we even care about a standardized protocol between the AP and the FA
3. Is a protocol required to locate the FA handling a particular mobile?

So are the above two points what Micro-mobility is all about?

PatC



From owner-seamoby@diameter.org  Thu Jan  4 22:03:20 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20796
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 22:03:20 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f052KoV06782
	for seamoby-list; Thu, 4 Jan 2001 18:20:50 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f052KmW06777
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 18:20:48 -0800
Received: (cpmta 6795 invoked from network); 4 Jan 2001 17:26:46 -0800
Received: from dsl-64-193-0-129.telocity.com (HELO telocity.com) (64.193.0.129)
  by smtp.telocity.com (209.228.33.206) with SMTP; 4 Jan 2001 17:26:46 -0800
X-Sent: 5 Jan 2001 01:26:46 GMT
Message-ID: <3A55234A.97D63ACE@telocity.com>
Date: Thu, 04 Jan 2001 19:28:42 -0600
From: Phil Neumiller <neumiller@telocity.com>
Organization: 3Com
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Gary Kenward <gkenward@nortelnetworks.com>
CC: "'Michael Thomas'" <mat@cisco.com>,
        "'Phil_Neumiller@3com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
Subject: Deconstructing Cellular WAS -> Re: [seamoby] Micromobility Problem 
 Statement
References: <13E2EF604DE5D111B2E50000F80824E8057A8A7E@zwdld001.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

See my <rebuttal></rebuttal> below.

\> Gary Kenward wrote:
> 
> <flop>
> 
> Or DisneyWorld
> 
> </flow>
> 
> > -----Original Message-----
> > From: Michael Thomas [mailto:mat@cisco.com]
> >
> > Gary Kenward writes:
> >  > Who is going to build these 802.11a networks and provide
> > them to users
> >  > for free?
> >
> > <flip>
> >
> > Supermarkets looking for a 2k version of Green Stamps?
> >
> > </flip>
> >
> >               Mike, not entirely flippant
> >
<rebuttal>
It certainly wont be the carriers that paid exorbitant prices for 
3G spectrum from a variety of world governments.  Tell me please,
does it make sense to have a 2 Mbps (you can only hope) link to
cell sites several kilometers away?  Meanwhile entrepreneurs that
grock the opportunity gap, will be deploying better, faster, and
cheaper pay-for services on 802.11a etc.  Who will win the race for
profit margins?  I think its obvious but time will tell.  The 3G
folks are going to be saddled with a minutes-of-use model to recoup
that BIG spectrum expenditure while the local wireless crowd will
be able to re-invest into QoS, AAA, SeaMoby!, etc., while offering
relatively FREE access to the BIG I.  Most people are in and
around building/infrastructer when they NEED high speed access 
(some automobile scenarios are the exception), so local wireless
can clearly steal outright the majority of broadband wireless
customers from cellular.  Light pipes to access points is the 
future whether you folks living in the cellular world dillusion 
want to admit or not.  It all makes sense economically so it is
bound to happen.  It will be unsuspected players deploying the
infrastructure introducing an element of innovation and competition
into wireless that has been lost since cellular became the end-all
solution, then again it could just be Cisco and 3Com afterall...
</rebuttal>


From owner-seamoby@diameter.org  Thu Jan  4 22:50:10 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22194
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 22:50:10 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f053FSY06861
	for seamoby-list; Thu, 4 Jan 2001 19:15:28 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from c007.snv.cp.net (c007-h014.c007.snv.cp.net [209.228.33.221])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f053FQW06856
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 19:15:26 -0800
Received: (cpmta 22302 invoked from network); 4 Jan 2001 18:23:00 -0800
Received: from dsl-64-193-0-129.telocity.com (HELO telocity.com) (64.193.0.129)
  by smtp.telocity.com (209.228.33.221) with SMTP; 4 Jan 2001 18:23:00 -0800
X-Sent: 5 Jan 2001 02:23:00 GMT
Message-ID: <3A553077.713E2F0@telocity.com>
Date: Thu, 04 Jan 2001 20:24:55 -0600
From: Phil Neumiller <neumiller@telocity.com>
Organization: 3Com
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
CC: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>,
        "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'campbell@comet.columbia.edu'" <campbell@comet.columbia.edu>,
        James Kempf <James.Kempf@eng.sun.com>, Phil_Neumiller@3Com.com,
        dblair@cisco.com, seamoby@diameter.org, cellularip@comet.columbia.edu
Subject: Re: [seamoby] Some thoughts and issues
References: <Roam.SIMC.2.0.6.978652595.18651.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bizzare comments below...

Pat Calhoun wrote:
> 
> > Sorry for the really late reply. I am catching up with the email. I agree
> > with Gary here. Having a trigger for context transfer and the actual context
> > transfer are two different things. I thought one of the issues that we are
> > trying to solve in Seamoby was micromobility or handover while CoA does not
> > change, a problem that MIP does not deal with, so why are mentioning mobile
> > IP handoff solutions. Furthormore, as far as I know (maybe this info needs
> > to updated) fast handoff drafts do not address or provide a solution for the
> > context transfer problem.
> >
> I believe that Raj's point was more along the lines that it is possible to
> re-use Mobile IP messages to "transport" opaque context information during a
> handoff. Now, I believe that we really do care about Mobile IP, because it
> DOES provide fast handoff without requiring a CoA change. Now, the
> micro-mobility folks (whose list was just setup and will be announced
> shortly), need to specify what problem exists that Mobile IP does not. This is
> something that the IESG folks are really interested in hearing, so we owe it
> to them.
> =
Pat,

Micro-mobility in the "classical" sense does not equal SeaMoby
micro-mobility
in my mind.  We are discussing inter-domain context transfer, as such we
may
in fact be wanting to extend existing MIP messages, etc.  Here goes a
REALLY
wacko idea... Since you yourself said that the fast handover solutions 
live on the edge wouldn't the more prudent division of labor be between
core (current MIP stuff) and edge (future seamoby stuff) mobility???  If
this
COULD be agreed upon, then FAST handover (that piggy backs context
transfer) 
moves to the edge mobility WG (formerly known as SeaMoby).  OK, maybe I
am
suggesting something totally wacked here...

Thanks,

Phil


From owner-seamoby@diameter.org  Thu Jan  4 22:51:55 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22222
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 22:51:54 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0536w006836
	for seamoby-list; Thu, 4 Jan 2001 19:06:58 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from c007.snv.cp.net (c007-h013.c007.snv.cp.net [209.228.33.220])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f0536uW06831
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 19:06:56 -0800
Received: (cpmta 8223 invoked from network); 4 Jan 2001 18:14:30 -0800
Received: from dsl-64-193-0-129.telocity.com (HELO telocity.com) (64.193.0.129)
  by smtp.telocity.com (209.228.33.220) with SMTP; 4 Jan 2001 18:14:30 -0800
X-Sent: 5 Jan 2001 02:14:30 GMT
Message-ID: <3A552E7A.A224AF4D@telocity.com>
Date: Thu, 04 Jan 2001 20:16:26 -0600
From: Phil Neumiller <neumiller@telocity.com>
Organization: 3Com
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
CC: "'Phil_Neumiller@3Com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
Subject: Re: [seamoby] Contract net protocol (phil's draft)
References: <0DF9920C9AD8D211AB0C0008C7CF1C9A0498FDAC@il27exm02.cig.mot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello Madjid,

Thank you very much for reading the draft and I really appreciate the
comments.  I realize that the draft is "solution" oriented and we
are in the "requirements" phase of SeaMoby, however, I believe one
very important potential requirements is illustrated in this draft.

REQUIREMENT?
Should context transfer be part of the handover decision (micro/macro
mobility)?  I believe it can be.  We can piggy-back our own state as
an AP (or possibly an MN) on our handover request.  This informs our
handover candidate APs of OUR state while requesting the handover.
It seems to be the most efficient way to do things to me (I also
believe is the road the fast handover drafts have went down).

My responses are interspersed below:

Nakhjiri Madjid-MNAKHJI1 wrote:
> 
> Phil,
> 
> I went through your draft. The idea of contract net and bidding is very
> interesting. There were somethings that were not clear to me, My questions
> are
> 
> 1-How many mobility agent would you have per access point.
> 
Absolutely ONE chunk of agent software, that sends receives and decides
on the contracts.  This agent works to send contracts on behalf of
clients
that wish to hand-out and acts as an "contract evaluator" on clients
wishing to hand in (sending their bids in).  This agent has THE VIEW of
the EDGE of the local mobility network.

> 2-What does the call anchor do? Is it any different than the context? You have
> one call anchor per call and you have several call anchors per mobility agent
> and you have transfer the call anchor to the new access point when you >handover, so why is this different from saying that you have a context (or what
>you call contract) and you transfer the context.

The call anchor is really is a synonym of the "real-time" call context. 
Only
an anchor (object?) has the "real-time" state of a particular call. 
When the
anchor is tossed, it is a serialization bundle of the anchor, i.e. THE
context
tranfer.

> Also what is a call?

What is a call???  Jeesh, I know you Madjid, you have worked in cellular
a 
LONG time....  OK, a call=connection=(MAIN PATH for a CONNECTION), i.e.
is
something end-to-end that is AAA'd for.  If you don't account for a call
or
have security, encryption, tunnelling, etc, your just handling datagrams
and
that is probably not a call (this gets real sticky though since some RF 
flavors require a ppp or other even to send ICMP messages).  I could use 
connection but call is shorter (SOMETHING CONNECTION ORIENTED).

> 
> 3-What if nobody's bid is within your satisfaction (your system quality is
> the highest as far as QoS, AAA and others)? then what? You excluded the
> possibility of negotiation.

Right.  The very second you add negotiation you open Pandora's box.  If
we
stick to agents that are fair (i.e. not self interested) we get nice
tractable
well behaving code.  When you add negotiation we instantly go non-linear
and
into NP complete problem space.  I think the simple answer here is
POLICY.
The mobile node must have a set of canned policy decisions like:

If I can't get what I want for QoS/AAA state XYZ, I accept NOTHING. 
or 
If I can't get what I want for QoS/AAA state XYZ, I take the next best
thing. 

> What do you mean by best AP? How do you provide a ranking? Also you cannot
> apply a constant neighbour ranking that applies to all the users, different
> users might have different level of demands, hence the ranking would be
> different.

In order for things to work fairly and simply, EVERYONE would HAVE to
agree
on the ranking metric.  This may be an equation that evaluates AAA, QoS, 
compression, work loads, etc., either way the ranking metric is
ESSENTIAL
and must be transitively agreed upon (possibly negotiated (during
initial
configuration, outages, route changes etc)). I think you understand the
draft
Madjid!!!

> 
> 4-By adding all the what you call "attributes" in the contract, I assume you
> are suggesting a lumped context transfer of all the states (which is I guess
> fine)
Exactly!

> 
> Thanks and Regards,
> 
> Madjid Nakhjiri

Thank you for the excellent comments and questions!

-pdn


From owner-seamoby@diameter.org  Thu Jan  4 23:03:40 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA22489
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 23:03:39 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f053YIi06885
	for seamoby-list; Thu, 4 Jan 2001 19:34:18 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from c007.snv.cp.net (c007-h008.c007.snv.cp.net [209.228.33.214])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f053YGW06880
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 19:34:16 -0800
Received: (cpmta 10961 invoked from network); 4 Jan 2001 18:41:50 -0800
Received: from dsl-64-193-0-129.telocity.com (HELO telocity.com) (64.193.0.129)
  by smtp.telocity.com (209.228.33.214) with SMTP; 4 Jan 2001 18:41:50 -0800
X-Sent: 5 Jan 2001 02:41:50 GMT
Message-ID: <3A5534E1.C714807D@telocity.com>
Date: Thu, 04 Jan 2001 20:43:45 -0600
From: Phil Neumiller <neumiller@telocity.com>
Organization: 3Com
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
CC: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>,
        "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'campbell@comet.columbia.edu'" <campbell@comet.columbia.edu>,
        James Kempf <James.Kempf@eng.sun.com>, Phil_Neumiller@3Com.com,
        dblair@cisco.com, seamoby@diameter.org, cellularip@comet.columbia.edu
Subject: Re: [seamoby] Some thoughts and issues
References: <Roam.SIMC.2.0.6.978661594.12718.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat Calhoun wrote:

> Perhaps, and this is, I believe, alot of what Cellular IP (Mobile IP at the
> edges, Cellular IP in the core) was all about. I even sent an e-mail today
> describing something similar.
> 
> PatC

Huh?  I seem to have this reversed, i.e. MIP at the core and
micro-mobility
at the edge, I don't seem to understand your comment.


From owner-seamoby@diameter.org  Thu Jan  4 23:04:51 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA22506
	for <seamoby-archive@odin.ietf.org>; Thu, 4 Jan 2001 23:04:48 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f053Mmr06872
	for seamoby-list; Thu, 4 Jan 2001 19:22:48 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f053MkW06867
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 19:22:46 -0800
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA22786;
	Thu, 4 Jan 2001 18:30:16 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA15692;
	Thu, 4 Jan 2001 18:30:16 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id SAA14880;
	Thu, 4 Jan 2001 18:30:05 -0800 (PST)
Date: Thu, 4 Jan 2001 18:26:34 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [seamoby] Some thoughts and issues
To: Phil Neumiller <neumiller@telocity.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>,
        "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'campbell@comet.columbia.edu'" <campbell@comet.columbia.edu>,
        James Kempf <James.Kempf@eng.sun.com>, Phil_Neumiller@3Com.com,
        dblair@cisco.com, seamoby@diameter.org, cellularip@comet.columbia.edu
In-Reply-To: "Your message with ID" <3A553077.713E2F0@telocity.com>
Message-ID: <Roam.SIMC.2.0.6.978661594.12718.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

> 
> Micro-mobility in the "classical" sense does not equal SeaMoby
> micro-mobility
> in my mind.  We are discussing inter-domain context transfer, as such we
> may
> in fact be wanting to extend existing MIP messages, etc.  Here goes a
> REALLY
> wacko idea... Since you yourself said that the fast handover solutions 
> live on the edge wouldn't the more prudent division of labor be between
> core (current MIP stuff) and edge (future seamoby stuff) mobility???  If
> this
> COULD be agreed upon, then FAST handover (that piggy backs context
> transfer) 
> moves to the edge mobility WG (formerly known as SeaMoby).  OK, maybe I
> am
> suggesting something totally wacked here...

Perhaps, and this is, I believe, alot of what Cellular IP (Mobile IP at the
edges, Cellular IP in the core) was all about. I even sent an e-mail today
describing something similar.

PatC



From owner-seamoby@diameter.org  Fri Jan  5 00:51:03 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23653
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 00:51:03 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f054ePh06920
	for seamoby-list; Thu, 4 Jan 2001 20:40:25 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f054eMW06915
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 20:40:22 -0800
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA26690;
	Thu, 4 Jan 2001 19:47:52 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA22970;
	Thu, 4 Jan 2001 19:47:51 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id TAA16602;
	Thu, 4 Jan 2001 19:47:45 -0800 (PST)
Date: Thu, 4 Jan 2001 19:44:04 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [seamoby] Some thoughts and issues
To: Phil Neumiller <neumiller@telocity.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>,
        "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'campbell@comet.columbia.edu'" <campbell@comet.columbia.edu>,
        James Kempf <James.Kempf@eng.sun.com>, Phil_Neumiller@3Com.com,
        dblair@cisco.com, seamoby@diameter.org, cellularip@comet.columbia.edu
In-Reply-To: "Your message with ID" <3A5534E1.C714807D@telocity.com>
Message-ID: <Roam.SIMC.2.0.6.978666244.22535.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

OOps.... I SHOULD have said Mobile IP in the core, and Cellular IP at the edge.
 sigh.

PatC
> Pat Calhoun wrote:
> 
> > Perhaps, and this is, I believe, alot of what Cellular IP (Mobile IP at the
> > edges, Cellular IP in the core) was all about. I even sent an e-mail today
> > describing something similar.
> > 
> > PatC
> 
> Huh?  I seem to have this reversed, i.e. MIP at the core and
> micro-mobility
> at the edge, I don't seem to understand your comment.




From owner-seamoby@diameter.org  Fri Jan  5 01:12:22 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24410
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 01:12:20 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f055ZRL07003
	for seamoby-list; Thu, 4 Jan 2001 21:35:27 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f055Y8W06998
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 21:34:08 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <ZJFR8WP5>; Thu, 4 Jan 2001 23:41:47 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B7B@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        Gary Kenward
	 <gkenward@nortelnetworks.com>
Cc: "'Phil_Neumiller@3Com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
Subject: RE: [seamoby] Micromobility Problem Statement ISSUE 2
Date: Thu, 4 Jan 2001 23:41:46 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

3. Is a protocol required to locate the FA handling a 
> particular mobile?

Maybe, I am missing something here.  But if the mobile is made responsible 
for its own movement, by requiring to:

1. Stay active if it wants real-time flows. 

2. Periodically transmit between dormant periods and re-associate with an
AP, if it wants to recieve a message.

3. Go completely dormant if it does not want to recieve a message.

4. Store the last AP/FA address and furnish it to the new AP, so it can
avoid the need for FA paging.

The problem I have with paging is its scalability.  What bounds are we
placing on how far a mobile can drift?   

Can the mobile do the ridiculous? Locate the other side of the planet and
cause a planet-wide page?  How many kWatts are we allowing the network to
expend to allow the mobile to save a few microWatts?  I think there needs to
be reasonable cap on how much network resources a mobile can consume.

???

Maybe, by saying "micro-mobility" the paging area is a sub-metro area.  But,
to ensure that, we need a time limit on how long the mobile can be dormant.
Which means the solution to the paging problem is 2 + 4 above.

- Kulwinder.

> 
> So are the above two points what Micro-mobility is all about?
> 
> PatC
> 


From owner-seamoby@diameter.org  Fri Jan  5 01:28:24 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25982
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 01:28:24 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05631A07037
	for seamoby-list; Thu, 4 Jan 2001 22:03:01 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0562wW07032
	for <seamoby@diameter.org>; Thu, 4 Jan 2001 22:02:58 -0800
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA18456;
	Thu, 4 Jan 2001 21:10:30 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA01166;
	Thu, 4 Jan 2001 21:10:29 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id VAA18422;
	Thu, 4 Jan 2001 21:10:23 -0800 (PST)
Date: Thu, 4 Jan 2001 21:06:52 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: RE: [seamoby] Micromobility Problem Statement ISSUE 2
To: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
Cc: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        Gary Kenward <gkenward@nortelnetworks.com>,
        "'Phil_Neumiller@3Com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
In-Reply-To: "Your message with ID" <FC0292EA4D13D34EA2E5FC728D70A8E3078B7B@NEPTUNE.zucotto.com>
Message-ID: <Roam.SIMC.2.0.6.978671212.5615.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

Perhaps I wasn't clear. When multiple FAs support an AP, and the mobile moves
to a new subnet (and AP), how should the new FA know *which* FA supported by
the old AP should be used. If the mobile informs the FA, then we have Mobile
IP with no fast handoff. In the pro-active case, the new FA needs to issue a
handoff-request to the old FA. This is known through a link layer message
(perhaps this is communicated via IP from the AP) to the FA.

Hope this is clearer, but I doubt it.
> 3. Is a protocol required to locate the FA handling a 
> > particular mobile?
> 
> Maybe, I am missing something here.  But if the mobile is made responsible 
> for its own movement, by requiring to:
> 
> 1. Stay active if it wants real-time flows. 
> 
> 2. Periodically transmit between dormant periods and re-associate with an
> AP, if it wants to recieve a message.
> 
> 3. Go completely dormant if it does not want to recieve a message.
> 
> 4. Store the last AP/FA address and furnish it to the new AP, so it can
> avoid the need for FA paging.
> 
> The problem I have with paging is its scalability.  What bounds are we
> placing on how far a mobile can drift?   
> 
> Can the mobile do the ridiculous? Locate the other side of the planet and
> cause a planet-wide page?  How many kWatts are we allowing the network to
> expend to allow the mobile to save a few microWatts?  I think there needs to
> be reasonable cap on how much network resources a mobile can consume.
> 
> ???
> 
> Maybe, by saying "micro-mobility" the paging area is a sub-metro area.  But,
> to ensure that, we need a time limit on how long the mobile can be dormant.
> Which means the solution to the paging problem is 2 + 4 above.
> 
> - Kulwinder.
> 
> > 
> > So are the above two points what Micro-mobility is all about?
> > 
> > PatC
> > 





From owner-seamoby@diameter.org  Fri Jan  5 11:44:23 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16362
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 11:44:22 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05G4it07890
	for seamoby-list; Fri, 5 Jan 2001 08:04:44 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05G4eW07885
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 08:04:41 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <ZJFR8WWL>; Fri, 5 Jan 2001 10:12:21 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B7C@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        Kulwinder Atwal
	 <kulwinder.atwal@herc.zucotto.com>
Cc: Gary Kenward <gkenward@nortelnetworks.com>,
        "'Phil_Neumiller@3Com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
Subject: RE: [seamoby] Micromobility Problem Statement ISSUE 2
Date: Fri, 5 Jan 2001 10:12:21 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk



> -----Original Message-----
> From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com]
> Sent: Friday, January 05, 2001 12:07 AM
> To: Kulwinder Atwal
> Cc: 'Pat Calhoun'; Gary Kenward; 'Phil_Neumiller@3Com.com';
> seamoby@diameter.org
> Subject: RE: [seamoby] Micromobility Problem Statement ISSUE 2
> 
> 
> Perhaps I wasn't clear. When multiple FAs support an AP, and 
> the mobile moves
> to a new subnet (and AP), how should the new FA know *which* 
> FA supported by
> the old AP should be used. If the mobile informs the FA, then 
> we have Mobile
> IP with no fast handoff. In the pro-active case, the new FA 
> needs to issue a
> handoff-request to the old FA. This is known through a link 
> layer message
> (perhaps this is communicated via IP from the AP) to the FA.
> 
> Hope this is clearer, but I doubt it.

I think so.  I think we have three cases at least.

Pro-active hand off:

Old AP knows the hand off is about to occur and notifies the new AP through
wired side.

Reative hand off:

The mobile finds it has crossed over, possibly after a communications
problem  (interference, etc.).  Sends last known AP address to new AP.  New
AP looks up old AP address and finds old AP IP address on wired side.  Sends
message to old AP on wired side.

Dormant hand off:

Cannot be seamless.  Mobile wakes up and sends last known AP address to new
AP.  New AP looks up the old AP IP address on the wired net and sends
message to old AP over wired link.

How's that?

- Kulwinder.

> > 3. Is a protocol required to locate the FA handling a 
> > > particular mobile?
> > 
> > Maybe, I am missing something here.  But if the mobile is 
> made responsible 
> > for its own movement, by requiring to:
> > 
> > 1. Stay active if it wants real-time flows. 
> > 
> > 2. Periodically transmit between dormant periods and 
> re-associate with an
> > AP, if it wants to recieve a message.
> > 
> > 3. Go completely dormant if it does not want to recieve a message.
> > 
> > 4. Store the last AP/FA address and furnish it to the new 
> AP, so it can
> > avoid the need for FA paging.
> > 
> > The problem I have with paging is its scalability.  What 
> bounds are we
> > placing on how far a mobile can drift?   
> > 
> > Can the mobile do the ridiculous? Locate the other side of 
> the planet and
> > cause a planet-wide page?  How many kWatts are we allowing 
> the network to
> > expend to allow the mobile to save a few microWatts?  I 
> think there needs to
> > be reasonable cap on how much network resources a mobile 
> can consume.
> > 
> > ???
> > 
> > Maybe, by saying "micro-mobility" the paging area is a 
> sub-metro area.  But,
> > to ensure that, we need a time limit on how long the mobile 
> can be dormant.
> > Which means the solution to the paging problem is 2 + 4 above.
> > 
> > - Kulwinder.
> > 
> > > 
> > > So are the above two points what Micro-mobility is all about?
> > > 
> > > PatC
> > > 
> 
> 
> 


From owner-seamoby@diameter.org  Fri Jan  5 12:01:12 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16711
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 12:01:11 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05GXdM07908
	for seamoby-list; Fri, 5 Jan 2001 08:33:39 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05GXaW07903
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 08:33:36 -0800
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA04943;
	Fri, 5 Jan 2001 07:41:10 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA23097;
	Fri, 5 Jan 2001 07:41:09 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA02611;
	Fri, 5 Jan 2001 07:41:08 -0800 (PST)
Date: Fri, 5 Jan 2001 07:37:36 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
To: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
Cc: "'Michael Ruckstuhl'" <mruckstuhl@MeshNetworks.com>,
        "'Kulwinder Atwal'" <kulwinder.atwal@herc.zucotto.com>,
        seamoby@diameter.org
In-Reply-To: "Your message with ID" <FC0292EA4D13D34EA2E5FC728D70A8E3078B63@NEPTUNE.zucotto.com>
Message-ID: <Roam.SIMC.2.0.6.978709056.5619.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

> The place for IP based real-time messaging is over the landline IP network
> between a Bluetooth Host and other Cellular Base Stations to switch IP
> packet flows.  Not, over a wireless link.  We cannot achieve seamless
> real-time behaviour by sending IP over a Bluetooth wireless link.  I need to
> get it done over a wireless link with only 28 bytes.
> 

Given the above comment, I am sure that many responses (or flames) have
already been sent, but I am still trying to catch up to all the threads as a
result of my vacation.

<chair hat>
It is not in this WG's position to break the end to end semantics of the
Internet by creating application gateways to deal with bluetooth's
deficiencies. </chair hat>

BTW, one can compress the IPv6 headers, using ROCH, down to one byte.

PatC



From owner-seamoby@diameter.org  Fri Jan  5 12:01:49 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16728
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 12:01:49 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05GZ8s07918
	for seamoby-list; Fri, 5 Jan 2001 08:35:08 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05GZ6W07913
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 08:35:06 -0800
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00004;
	Fri, 5 Jan 2001 07:42:41 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA23508;
	Fri, 5 Jan 2001 07:42:40 -0800 (PST)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA02714;
	Fri, 5 Jan 2001 07:42:40 -0800 (PST)
Message-Id: <200101051542.HAA02714@nasnfs.eng.sun.com>
Date: Fri, 5 Jan 2001 07:42:58 -0800 (PST)
From: James Kempf <James.Kempf@eng.sun.com>
Reply-To: James Kempf <James.Kempf@eng.sun.com>
Subject: RE: [seamoby] Micromobility Problem Statement ISSUE 2
To: gkenward@nortelnetworks.com, Pat.Calhoun@eng.sun.com
Cc: Phil_Neumiller@3Com.com, seamoby@diameter.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: kF00V1TsF37By3J4fpmxLw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Pat,

>Mobile IP restricts the number of hops to one. So an AP, in the traditional
>802.11 sense, that acts as a bridge can allow Mobile IP to work through it,
>assuming that a Foreign Agent is on the wired subnet. However, such an AP
>working as a "router" would not work, since the Mobility Agents would not be
>forwarded on the wireless link.
>

In HMIPv6, a MAP can be an arbitrary number of hops away from the AP. 
The access router is still only one hop, of course. But perhaps the
MAP could perform some of these functions.
 
>One discussion that I brought up in the paging sublist to describe a problem
>where paging may be useful, in probably in fact a micro-mobility problem and
>not a paging one (as James Kempf pointed out).
>
>Here is the problem:
>
>Imagine two wireless networks, each with their own AP. Each AP has two or more
>Foreign Agents on the wired side to support the mobile nodes on the wireless
>nets. Now let's assume that a mobile is on wireless net A, and is using
>Foreign Agent X (on Net A). The mobile node moves to Net B, and the AP is
>notified of the transition. Now the AP must somehow notify the FA of the
>existence of the mobile. There is currently no protocol to do this. In the
>cdma-2000 world, a bastardized version of Mobile IP is used (called the RP
>interface). However, if such an environment needs to be supported, something
>is required.
>
>Now, whether or not the AP acts as a bridge, or a router, using the above
>scenario, let's assume that the FA is (somehow) notified of the new mobile's
>presence, and it finds out that the mobile moved from the AP on Net A. How
>would the Foreign Agent know *which* FA supported the mobile on Net A? Looks
>like something is required there.
>
>I suppose the following questions should be asked:
>1. Can we safely assume that Mobile IP is used on the mobile? I would hope
>that the answer is yes, given that some mobility protocol needs to be
>designed, and I would hate to have to go through the same History the MIP WG
>went through :) if so,
>2. Do we even care about a standardized protocol between the AP and the FA
>3. Is a protocol required to locate the FA handling a particular mobile?
>So are the above two points what Micro-mobility is all about?
>
>PatC
>



From owner-seamoby@diameter.org  Fri Jan  5 12:26:49 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17322
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 12:26:47 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05H5rO07950
	for seamoby-list; Fri, 5 Jan 2001 09:05:53 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05H5pW07945
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 09:05:51 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 5 Jan 2001 11:10:43 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBQBBH>; Fri, 5 Jan 2001 11:10:44 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8A8C@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        Phil Neumiller <neumiller@telocity.com>
Cc: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>,
        "'campbell@comet.columbia.edu'" <campbell@comet.columbia.edu>,
        James Kempf <James.Kempf@eng.sun.com>, Phil_Neumiller@3Com.com,
        dblair@cisco.com, seamoby@diameter.org, cellularip@comet.columbia.edu
Subject: RE: [seamoby] Some thoughts and issues
Date: Fri, 5 Jan 2001 11:10:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C07732.0C373A30"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C07732.0C373A30
Content-Type: text/plain;
	charset="iso-8859-1"

> -----Original Message-----
> From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com]
> Sent: Thursday, January 04, 2001 9:27 PM
> To: Phil Neumiller
> Cc: Pat Calhoun; Nakhjiri Madjid-MNAKHJI1; Kenward, Gary
> [WDLN2:AN10:EXCH]; 'campbell@comet.columbia.edu'; James Kempf;
> Phil_Neumiller@3Com.com; dblair@cisco.com; seamoby@diameter.org;
> cellularip@comet.columbia.edu
> Subject: Re: [seamoby] Some thoughts and issues
> 
> 
> > 
> > Micro-mobility in the "classical" sense does not equal SeaMoby
> > micro-mobility
> > in my mind.  We are discussing inter-domain context 
> transfer, as such we

It was my understanding that we were concerned with context transfer in
general,
intra- and inter- domain. I am deluded as usual?

Gary
Or, am I taking this out of context?

> 

------_=_NextPart_001_01C07732.0C373A30
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] Some thoughts and issues</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Pat Calhoun [<A HREF="mailto:Pat.Calhoun@eng.sun.com">mailto:Pat.Calhoun@eng.sun.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, January 04, 2001 9:27 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Phil Neumiller</FONT>
<BR><FONT SIZE=2>&gt; Cc: Pat Calhoun; Nakhjiri Madjid-MNAKHJI1; Kenward, Gary</FONT>
<BR><FONT SIZE=2>&gt; [WDLN2:AN10:EXCH]; 'campbell@comet.columbia.edu'; James Kempf;</FONT>
<BR><FONT SIZE=2>&gt; Phil_Neumiller@3Com.com; dblair@cisco.com; seamoby@diameter.org;</FONT>
<BR><FONT SIZE=2>&gt; cellularip@comet.columbia.edu</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: [seamoby] Some thoughts and issues</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Micro-mobility in the &quot;classical&quot; sense does not equal SeaMoby</FONT>
<BR><FONT SIZE=2>&gt; &gt; micro-mobility</FONT>
<BR><FONT SIZE=2>&gt; &gt; in my mind.&nbsp; We are discussing inter-domain context </FONT>
<BR><FONT SIZE=2>&gt; transfer, as such we</FONT>
</P>

<P><FONT SIZE=2>It was my understanding that we were concerned with context transfer in general,</FONT>
<BR><FONT SIZE=2>intra- and inter- domain. I am deluded as usual?</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
<BR><FONT SIZE=2>Or, am I taking this out of context?</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C07732.0C373A30--


From owner-seamoby@diameter.org  Fri Jan  5 12:28:39 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17363
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 12:28:38 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05GuHA07933
	for seamoby-list; Fri, 5 Jan 2001 08:56:17 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (witbier.cisco.com [171.71.152.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05Gu7W07928
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 08:56:07 -0800
Received: from Ramalho-Family (sjc-vpn-42.cisco.com [10.21.64.42])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id IAA22659;
	Fri, 5 Jan 2001 08:00:08 -0800 (PST)
Message-Id: <4.1.20010105104002.00a5edf0@witbier.cisco.com>
X-Sender: mramalho@witbier.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 05 Jan 2001 11:02:17 -0500
To: Kulwinder Atwal <kulwinder.atwal@zucotto.com>,
        "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        Kulwinder Atwal <kulwinder.atwal@herc.zucotto.com>
From: "Michael A. Ramalho" <mramalho@cisco.com>
Subject: RE: [seamoby] Micromobility Problem Statement ISSUE 2
Cc: Gary Kenward <gkenward@nortelnetworks.com>,
        "'Phil_Neumiller@3Com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
In-Reply-To: <FC0292EA4D13D34EA2E5FC728D70A8E3078B7C@NEPTUNE.zucotto.com
 >
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-seamoby@diameter.org
Precedence: bulk

At 10:12 AM 1/5/01 -0500, Kulwinder Atwal wrote:
>
>
>> -----Original Message-----
>> From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com]
>> Sent: Friday, January 05, 2001 12:07 AM
>> To: Kulwinder Atwal
>> Cc: 'Pat Calhoun'; Gary Kenward; 'Phil_Neumiller@3Com.com';
>> seamoby@diameter.org
>> Subject: RE: [seamoby] Micromobility Problem Statement ISSUE 2
>> 
>> 
>> Perhaps I wasn't clear. When multiple FAs support an AP, and 
>> the mobile moves
>> to a new subnet (and AP), how should the new FA know *which* 
>> FA supported by
>> the old AP should be used. If the mobile informs the FA, then 
>> we have Mobile
>> IP with no fast handoff. In the pro-active case, the new FA 
>> needs to issue a
>> handoff-request to the old FA. This is known through a link 
>> layer message
>> (perhaps this is communicated via IP from the AP) to the FA.
>> 
>> Hope this is clearer, but I doubt it.
>
>I think so.  I think we have three cases at least.
>
>Pro-active hand off:
>
>Old AP knows the hand off is about to occur and notifies the new AP through
>wired side.
>
>Reative hand off:
>
>The mobile finds it has crossed over, possibly after a communications
>problem  (interference, etc.).  Sends last known AP address to new AP.  New
>AP looks up old AP address and finds old AP IP address on wired side.  Sends
>message to old AP on wired side.

Kulwinder,

The appendix of our draft (draft-blair-rt-mobileipv6-seamoby-00.txt)
essentially specifies this type of (forwarding/context transfer)
behavior for particular types of authorization, authentication,
security and QoS schemes that we have studied.

Key to our thoughts are to be proactive when you can (i.e,
try to make before break and send credentials that you believe
may be accepted by the next AR ... remember ... it may
not trust these!) ... and if either you lose connectivity before
accomplishing your proactive steps OR if the next AR doesn't
like/trust/accommodate parts your proactive request ... try to set up
these relationships (including packet forwarding) as soon as possible
under fallback conditions.

Next try to accomplish this (fast-handoff) behavior while thinking
about admission control, security associations, QoS signaling and
binding updates CONCURRENTLY ... and you have the jist of our draft.

For "fast-handoff" cross-service provider handoffs we need to
try to accomplish as many steps *in parallel* as the new access
link and/or access router/AP will accommodate. To do otherwise
will increase the likelihood of non-seamlessness (due to serial
processing of requests like QoS or AAA).

The key here is that we expect that for a given subnet or service
provider trust boundary ... the vast majority of the handoffs can
be made seamless (high trust between the elements ... they
all belong to the same service provider!).

For handoffs where additional AAA/QoS work has to be done (i.e.,
a transfer to another service provider) ... it may or may not be
perfectly seamless ... but we don't drop the session. If the
service providers involved develop credentials each other
trust ... then the likelihood of seamlessness between
these service providers is increased.

Michael

>
>Dormant hand off:
>
>Cannot be seamless.  Mobile wakes up and sends last known AP address to new
>AP.  New AP looks up the old AP IP address on the wired net and sends
>message to old AP over wired link.
>
>How's that?
>
>- Kulwinder.
>
>> > 3. Is a protocol required to locate the FA handling a 
>> > > particular mobile?
>> > 
>> > Maybe, I am missing something here.  But if the mobile is 
>> made responsible 
>> > for its own movement, by requiring to:
>> > 
>> > 1. Stay active if it wants real-time flows. 
>> > 
>> > 2. Periodically transmit between dormant periods and 
>> re-associate with an
>> > AP, if it wants to recieve a message.
>> > 
>> > 3. Go completely dormant if it does not want to recieve a message.
>> > 
>> > 4. Store the last AP/FA address and furnish it to the new 
>> AP, so it can
>> > avoid the need for FA paging.
>> > 
>> > The problem I have with paging is its scalability.  What 
>> bounds are we
>> > placing on how far a mobile can drift?   
>> > 
>> > Can the mobile do the ridiculous? Locate the other side of 
>> the planet and
>> > cause a planet-wide page?  How many kWatts are we allowing 
>> the network to
>> > expend to allow the mobile to save a few microWatts?  I 
>> think there needs to
>> > be reasonable cap on how much network resources a mobile 
>> can consume.
>> > 
>> > ???
>> > 
>> > Maybe, by saying "micro-mobility" the paging area is a 
>> sub-metro area.  But,
>> > to ensure that, we need a time limit on how long the mobile 
>> can be dormant.
>> > Which means the solution to the paging problem is 2 + 4 above.
>> > 
>> > - Kulwinder.
>> > 
>> > > 
>> > > So are the above two points what Micro-mobility is all about?
>> > > 
>> > > PatC
>> > > 
>> 
>> 
>> 


Michael A. Ramalho, Ph.D.
Office email: mramalho@cisco.com
Personal email: mar42@cornell.edu
Office: +1.732.449.5762
Cell: +1.732.809.0188
Pager: +1.800.365.4578


From owner-seamoby@diameter.org  Fri Jan  5 12:45:40 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17780
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 12:45:39 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05HEYw07962
	for seamoby-list; Fri, 5 Jan 2001 09:14:34 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05HEWW07957
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 09:14:32 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <ZJFR8WZJ>; Fri, 5 Jan 2001 11:22:12 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B7D@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Michael A. Ramalho'" <mramalho@cisco.com>,
        "'Pat Calhoun'"
	 <Pat.Calhoun@eng.sun.com>
Cc: Gary Kenward <gkenward@nortelnetworks.com>,
        "'Phil_Neumiller@3Com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
Subject: RE: [seamoby] Micromobility Problem Statement ISSUE 2
Date: Fri, 5 Jan 2001 11:22:11 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

I agree, I will read your draft before commenting further.

Also, Pat:

I will read draft-ietf-rohc-rtp-06.txt.

I did not know the IETF was looking at header compression.  In the SIG there
was a proposed draft in Sept., but I was hoping for an IETF solution.
Thanks.  I will read.

- Kulwinder. 


> -----Original Message-----
> From: Michael A. Ramalho [mailto:mramalho@cisco.com]
> Sent: Friday, January 05, 2001 11:02 AM
> To: Kulwinder Atwal; 'Pat Calhoun'; Kulwinder Atwal
> Cc: Gary Kenward; 'Phil_Neumiller@3Com.com'; seamoby@diameter.org
> Subject: RE: [seamoby] Micromobility Problem Statement ISSUE 2
> 
> 
> At 10:12 AM 1/5/01 -0500, Kulwinder Atwal wrote:
> >
> >
> >> -----Original Message-----
> >> From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com]
> >> Sent: Friday, January 05, 2001 12:07 AM
> >> To: Kulwinder Atwal
> >> Cc: 'Pat Calhoun'; Gary Kenward; 'Phil_Neumiller@3Com.com';
> >> seamoby@diameter.org
> >> Subject: RE: [seamoby] Micromobility Problem Statement ISSUE 2
> >> 
> >> 
> >> Perhaps I wasn't clear. When multiple FAs support an AP, and 
> >> the mobile moves
> >> to a new subnet (and AP), how should the new FA know *which* 
> >> FA supported by
> >> the old AP should be used. If the mobile informs the FA, then 
> >> we have Mobile
> >> IP with no fast handoff. In the pro-active case, the new FA 
> >> needs to issue a
> >> handoff-request to the old FA. This is known through a link 
> >> layer message
> >> (perhaps this is communicated via IP from the AP) to the FA.
> >> 
> >> Hope this is clearer, but I doubt it.
> >
> >I think so.  I think we have three cases at least.
> >
> >Pro-active hand off:
> >
> >Old AP knows the hand off is about to occur and notifies the 
> new AP through
> >wired side.
> >
> >Reative hand off:
> >
> >The mobile finds it has crossed over, possibly after a communications
> >problem  (interference, etc.).  Sends last known AP address 
> to new AP.  New
> >AP looks up old AP address and finds old AP IP address on 
> wired side.  Sends
> >message to old AP on wired side.
> 
> Kulwinder,
> 
> The appendix of our draft (draft-blair-rt-mobileipv6-seamoby-00.txt)
> essentially specifies this type of (forwarding/context transfer)
> behavior for particular types of authorization, authentication,
> security and QoS schemes that we have studied.
> 
> Key to our thoughts are to be proactive when you can (i.e,
> try to make before break and send credentials that you believe
> may be accepted by the next AR ... remember ... it may
> not trust these!) ... and if either you lose connectivity before
> accomplishing your proactive steps OR if the next AR doesn't
> like/trust/accommodate parts your proactive request ... try to set up
> these relationships (including packet forwarding) as soon as possible
> under fallback conditions.
> 
> Next try to accomplish this (fast-handoff) behavior while thinking
> about admission control, security associations, QoS signaling and
> binding updates CONCURRENTLY ... and you have the jist of our draft.
> 
> For "fast-handoff" cross-service provider handoffs we need to
> try to accomplish as many steps *in parallel* as the new access
> link and/or access router/AP will accommodate. To do otherwise
> will increase the likelihood of non-seamlessness (due to serial
> processing of requests like QoS or AAA).
> 
> The key here is that we expect that for a given subnet or service
> provider trust boundary ... the vast majority of the handoffs can
> be made seamless (high trust between the elements ... they
> all belong to the same service provider!).
> 
> For handoffs where additional AAA/QoS work has to be done (i.e.,
> a transfer to another service provider) ... it may or may not be
> perfectly seamless ... but we don't drop the session. If the
> service providers involved develop credentials each other
> trust ... then the likelihood of seamlessness between
> these service providers is increased.
> 
> Michael
> 
> >
> >Dormant hand off:
> >
> >Cannot be seamless.  Mobile wakes up and sends last known AP 
> address to new
> >AP.  New AP looks up the old AP IP address on the wired net and sends
> >message to old AP over wired link.
> >
> >How's that?
> >
> >- Kulwinder.
> >
> >> > 3. Is a protocol required to locate the FA handling a 
> >> > > particular mobile?
> >> > 
> >> > Maybe, I am missing something here.  But if the mobile is 
> >> made responsible 
> >> > for its own movement, by requiring to:
> >> > 
> >> > 1. Stay active if it wants real-time flows. 
> >> > 
> >> > 2. Periodically transmit between dormant periods and 
> >> re-associate with an
> >> > AP, if it wants to recieve a message.
> >> > 
> >> > 3. Go completely dormant if it does not want to recieve 
> a message.
> >> > 
> >> > 4. Store the last AP/FA address and furnish it to the new 
> >> AP, so it can
> >> > avoid the need for FA paging.
> >> > 
> >> > The problem I have with paging is its scalability.  What 
> >> bounds are we
> >> > placing on how far a mobile can drift?   
> >> > 
> >> > Can the mobile do the ridiculous? Locate the other side of 
> >> the planet and
> >> > cause a planet-wide page?  How many kWatts are we allowing 
> >> the network to
> >> > expend to allow the mobile to save a few microWatts?  I 
> >> think there needs to
> >> > be reasonable cap on how much network resources a mobile 
> >> can consume.
> >> > 
> >> > ???
> >> > 
> >> > Maybe, by saying "micro-mobility" the paging area is a 
> >> sub-metro area.  But,
> >> > to ensure that, we need a time limit on how long the mobile 
> >> can be dormant.
> >> > Which means the solution to the paging problem is 2 + 4 above.
> >> > 
> >> > - Kulwinder.
> >> > 
> >> > > 
> >> > > So are the above two points what Micro-mobility is all about?
> >> > > 
> >> > > PatC
> >> > > 
> >> 
> >> 
> >> 
> 
> 
> Michael A. Ramalho, Ph.D.
> Office email: mramalho@cisco.com
> Personal email: mar42@cornell.edu
> Office: +1.732.449.5762
> Cell: +1.732.809.0188
> Pager: +1.800.365.4578
> 


From owner-seamoby@diameter.org  Fri Jan  5 13:10:14 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18479
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 13:10:13 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05HfJx08003
	for seamoby-list; Fri, 5 Jan 2001 09:41:19 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05HfGW07998
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 09:41:16 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 5 Jan 2001 11:47:42 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBQCM0>; Fri, 5 Jan 2001 11:47:43 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8A8D@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: seamoby@diameter.org
Subject: RE: [seamoby] Micromobility Problem Statement ISSUE 2
Date: Fri, 5 Jan 2001 11:47:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C07737.33254100"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C07737.33254100
Content-Type: text/plain;
	charset="iso-8859-1"

> -----Original Message-----
> From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com]
> Sent: Thursday, January 04, 2001 8:13 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Phil_Neumiller@3Com.com'; seamoby@diameter.org
> Subject: RE: [seamoby] Micromobility Problem Statement ISSUE 2
> 

*snip*

> ok, so it looks like we are heading in a general direction. I 
> do find Phil's
> comments most interesting, but of course we cannot, in 
> seamoby, redo layer 1
> functions over IP (but perhaps someone should be looking at 
> this). In any
> case, one "problem" with micro-mobility are the number of 
> hops between the
> mobile and the mobility agent. 
> 
> Mobile IP restricts the number of hops to one. So an AP, in 

If I may, I think that the hop distance is the major issue here.
Assume for the moment that for a particular function, there is
a topological locus that is the optimal location for that function 
to be executed. Optimal in terms of performance, reliability,
scalability, etc. 

No matter how you design it, any solution that is located one or
more hops away from its optimal locus will be  less efficient. 

To clarify: MIPs primary function (step in any time here if I've got
this wrong) is inter-network mobility. As MIP is concerned with sustainment
of reachability (and AAA), the main "locii activity" is the really the 
network addressing and security domain - in cellular parlance, it is a "core
network" function. The optimal locii an HA or FA is "near" (at most one
hop away from) the other "core network functions" such as AAA, policy,
etc. Using MIP is a bit of a stretch, as it's function is less sensitive to
degraded performance.

SeaMoby (micromobility, context transfer) is concerned with sustaining
the bearer service provided to an MNs flows (aka: the packet level handover 
and microflow QoS at the edges). This goal is far more sensitive to
performance
degradation, and clearly suffers when distanced from the point locii of
activity, namely the actual handover between access points.

FH, as far as I can tell so far, is trying to bridge the gap between MIP
and the requirements for bearer service sustainment.

It is not clear to me that all three solutions are required, even though
specific
features of each solution set (MIP, FH, SeaMoby) are required. This
should become clearer once we have a better articulation of the problem
statements and the requirements.
 
*snip*

> this. In the
> cdma-2000 world, a bastardized version of Mobile IP is used 
> (called the RP
> interface). However, if such an environment needs to be 
> supported, something
> is required.

*snip*

> 2. Do we even care about a standardized protocol between the 
> AP and the FA

Yes, we do care. It is the creation of these "bastardized versions" of
IP protocols which impede the inter-operability of the various wireless
data networking solutions. We have heard CDMA2000, for example,
referred to as the "link layer". In reality, it is a network larger then 
many ASs in the wireline Internet. You can always, of course, create
interworking functions between networks, to a point. Interworking
functions create impedances between networks, the bearer service
suffers. For the most part this is mainly an issue when QoS is considered
(although there are examples where the impedance was significant enough
to hamstring even BE performance.


I hope some of this makes sense. 

Gary

=====

"What I intended you to hear is not what you think I said".

> 
> PatC
> 
> 

------_=_NextPart_001_01C07737.33254100
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] Micromobility Problem Statement ISSUE 2</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Pat Calhoun [<A HREF="mailto:Pat.Calhoun@eng.sun.com">mailto:Pat.Calhoun@eng.sun.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, January 04, 2001 8:13 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Cc: 'Phil_Neumiller@3Com.com'; seamoby@diameter.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [seamoby] Micromobility Problem Statement ISSUE 2</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

<P><FONT SIZE=2>*snip*</FONT>
</P>

<P><FONT SIZE=2>&gt; ok, so it looks like we are heading in a general direction. I </FONT>
<BR><FONT SIZE=2>&gt; do find Phil's</FONT>
<BR><FONT SIZE=2>&gt; comments most interesting, but of course we cannot, in </FONT>
<BR><FONT SIZE=2>&gt; seamoby, redo layer 1</FONT>
<BR><FONT SIZE=2>&gt; functions over IP (but perhaps someone should be looking at </FONT>
<BR><FONT SIZE=2>&gt; this). In any</FONT>
<BR><FONT SIZE=2>&gt; case, one &quot;problem&quot; with micro-mobility are the number of </FONT>
<BR><FONT SIZE=2>&gt; hops between the</FONT>
<BR><FONT SIZE=2>&gt; mobile and the mobility agent. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Mobile IP restricts the number of hops to one. So an AP, in </FONT>
</P>

<P><FONT SIZE=2>If I may, I think that the hop distance is the major issue here.</FONT>
<BR><FONT SIZE=2>Assume for the moment that for a particular function, there is</FONT>
<BR><FONT SIZE=2>a topological locus that is the optimal location for that function </FONT>
<BR><FONT SIZE=2>to be executed. Optimal in terms of performance, reliability,</FONT>
<BR><FONT SIZE=2>scalability, etc. </FONT>
</P>

<P><FONT SIZE=2>No matter how you design it, any solution that is located one or</FONT>
<BR><FONT SIZE=2>more hops away from its optimal locus will be&nbsp; less efficient. </FONT>
</P>

<P><FONT SIZE=2>To clarify: MIPs primary function (step in any time here if I've got</FONT>
<BR><FONT SIZE=2>this wrong) is inter-network mobility. As MIP is concerned with sustainment</FONT>
<BR><FONT SIZE=2>of reachability (and AAA), the main &quot;locii activity&quot; is the really the </FONT>
<BR><FONT SIZE=2>network addressing and security domain - in cellular parlance, it is a &quot;core</FONT>
<BR><FONT SIZE=2>network&quot; function. The optimal locii an HA or FA is &quot;near&quot; (at most one</FONT>
<BR><FONT SIZE=2>hop away from) the other &quot;core network functions&quot; such as AAA, policy,</FONT>
<BR><FONT SIZE=2>etc. Using MIP is a bit of a stretch, as it's function is less sensitive to</FONT>
<BR><FONT SIZE=2>degraded performance.</FONT>
</P>

<P><FONT SIZE=2>SeaMoby (micromobility, context transfer) is concerned with sustaining</FONT>
<BR><FONT SIZE=2>the bearer service provided to an MNs flows (aka: the packet level handover </FONT>
<BR><FONT SIZE=2>and microflow QoS at the edges). This goal is far more sensitive to performance</FONT>
<BR><FONT SIZE=2>degradation, and clearly suffers when distanced from the point locii of</FONT>
<BR><FONT SIZE=2>activity, namely the actual handover between access points.</FONT>
</P>

<P><FONT SIZE=2>FH, as far as I can tell so far, is trying to bridge the gap between MIP</FONT>
<BR><FONT SIZE=2>and the requirements for bearer service sustainment.</FONT>
</P>

<P><FONT SIZE=2>It is not clear to me that all three solutions are required, even though specific</FONT>
<BR><FONT SIZE=2>features of each solution set (MIP, FH, SeaMoby) are required. This</FONT>
<BR><FONT SIZE=2>should become clearer once we have a better articulation of the problem</FONT>
<BR><FONT SIZE=2>statements and the requirements.</FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>*snip*</FONT>
</P>

<P><FONT SIZE=2>&gt; this. In the</FONT>
<BR><FONT SIZE=2>&gt; cdma-2000 world, a bastardized version of Mobile IP is used </FONT>
<BR><FONT SIZE=2>&gt; (called the RP</FONT>
<BR><FONT SIZE=2>&gt; interface). However, if such an environment needs to be </FONT>
<BR><FONT SIZE=2>&gt; supported, something</FONT>
<BR><FONT SIZE=2>&gt; is required.</FONT>
</P>

<P><FONT SIZE=2>*snip*</FONT>
</P>

<P><FONT SIZE=2>&gt; 2. Do we even care about a standardized protocol between the </FONT>
<BR><FONT SIZE=2>&gt; AP and the FA</FONT>
</P>

<P><FONT SIZE=2>Yes, we do care. It is the creation of these &quot;bastardized versions&quot; of</FONT>
<BR><FONT SIZE=2>IP protocols which impede the inter-operability of the various wireless</FONT>
<BR><FONT SIZE=2>data networking solutions. We have heard CDMA2000, for example,</FONT>
<BR><FONT SIZE=2>referred to as the &quot;link layer&quot;. In reality, it is a network larger then </FONT>
<BR><FONT SIZE=2>many ASs in the wireline Internet. You can always, of course, create</FONT>
<BR><FONT SIZE=2>interworking functions between networks, to a point. Interworking</FONT>
<BR><FONT SIZE=2>functions create impedances between networks, the bearer service</FONT>
<BR><FONT SIZE=2>suffers. For the most part this is mainly an issue when QoS is considered</FONT>
<BR><FONT SIZE=2>(although there are examples where the impedance was significant enough</FONT>
<BR><FONT SIZE=2>to hamstring even BE performance.</FONT>
</P>
<BR>

<P><FONT SIZE=2>I hope some of this makes sense. </FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>=====</FONT>
</P>

<P><FONT SIZE=2>&quot;What I intended you to hear is not what you think I said&quot;.</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; PatC</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C07737.33254100--


From owner-seamoby@diameter.org  Fri Jan  5 13:43:54 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19325
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 13:43:53 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05I1fn08061
	for seamoby-list; Fri, 5 Jan 2001 10:01:41 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05I1cW08056
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 10:01:39 -0800
Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com;
          Fri, 5 Jan 2001 12:07:52 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBQC09>; Fri, 5 Jan 2001 12:07:33 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8A8E@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: seamoby_context@standards.nortelnetworks.com
Cc: "'seamoby@diameter.org'" <seamoby@diameter.org>
Subject: [seamoby] seamoby context transfer design team email list AND the first des ign 
         team conference call
Date: Fri, 5 Jan 2001 12:07:27 -0500
Sensitivity: Company-Confidential
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C07739.FB185150"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C07739.FB185150
Content-Type: text/plain;
	charset="iso-8859-1"

First, the SeaMoby Context Transfer email list appears to be up and running.
And, the addresses of all those who wished to participate in the design
team.

As the list is rather long, and there were a few transcription glitches in
entering
the addresses, I am cross posting this message to both lists. If you asked
to be
on the context transfer email list, but do not receive an email from the
list server,
notify me directly (please don't reply to the list).

Second, because time is short:

The first conference call will be on Monday, January 8, 2001, at 11am EST.
The time has been shifted one hour later.

The conference phone number is still: 905-863-6338 (North America).
The passcode has changed, it is now: 923212#. 
Don't forget the "#" sign.
The working agenda is (EST):
	11:00am - 12:05am		introductions
	11:05am - 12:35am		everyone (who wants to) gets exactly

					2 minutes to articulate a problem
statement
	11:35am - 12:30am		debate
	12:30am - 12:45am		next steps

It is getting to close to the deadline to make any changes without a very
compelling
reason.

Regards,
Gary Kenward

------_=_NextPart_001_01C07739.FB185150
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>seamoby context transfer design team email list AND the first =
design team conference call</TITLE>
</HEAD>
<BODY>

<P><B><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans =
MS">First</FONT></B><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">, =
the SeaMoby Context Transfer email list appears to be up and =
running.</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">And, the addresses =
of all those who wished to participate in the design team.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">As the list is rather =
long, and there were a few transcription glitches in entering</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">the addresses, I am =
cross posting this message to both lists. If you asked to be</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">on the context =
transfer email list, but do not receive an email from the list =
server,</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">notify me directly =
(please don't reply to the list).</FONT>
</P>

<P><B><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans =
MS">Second</FONT></B><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">, =
because time is short:</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">The first conference =
call will be on</FONT><B></B><B> <FONT COLOR=3D"#000080" SIZE=3D4 =
FACE=3D"Times New Roman">Monday, January 8, 2001, at 11am =
EST</FONT><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">.</FONT></B>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">The time has been =
shifted one hour later.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">The conference phone =
number is still:</FONT><B></B><B> <FONT SIZE=3D4 FACE=3D"Times New =
Roman">905-863-6338 (North America)</FONT></B><FONT FACE=3D"Times New =
Roman">.</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">The passcode<I> has =
changed</I>, it is now:</FONT><B></B><B> <FONT COLOR=3D"#000080" =
SIZE=3D4 FACE=3D"Times New Roman">923212#</FONT></B><FONT FACE=3D"Times =
New Roman">.</FONT><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS"><BR>
Don't forget the &quot;#&quot; sign.</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">The working agenda =
is (EST):</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#0000FF" =
FACE=3D"Comic Sans MS">11:00am - =
12:05am&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; introductions</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#0000FF" =
FACE=3D"Comic Sans MS">11:05am - =
12:35am&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; everyone (who wants to) gets =
exactly </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#0000FF" =
FACE=3D"Comic Sans MS">2 minutes to articulate a problem =
statement</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#0000FF" =
FACE=3D"Comic Sans MS">11:35am - =
12:30am&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; debate</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#0000FF" =
FACE=3D"Comic Sans MS">12:30am - =
12:45am&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; next steps</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">It is getting to =
close to the deadline to make any changes without a very =
compelling</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">reason.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">Regards,</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">Gary Kenward</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C07739.FB185150--


From owner-seamoby@diameter.org  Fri Jan  5 13:48:28 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19458
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 13:48:27 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05IRfp08127
	for seamoby-list; Fri, 5 Jan 2001 10:27:41 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05IRbW08122
	for <seamoby@cdma-2000.org>; Fri, 5 Jan 2001 10:27:37 -0800
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA16903
	for <seamoby@cdma-2000.org>; Fri, 5 Jan 2001 09:35:18 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA19411
	for <seamoby@cdma-2000.org>; Fri, 5 Jan 2001 09:35:14 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA06550
	for <seamoby@cdma-2000.org>; Fri, 5 Jan 2001 09:35:11 -0800 (PST)
Date: Fri, 5 Jan 2001 09:31:39 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: [seamoby] Thank you note
To: seamoby@cdma-2000.org
Message-ID: <Roam.SIMC.2.0.6.978715899.15042.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

I would like to Thank Phil Neumiller for his excellent work in getting seamby
(a.k.a CRAPS, an even sometimes refered to as OBAST) off the ground. We would
not be where we are today without Phil's great contributions.

Thanks Phil. I am looking forward to your stirring the pot :)

PatC



From owner-seamoby@diameter.org  Fri Jan  5 14:25:36 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20420
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 14:25:35 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05IKHM08113
	for seamoby-list; Fri, 5 Jan 2001 10:20:17 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from c007.snv.cp.net (c007-h015.c007.snv.cp.net [209.228.33.222])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f05IKDW08108
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 10:20:13 -0800
Received: (cpmta 1733 invoked from network); 5 Jan 2001 09:27:51 -0800
Received: from unknown (HELO telocity.com) (64.193.0.129)
  by smtp.telocity.com (209.228.33.222) with SMTP; 5 Jan 2001 09:27:51 -0800
X-Sent: 5 Jan 2001 17:27:51 GMT
Message-ID: <3A560487.B86EA255@telocity.com>
Date: Fri, 05 Jan 2001 11:29:43 -0600
From: Phil Neumiller <neumiller@telocity.com>
Organization: 3Com
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: seamoby@diameter.org
Subject: [seamoby] My resignation as SeaMoby co-chair
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

You may have noticed in the unformatted minutes EMail that
I sent immediately following the SeaMoby WG meeting that I
resigned as co-chair.  It seems some people were not aware of
this, so I wanted to make sure people on the list were now 
made aware of this.  My reason is (as you may have noticed)
is so that I could warm up my flame thrower again, and
put on my own asbestos long johns.  If you find you often
disagree with me, I am probably doing a good job of stirring
the pot (something I seem to excel at). :-)

Regards,

Phil Neumiller


From owner-seamoby@diameter.org  Fri Jan  5 15:40:52 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21865
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 15:40:51 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05K6Jc08298
	for seamoby-list; Fri, 5 Jan 2001 12:06:19 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05K6HW08293
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 12:06:17 -0800
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18210;
	Fri, 5 Jan 2001 11:13:50 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA16791;
	Fri, 5 Jan 2001 11:13:49 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id LAA10494;
	Fri, 5 Jan 2001 11:13:48 -0800 (PST)
Date: Fri, 5 Jan 2001 11:10:15 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [seamoby] Micromobility Problem Statement ISSUE 2
To: Ramachandran Ramjee <ramjee@dnrc.bell-labs.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        Gary Kenward <gkenward@nortelnetworks.com>,
        "'Phil_Neumiller@3Com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
In-Reply-To: "Your message with ID" <3A561B3D.FDC49CB@dnrc.bell-labs.com>
Message-ID: <Roam.SIMC.2.0.6.978721815.2318.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

> Hi Pat,
> 
> Regarding the load balancing problem you describe, it appears to me 
> that it is neither a micro-mobility or paging problem - it is a load
> balancing problem that could be resolved locally at the original FA site
> (the new AP/FA sends the message towards ONE of the old AP/FAs -
> the old FA or a director at that site forwards it to the correct
> old FA - similar in flavor to some web load balancing solutions). 
> 
> Just my thoughts...

I actually agree with this train of thought. However, doesn't the redirector
at the old FA's subnet need some similar protocol to find the FA responsible
for the mobile node? It seems that whether the new FA needs to find the
mobile, or some redirector on the old subnet, something is required.

Or am I offbase?

PatC



From owner-seamoby@diameter.org  Fri Jan  5 15:44:15 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21973
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 15:44:13 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05K2dt08289
	for seamoby-list; Fri, 5 Jan 2001 12:02:39 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f05K2KW08284
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 12:02:21 -0800
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Fri Jan  5 14:09:18 EST 2001
Received: from dnrc.bell-labs.com (IDENT:21257@ramjeepc [135.180.240.106])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA08289;
	Fri, 5 Jan 2001 14:09:14 -0500 (EST)
Message-ID: <3A561B3D.FDC49CB@dnrc.bell-labs.com>
Date: Fri, 05 Jan 2001 19:06:37 +0000
From: Ramachandran Ramjee <ramjee@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
CC: Gary Kenward <gkenward@nortelnetworks.com>,
        "'Phil_Neumiller@3Com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
Subject: Re: [seamoby] Micromobility Problem Statement ISSUE 2
References: <Roam.SIMC.2.0.6.978657178.24160.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pat,

Regarding the load balancing problem you describe, it appears to me 
that it is neither a micro-mobility or paging problem - it is a load
balancing problem that could be resolved locally at the original FA site
(the new AP/FA sends the message towards ONE of the old AP/FAs -
the old FA or a director at that site forwards it to the correct
old FA - similar in flavor to some web load balancing solutions). 

Just my thoughts...

Cheers,
Ram


Pat Calhoun wrote:
> One discussion that I brought up in the paging sublist to describe a problem
> where paging may be useful, in probably in fact a micro-mobility problem and
> not a paging one (as James Kempf pointed out).
> 
> Here is the problem:
> 
> Imagine two wireless networks, each with their own AP. Each AP has two or more
> Foreign Agents on the wired side to support the mobile nodes on the wireless
> nets. Now let's assume that a mobile is on wireless net A, and is using
> Foreign Agent X (on Net A). The mobile node moves to Net B, and the AP is
> notified of the transition. Now the AP must somehow notify the FA of the
> existence of the mobile. There is currently no protocol to do this. In the
> cdma-2000 world, a bastardized version of Mobile IP is used (called the RP
> interface). However, if such an environment needs to be supported, something
> is required.
> 
> Now, whether or not the AP acts as a bridge, or a router, using the above
> scenario, let's assume that the FA is (somehow) notified of the new mobile's
> presence, and it finds out that the mobile moved from the AP on Net A. How
> would the Foreign Agent know *which* FA supported the mobile on Net A? Looks
> like something is required there.
> 
> I suppose the following questions should be asked:
> 1. Can we safely assume that Mobile IP is used on the mobile? I would hope
> that the answer is yes, given that some mobility protocol needs to be
> designed, and I would hate to have to go through the same History the MIP WG
> went through :) if so,
> 2. Do we even care about a standardized protocol between the AP and the FA
> 3. Is a protocol required to locate the FA handling a particular mobile?
> 
> So are the above two points what Micro-mobility is all about?
> 
> PatC


From owner-seamoby@diameter.org  Fri Jan  5 16:05:38 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22522
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 16:05:37 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05KkOR08404
	for seamoby-list; Fri, 5 Jan 2001 12:46:24 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f05KkLW08399
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 12:46:21 -0800
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Fri Jan  5 14:53:29 EST 2001
Received: from dnrc.bell-labs.com (IDENT:21257@ramjeepc [135.180.240.106])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA12821;
	Fri, 5 Jan 2001 14:53:29 -0500 (EST)
Message-ID: <3A56259C.4F89368A@dnrc.bell-labs.com>
Date: Fri, 05 Jan 2001 19:50:52 +0000
From: Ramachandran Ramjee <ramjee@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
CC: Gary Kenward <gkenward@nortelnetworks.com>,
        "'Phil_Neumiller@3Com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
Subject: Re: [seamoby] Micromobility Problem Statement ISSUE 2
References: <Roam.SIMC.2.0.6.978721815.2318.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat Calhoun wrote:
> 
> > Hi Pat,
> >
> > Regarding the load balancing problem you describe, it appears to me
> > that it is neither a micro-mobility or paging problem - it is a load
> > balancing problem that could be resolved locally at the original FA site
> > (the new AP/FA sends the message towards ONE of the old AP/FAs -
> > the old FA or a director at that site forwards it to the correct
> > old FA - similar in flavor to some web load balancing solutions).
> >
> > Just my thoughts...
> 
> I actually agree with this train of thought. However, doesn't the redirector
> at the old FA's subnet need some similar protocol to find the FA responsible
> for the mobile node? It seems that whether the new FA needs to find the
> mobile, or some redirector on the old subnet, something is required.

Pat,

I think you have several questions in there..

1) The question of a redirector finding an FA out of several - a
mechanism is needed but it could be something implementation specific...
for example, an FA could be allocated based on a hash of the
mobile's HA address etc. Not convinced we need a protocol and
that too, a standardized protocol, since it is local to one FA site.

2) The question of old FA finding the mobile  - now, that I think
is a paging problem.

3) The question of new FA finding the old FA (or old redirector) - this
is needed only when the new FA gets only a L2 update and needs to 
translate it to an L3 old FA address - this is really an optimization
to avoid paging and I think it doesn't belong in seamoby.


Cheers,
Ram


From owner-seamoby@diameter.org  Fri Jan  5 16:22:02 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22999
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 16:22:00 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05Kamw08364
	for seamoby-list; Fri, 5 Jan 2001 12:36:48 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05KaiW08354
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 12:36:44 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 5 Jan 2001 14:42:55 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBQH6N>; Fri, 5 Jan 2001 14:42:56 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8A9D@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        Phil Neumiller <neumiller@telocity.com>
Cc: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>,
        "'campbell@comet.columbia.edu'" <campbell@comet.columbia.edu>,
        James Kempf <James.Kempf@eng.sun.com>, Phil_Neumiller@3Com.com,
        dblair@cisco.com, seamoby@diameter.org, cellularip@comet.columbia.edu
Subject: RE: [seamoby] Some thoughts and issues
Date: Fri, 5 Jan 2001 14:42:51 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0774F.B0D8BDD0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0774F.B0D8BDD0
Content-Type: text/plain;
	charset="iso-8859-1"

Or, MIP at the edge of the core and CIP at the edge of the access?
"Core" being one of the many heavily overloaded words.

Gary

> -----Original Message-----
> From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com]
> Sent: Thursday, January 04, 2001 10:44 PM
> To: Phil Neumiller
> Cc: Pat Calhoun; Nakhjiri Madjid-MNAKHJI1; Kenward, Gary
> [WDLN2:AN10:EXCH]; 'campbell@comet.columbia.edu'; James Kempf;
> Phil_Neumiller@3Com.com; dblair@cisco.com; seamoby@diameter.org;
> cellularip@comet.columbia.edu
> Subject: Re: [seamoby] Some thoughts and issues
> 
> 
> OOps.... I SHOULD have said Mobile IP in the core, and 
> Cellular IP at the edge.
>  sigh.
> 
> PatC
> > Pat Calhoun wrote:
> > 
> > > Perhaps, and this is, I believe, alot of what Cellular IP 
> (Mobile IP at the
> > > edges, Cellular IP in the core) was all about. I even 
> sent an e-mail today
> > > describing something similar.
> > > 
> > > PatC
> > 
> > Huh?  I seem to have this reversed, i.e. MIP at the core and
> > micro-mobility
> > at the edge, I don't seem to understand your comment.
> 
> 
> 

------_=_NextPart_001_01C0774F.B0D8BDD0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] Some thoughts and issues</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Or, MIP at the edge of the core and CIP at the edge of the access?</FONT>
<BR><FONT SIZE=2>&quot;Core&quot; being one of the many heavily overloaded words.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Pat Calhoun [<A HREF="mailto:Pat.Calhoun@eng.sun.com">mailto:Pat.Calhoun@eng.sun.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, January 04, 2001 10:44 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Phil Neumiller</FONT>
<BR><FONT SIZE=2>&gt; Cc: Pat Calhoun; Nakhjiri Madjid-MNAKHJI1; Kenward, Gary</FONT>
<BR><FONT SIZE=2>&gt; [WDLN2:AN10:EXCH]; 'campbell@comet.columbia.edu'; James Kempf;</FONT>
<BR><FONT SIZE=2>&gt; Phil_Neumiller@3Com.com; dblair@cisco.com; seamoby@diameter.org;</FONT>
<BR><FONT SIZE=2>&gt; cellularip@comet.columbia.edu</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: [seamoby] Some thoughts and issues</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; OOps.... I SHOULD have said Mobile IP in the core, and </FONT>
<BR><FONT SIZE=2>&gt; Cellular IP at the edge.</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; sigh.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; PatC</FONT>
<BR><FONT SIZE=2>&gt; &gt; Pat Calhoun wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Perhaps, and this is, I believe, alot of what Cellular IP </FONT>
<BR><FONT SIZE=2>&gt; (Mobile IP at the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; edges, Cellular IP in the core) was all about. I even </FONT>
<BR><FONT SIZE=2>&gt; sent an e-mail today</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; describing something similar.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; PatC</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Huh?&nbsp; I seem to have this reversed, i.e. MIP at the core and</FONT>
<BR><FONT SIZE=2>&gt; &gt; micro-mobility</FONT>
<BR><FONT SIZE=2>&gt; &gt; at the edge, I don't seem to understand your comment.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0774F.B0D8BDD0--


From owner-seamoby@diameter.org  Fri Jan  5 16:22:18 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23025
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 16:22:17 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05KeDZ08388
	for seamoby-list; Fri, 5 Jan 2001 12:40:13 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05KeBW08383
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 12:40:11 -0800
Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com;
          Fri, 5 Jan 2001 14:46:37 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBQH0C>; Fri, 5 Jan 2001 14:46:38 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8A9E@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>,
        "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        Kulwinder Atwal <kulwinder.atwal@herc.zucotto.com>
Cc: "'Phil_Neumiller@3Com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
Subject: RE: [seamoby] Micromobility Problem Statement ISSUE 2
Date: Fri, 5 Jan 2001 14:46:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C07750.3591CAD0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C07750.3591CAD0
Content-Type: text/plain;
	charset="iso-8859-1"

*snip*
> 
> I think so.  I think we have three cases at least.
> 
> Pro-active hand off:
> 
> Old AP knows the hand off is about to occur and notifies the 
> new AP through
> wired side.
> 
> Reative hand off:
> 
> The mobile finds it has crossed over, possibly after a communications
> problem  (interference, etc.).  Sends last known AP address 
> to new AP.  New
> AP looks up old AP address and finds old AP IP address on 
> wired side.  Sends
> message to old AP on wired side.
> 
> Dormant hand off:
> 
> Cannot be seamless.  Mobile wakes up and sends last known AP 
> address to new
> AP.  New AP looks up the old AP IP address on the wired net and sends
> message to old AP over wired link.
> 
> How's that?

A good start, at the least.

Question: do FAs support proactive handoff? should they?
If they did, would paging be needed? Or is the answer to
the latter question that we have to account for the less
optimal, non-proactive scenarios?

Gary
> 
> - Kulwinder.
> 
> > > 3. Is a protocol required to locate the FA handling a 
> > > > particular mobile?
> > > 
> > > Maybe, I am missing something here.  But if the mobile is 
> > made responsible 
> > > for its own movement, by requiring to:
> > > 
> > > 1. Stay active if it wants real-time flows. 
> > > 
> > > 2. Periodically transmit between dormant periods and 
> > re-associate with an
> > > AP, if it wants to recieve a message.
> > > 
> > > 3. Go completely dormant if it does not want to recieve a message.
> > > 
> > > 4. Store the last AP/FA address and furnish it to the new 
> > AP, so it can
> > > avoid the need for FA paging.
> > > 
> > > The problem I have with paging is its scalability.  What 
> > bounds are we
> > > placing on how far a mobile can drift?   
> > > 
> > > Can the mobile do the ridiculous? Locate the other side of 
> > the planet and
> > > cause a planet-wide page?  How many kWatts are we allowing 
> > the network to
> > > expend to allow the mobile to save a few microWatts?  I 
> > think there needs to
> > > be reasonable cap on how much network resources a mobile 
> > can consume.
> > > 
> > > ???
> > > 
> > > Maybe, by saying "micro-mobility" the paging area is a 
> > sub-metro area.  But,
> > > to ensure that, we need a time limit on how long the mobile 
> > can be dormant.
> > > Which means the solution to the paging problem is 2 + 4 above.
> > > 
> > > - Kulwinder.
> > > 
> > > > 
> > > > So are the above two points what Micro-mobility is all about?
> > > > 
> > > > PatC
> > > > 
> > 
> > 
> > 
> 

------_=_NextPart_001_01C07750.3591CAD0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] Micromobility Problem Statement ISSUE 2</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>*snip*</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I think so.&nbsp; I think we have three cases at least.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Pro-active hand off:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Old AP knows the hand off is about to occur and notifies the </FONT>
<BR><FONT SIZE=2>&gt; new AP through</FONT>
<BR><FONT SIZE=2>&gt; wired side.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Reative hand off:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The mobile finds it has crossed over, possibly after a communications</FONT>
<BR><FONT SIZE=2>&gt; problem&nbsp; (interference, etc.).&nbsp; Sends last known AP address </FONT>
<BR><FONT SIZE=2>&gt; to new AP.&nbsp; New</FONT>
<BR><FONT SIZE=2>&gt; AP looks up old AP address and finds old AP IP address on </FONT>
<BR><FONT SIZE=2>&gt; wired side.&nbsp; Sends</FONT>
<BR><FONT SIZE=2>&gt; message to old AP on wired side.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Dormant hand off:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Cannot be seamless.&nbsp; Mobile wakes up and sends last known AP </FONT>
<BR><FONT SIZE=2>&gt; address to new</FONT>
<BR><FONT SIZE=2>&gt; AP.&nbsp; New AP looks up the old AP IP address on the wired net and sends</FONT>
<BR><FONT SIZE=2>&gt; message to old AP over wired link.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; How's that?</FONT>
</P>

<P><FONT SIZE=2>A good start, at the least.</FONT>
</P>

<P><FONT SIZE=2>Question: do FAs support proactive handoff? should they?</FONT>
<BR><FONT SIZE=2>If they did, would paging be needed? Or is the answer to</FONT>
<BR><FONT SIZE=2>the latter question that we have to account for the less</FONT>
<BR><FONT SIZE=2>optimal, non-proactive scenarios?</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; - Kulwinder.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; 3. Is a protocol required to locate the FA handling a </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; particular mobile?</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Maybe, I am missing something here.&nbsp; But if the mobile is </FONT>
<BR><FONT SIZE=2>&gt; &gt; made responsible </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; for its own movement, by requiring to:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; 1. Stay active if it wants real-time flows. </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; 2. Periodically transmit between dormant periods and </FONT>
<BR><FONT SIZE=2>&gt; &gt; re-associate with an</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; AP, if it wants to recieve a message.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; 3. Go completely dormant if it does not want to recieve a message.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; 4. Store the last AP/FA address and furnish it to the new </FONT>
<BR><FONT SIZE=2>&gt; &gt; AP, so it can</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; avoid the need for FA paging.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; The problem I have with paging is its scalability.&nbsp; What </FONT>
<BR><FONT SIZE=2>&gt; &gt; bounds are we</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; placing on how far a mobile can drift?&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Can the mobile do the ridiculous? Locate the other side of </FONT>
<BR><FONT SIZE=2>&gt; &gt; the planet and</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; cause a planet-wide page?&nbsp; How many kWatts are we allowing </FONT>
<BR><FONT SIZE=2>&gt; &gt; the network to</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; expend to allow the mobile to save a few microWatts?&nbsp; I </FONT>
<BR><FONT SIZE=2>&gt; &gt; think there needs to</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; be reasonable cap on how much network resources a mobile </FONT>
<BR><FONT SIZE=2>&gt; &gt; can consume.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; ???</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Maybe, by saying &quot;micro-mobility&quot; the paging area is a </FONT>
<BR><FONT SIZE=2>&gt; &gt; sub-metro area.&nbsp; But,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; to ensure that, we need a time limit on how long the mobile </FONT>
<BR><FONT SIZE=2>&gt; &gt; can be dormant.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Which means the solution to the paging problem is 2 + 4 above.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; - Kulwinder.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; So are the above two points what Micro-mobility is all about?</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; PatC</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C07750.3591CAD0--


From owner-seamoby@diameter.org  Fri Jan  5 16:22:48 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23051
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 16:22:48 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05KaP808349
	for seamoby-list; Fri, 5 Jan 2001 12:36:25 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05KaMW08344
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 12:36:22 -0800
Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com;
          Fri, 5 Jan 2001 14:40:22 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBQHWK>; Fri, 5 Jan 2001 14:38:33 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8A9B@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Phil Neumiller'" <neumiller@telocity.com>
Cc: "'Michael Thomas'" <mat@cisco.com>,
        "'Phil_Neumiller@3com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
Subject: RE: Deconstructing Cellular WAS -> Re: [seamoby] Micromobility Pr 
         oblem Statement
Date: Fri, 5 Jan 2001 14:38:31 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0774F.155A6020"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0774F.155A6020
Content-Type: text/plain;
	charset="iso-8859-1"

I agree with you.
But you are making socio-economic arguments for future market evolution.
Spectrum remains scarce.

Let's take this off the list if you want to continue. I can sense Pat about
to
put on his wg chair hat...

Gary

> -----Original Message-----
> From: Phil Neumiller [mailto:neumiller@telocity.com]
> Sent: Thursday, January 04, 2001 8:29 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Michael Thomas'; 'Phil_Neumiller@3com.com'; seamoby@diameter.org
> Subject: Deconstructing Cellular WAS -> Re: [seamoby] Micromobility
> Problem Statement
> 
> 
> See my <rebuttal></rebuttal> below.
> 
> \> Gary Kenward wrote:
> > 
> > <flop>
> > 
> > Or DisneyWorld
> > 
> > </flow>
> > 
> > > -----Original Message-----
> > > From: Michael Thomas [mailto:mat@cisco.com]
> > >
> > > Gary Kenward writes:
> > >  > Who is going to build these 802.11a networks and provide
> > > them to users
> > >  > for free?
> > >
> > > <flip>
> > >
> > > Supermarkets looking for a 2k version of Green Stamps?
> > >
> > > </flip>
> > >
> > >               Mike, not entirely flippant
> > >
> <rebuttal>
> It certainly wont be the carriers that paid exorbitant prices for 
> 3G spectrum from a variety of world governments.  Tell me please,
> does it make sense to have a 2 Mbps (you can only hope) link to
> cell sites several kilometers away?  Meanwhile entrepreneurs that
> grock the opportunity gap, will be deploying better, faster, and
> cheaper pay-for services on 802.11a etc.  Who will win the race for
> profit margins?  I think its obvious but time will tell.  The 3G
> folks are going to be saddled with a minutes-of-use model to recoup
> that BIG spectrum expenditure while the local wireless crowd will
> be able to re-invest into QoS, AAA, SeaMoby!, etc., while offering
> relatively FREE access to the BIG I.  Most people are in and
> around building/infrastructer when they NEED high speed access 
> (some automobile scenarios are the exception), so local wireless
> can clearly steal outright the majority of broadband wireless
> customers from cellular.  Light pipes to access points is the 
> future whether you folks living in the cellular world dillusion 
> want to admit or not.  It all makes sense economically so it is
> bound to happen.  It will be unsuspected players deploying the
> infrastructure introducing an element of innovation and competition
> into wireless that has been lost since cellular became the end-all
> solution, then again it could just be Cisco and 3Com afterall...
> </rebuttal>
> 

------_=_NextPart_001_01C0774F.155A6020
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Deconstructing Cellular WAS -&gt; Re: [seamoby] =
Micromobility Problem  Statement</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I agree with you.</FONT>
<BR><FONT SIZE=3D2>But you are making socio-economic arguments for =
future market evolution.</FONT>
<BR><FONT SIZE=3D2>Spectrum remains scarce.</FONT>
</P>

<P><FONT SIZE=3D2>Let's take this off the list if you want to continue. =
I can sense Pat about to</FONT>
<BR><FONT SIZE=3D2>put on his wg chair hat...</FONT>
</P>

<P><FONT SIZE=3D2>Gary</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Phil Neumiller [<A =
HREF=3D"mailto:neumiller@telocity.com">mailto:neumiller@telocity.com</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, January 04, 2001 8:29 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'Michael Thomas'; =
'Phil_Neumiller@3com.com'; seamoby@diameter.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Deconstructing Cellular WAS -&gt; Re: =
[seamoby] Micromobility</FONT>
<BR><FONT SIZE=3D2>&gt; Problem Statement</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; See my &lt;rebuttal&gt;&lt;/rebuttal&gt; =
below.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; \&gt; Gary Kenward wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &lt;flop&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Or DisneyWorld</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &lt;/flow&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; From: Michael Thomas [<A =
HREF=3D"mailto:mat@cisco.com">mailto:mat@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Gary Kenward writes:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; &gt; Who is going to build =
these 802.11a networks and provide</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; them to users</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; &gt; for free?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &lt;flip&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Supermarkets looking for a 2k version =
of Green Stamps?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &lt;/flip&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; Mike, not entirely flippant</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &lt;rebuttal&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; It certainly wont be the carriers that paid =
exorbitant prices for </FONT>
<BR><FONT SIZE=3D2>&gt; 3G spectrum from a variety of world =
governments.&nbsp; Tell me please,</FONT>
<BR><FONT SIZE=3D2>&gt; does it make sense to have a 2 Mbps (you can =
only hope) link to</FONT>
<BR><FONT SIZE=3D2>&gt; cell sites several kilometers away?&nbsp; =
Meanwhile entrepreneurs that</FONT>
<BR><FONT SIZE=3D2>&gt; grock the opportunity gap, will be deploying =
better, faster, and</FONT>
<BR><FONT SIZE=3D2>&gt; cheaper pay-for services on 802.11a etc.&nbsp; =
Who will win the race for</FONT>
<BR><FONT SIZE=3D2>&gt; profit margins?&nbsp; I think its obvious but =
time will tell.&nbsp; The 3G</FONT>
<BR><FONT SIZE=3D2>&gt; folks are going to be saddled with a =
minutes-of-use model to recoup</FONT>
<BR><FONT SIZE=3D2>&gt; that BIG spectrum expenditure while the local =
wireless crowd will</FONT>
<BR><FONT SIZE=3D2>&gt; be able to re-invest into QoS, AAA, SeaMoby!, =
etc., while offering</FONT>
<BR><FONT SIZE=3D2>&gt; relatively FREE access to the BIG I.&nbsp; Most =
people are in and</FONT>
<BR><FONT SIZE=3D2>&gt; around building/infrastructer when they NEED =
high speed access </FONT>
<BR><FONT SIZE=3D2>&gt; (some automobile scenarios are the exception), =
so local wireless</FONT>
<BR><FONT SIZE=3D2>&gt; can clearly steal outright the majority of =
broadband wireless</FONT>
<BR><FONT SIZE=3D2>&gt; customers from cellular.&nbsp; Light pipes to =
access points is the </FONT>
<BR><FONT SIZE=3D2>&gt; future whether you folks living in the cellular =
world dillusion </FONT>
<BR><FONT SIZE=3D2>&gt; want to admit or not.&nbsp; It all makes sense =
economically so it is</FONT>
<BR><FONT SIZE=3D2>&gt; bound to happen.&nbsp; It will be unsuspected =
players deploying the</FONT>
<BR><FONT SIZE=3D2>&gt; infrastructure introducing an element of =
innovation and competition</FONT>
<BR><FONT SIZE=3D2>&gt; into wireless that has been lost since cellular =
became the end-all</FONT>
<BR><FONT SIZE=3D2>&gt; solution, then again it could just be Cisco and =
3Com afterall...</FONT>
<BR><FONT SIZE=3D2>&gt; &lt;/rebuttal&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0774F.155A6020--


From owner-seamoby@diameter.org  Fri Jan  5 16:32:09 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23251
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 16:32:09 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05Kaor08365
	for seamoby-list; Fri, 5 Jan 2001 12:36:50 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05KajW08357
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 12:36:45 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 5 Jan 2001 14:41:19 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBQHZP>; Fri, 5 Jan 2001 14:41:21 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8A9C@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Phil Neumiller'" <neumiller@telocity.com>,
        Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>,
        "'campbell@comet.columbia.edu'" <campbell@comet.columbia.edu>,
        James Kempf <James.Kempf@eng.sun.com>, Phil_Neumiller@3Com.com,
        dblair@cisco.com, seamoby@diameter.org, cellularip@comet.columbia.edu
Subject: RE: [seamoby] Some thoughts and issues
Date: Fri, 5 Jan 2001 14:41:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0774F.765E57F0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0774F.765E57F0
Content-Type: text/plain;
	charset="iso-8859-1"

We still seem to be having a hard time defining what micro-mobility is in
the SeaMoby sense. Dare I ask what "micromobility in the classic sense"
means?

Gary

> -----Original Message-----
> From: Phil Neumiller [mailto:neumiller@telocity.com]
> Sent: Thursday, January 04, 2001 9:25 PM
> To: Pat Calhoun
> Cc: Nakhjiri Madjid-MNAKHJI1; Kenward, Gary [WDLN2:AN10:EXCH];
> 'campbell@comet.columbia.edu'; James Kempf; Phil_Neumiller@3Com.com;
> dblair@cisco.com; seamoby@diameter.org; cellularip@comet.columbia.edu
> Subject: Re: [seamoby] Some thoughts and issues
> 
> 
> Bizzare comments below...
> 
> Pat Calhoun wrote:
> > 
> > > Sorry for the really late reply. I am catching up with 
> the email. I agree
> > > with Gary here. Having a trigger for context transfer and 
> the actual context
> > > transfer are two different things. I thought one of the 
> issues that we are
> > > trying to solve in Seamoby was micromobility or handover 
> while CoA does not
> > > change, a problem that MIP does not deal with, so why are 
> mentioning mobile
> > > IP handoff solutions. Furthormore, as far as I know 
> (maybe this info needs
> > > to updated) fast handoff drafts do not address or provide 
> a solution for the
> > > context transfer problem.
> > >
> > I believe that Raj's point was more along the lines that it 
> is possible to
> > re-use Mobile IP messages to "transport" opaque context 
> information during a
> > handoff. Now, I believe that we really do care about Mobile 
> IP, because it
> > DOES provide fast handoff without requiring a CoA change. Now, the
> > micro-mobility folks (whose list was just setup and will be 
> announced
> > shortly), need to specify what problem exists that Mobile 
> IP does not. This is
> > something that the IESG folks are really interested in 
> hearing, so we owe it
> > to them.
> > =
> Pat,
> 
> Micro-mobility in the "classical" sense does not equal SeaMoby
> micro-mobility
> in my mind.  We are discussing inter-domain context transfer, 
> as such we
> may
> in fact be wanting to extend existing MIP messages, etc.  Here goes a
> REALLY
> wacko idea... Since you yourself said that the fast handover 
> solutions 
> live on the edge wouldn't the more prudent division of labor 
> be between
> core (current MIP stuff) and edge (future seamoby stuff) 
> mobility???  If
> this
> COULD be agreed upon, then FAST handover (that piggy backs context
> transfer) 
> moves to the edge mobility WG (formerly known as SeaMoby).  
> OK, maybe I
> am
> suggesting something totally wacked here...
> 
> Thanks,
> 
> Phil
> 

------_=_NextPart_001_01C0774F.765E57F0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] Some thoughts and issues</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>We still seem to be having a hard time defining what micro-mobility is in</FONT>
<BR><FONT SIZE=2>the SeaMoby sense. Dare I ask what &quot;micromobility in the classic sense&quot;</FONT>
<BR><FONT SIZE=2>means?</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Phil Neumiller [<A HREF="mailto:neumiller@telocity.com">mailto:neumiller@telocity.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, January 04, 2001 9:25 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Pat Calhoun</FONT>
<BR><FONT SIZE=2>&gt; Cc: Nakhjiri Madjid-MNAKHJI1; Kenward, Gary [WDLN2:AN10:EXCH];</FONT>
<BR><FONT SIZE=2>&gt; 'campbell@comet.columbia.edu'; James Kempf; Phil_Neumiller@3Com.com;</FONT>
<BR><FONT SIZE=2>&gt; dblair@cisco.com; seamoby@diameter.org; cellularip@comet.columbia.edu</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: [seamoby] Some thoughts and issues</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Bizzare comments below...</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Pat Calhoun wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Sorry for the really late reply. I am catching up with </FONT>
<BR><FONT SIZE=2>&gt; the email. I agree</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; with Gary here. Having a trigger for context transfer and </FONT>
<BR><FONT SIZE=2>&gt; the actual context</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; transfer are two different things. I thought one of the </FONT>
<BR><FONT SIZE=2>&gt; issues that we are</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; trying to solve in Seamoby was micromobility or handover </FONT>
<BR><FONT SIZE=2>&gt; while CoA does not</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; change, a problem that MIP does not deal with, so why are </FONT>
<BR><FONT SIZE=2>&gt; mentioning mobile</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; IP handoff solutions. Furthormore, as far as I know </FONT>
<BR><FONT SIZE=2>&gt; (maybe this info needs</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; to updated) fast handoff drafts do not address or provide </FONT>
<BR><FONT SIZE=2>&gt; a solution for the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; context transfer problem.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; I believe that Raj's point was more along the lines that it </FONT>
<BR><FONT SIZE=2>&gt; is possible to</FONT>
<BR><FONT SIZE=2>&gt; &gt; re-use Mobile IP messages to &quot;transport&quot; opaque context </FONT>
<BR><FONT SIZE=2>&gt; information during a</FONT>
<BR><FONT SIZE=2>&gt; &gt; handoff. Now, I believe that we really do care about Mobile </FONT>
<BR><FONT SIZE=2>&gt; IP, because it</FONT>
<BR><FONT SIZE=2>&gt; &gt; DOES provide fast handoff without requiring a CoA change. Now, the</FONT>
<BR><FONT SIZE=2>&gt; &gt; micro-mobility folks (whose list was just setup and will be </FONT>
<BR><FONT SIZE=2>&gt; announced</FONT>
<BR><FONT SIZE=2>&gt; &gt; shortly), need to specify what problem exists that Mobile </FONT>
<BR><FONT SIZE=2>&gt; IP does not. This is</FONT>
<BR><FONT SIZE=2>&gt; &gt; something that the IESG folks are really interested in </FONT>
<BR><FONT SIZE=2>&gt; hearing, so we owe it</FONT>
<BR><FONT SIZE=2>&gt; &gt; to them.</FONT>
<BR><FONT SIZE=2>&gt; &gt; =</FONT>
<BR><FONT SIZE=2>&gt; Pat,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Micro-mobility in the &quot;classical&quot; sense does not equal SeaMoby</FONT>
<BR><FONT SIZE=2>&gt; micro-mobility</FONT>
<BR><FONT SIZE=2>&gt; in my mind.&nbsp; We are discussing inter-domain context transfer, </FONT>
<BR><FONT SIZE=2>&gt; as such we</FONT>
<BR><FONT SIZE=2>&gt; may</FONT>
<BR><FONT SIZE=2>&gt; in fact be wanting to extend existing MIP messages, etc.&nbsp; Here goes a</FONT>
<BR><FONT SIZE=2>&gt; REALLY</FONT>
<BR><FONT SIZE=2>&gt; wacko idea... Since you yourself said that the fast handover </FONT>
<BR><FONT SIZE=2>&gt; solutions </FONT>
<BR><FONT SIZE=2>&gt; live on the edge wouldn't the more prudent division of labor </FONT>
<BR><FONT SIZE=2>&gt; be between</FONT>
<BR><FONT SIZE=2>&gt; core (current MIP stuff) and edge (future seamoby stuff) </FONT>
<BR><FONT SIZE=2>&gt; mobility???&nbsp; If</FONT>
<BR><FONT SIZE=2>&gt; this</FONT>
<BR><FONT SIZE=2>&gt; COULD be agreed upon, then FAST handover (that piggy backs context</FONT>
<BR><FONT SIZE=2>&gt; transfer) </FONT>
<BR><FONT SIZE=2>&gt; moves to the edge mobility WG (formerly known as SeaMoby).&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; OK, maybe I</FONT>
<BR><FONT SIZE=2>&gt; am</FONT>
<BR><FONT SIZE=2>&gt; suggesting something totally wacked here...</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thanks,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Phil</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0774F.765E57F0--


From owner-seamoby@diameter.org  Fri Jan  5 16:49:34 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23770
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 16:49:34 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05L9S608470
	for seamoby-list; Fri, 5 Jan 2001 13:09:28 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (flipper.cisco.com [171.69.25.141])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05L9QW08465
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 13:09:26 -0800
Received: from dblair-pc (dhcp-atlanta-220-52.cisco.com [161.44.220.52])
	by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id MAA24541;
	Fri, 5 Jan 2001 12:16:56 -0800 (PST)
Message-Id: <4.1.20010105145937.0473b100@flipper.cisco.com>
X-Sender: dblair@flipper.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 05 Jan 2001 15:13:52 -0500
To: seamoby-mm@cdma-2000.org, seamoby@diameter.org
From: "Dana L. Blair" <dblair@cisco.com>
Subject: [seamoby] SEAMOBY Micromobility Design alias
Cc: dblair@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-seamoby@diameter.org
Precedence: bulk

The design team alias for the Micromobility discussion is seamoby-mm@cdma-2000.org

The list of team members that I had a few days after the IETF ended.

Phil_Neumiller@3com.com
john.loughney@nokia.com
lsalgarelli@bell-labs.com
a.ross@ieee.org
kulwinder.atwal@zucotto.com
t.pagtzis@cs.ucl.ac.uk
over@ees2.oulu.fi
chuah@hoserve.ho.lucent.com
dblair@cisco.com
henrik.levkowetz@abrandnewworld.se
campbell@comet.columbia.edu
charliep@iprg.nokia.com
Ron.Akers@motorola.com

These people have already been added to the alias and should get this email from
both the seamoby general list and micromobility list.  I realize that others have asked
to be added to the design team.  If you are not listed above please subscribe to the
alias, seamoby-mm@cdma-2000.org.

One can register by sending a message to
seamoby-mm-request@cdma-2000.org with the body that includes "subscribe
[e-mail address]" (without quotes, of course).

I'll repost my original problem statement to the alias later today after folks have had
time to subscribe and I have had time to filter through some of the micromobility problem
statement discussion on the alias.  Anyone else with a problem statement may post it to the
alias as well.

thanks,
Dana






From owner-seamoby@diameter.org  Fri Jan  5 16:49:59 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23793
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 16:49:58 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05L1tN08444
	for seamoby-list; Fri, 5 Jan 2001 13:01:55 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05L1rW08439
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 13:01:53 -0800
Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com;
          Fri, 5 Jan 2001 15:06:57 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBQ2WQ>; Fri, 5 Jan 2001 15:06:59 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8AA2@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: seamoby_context@standards.nortelnetworks.com
Cc: "'seamoby@diameter.org'" <seamoby@diameter.org>
Subject: [seamoby] FW: seamoby context transfer design team email list AND the first 
         design team conference call
Date: Fri, 5 Jan 2001 15:06:54 -0500
Sensitivity: Company-Confidential
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C07753.0CF35B40"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C07753.0CF35B40
Content-Type: text/plain;
	charset="iso-8859-1"


> The first conference call will be on Monday, January 8, 2001, 
> at 11am EST.
> The time has been shifted one hour later.
> 
> The conference phone number is still: 905-863-6338 (North America).
> The passcode has changed, it is now: 923212#. 
> Don't forget the "#" sign.
> The working agenda is (EST):
> 	11:00am - 12:05am		introductions
> 	11:05am - 12:35am		everyone (who wants to) 
> gets exactly 
> 					2 minutes to articulate 
> a problem statement
> 	11:35am - 12:30am		debate
> 	12:30am - 12:45am		next steps
> 

Not that it wasn't obvious, but I messed up my typing again. The
agenda should read:

 	11:00am - 11:05am		introductions
 	11:05am - 11:35am		everyone (who wants to) gets exactly

 					2 minutes to articulate  a problem
statement
 	11:35am - 12:30am		debate
 	12:30am - 13:00am		next steps

Now I obviously must make an appointment with an optometrist.
Gary

------_=_NextPart_001_01C07753.0CF35B40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>FW: seamoby context transfer design team email list AND the =
first design team conference call</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">&gt; The first =
conference call will be on</FONT><B></B><B> <FONT COLOR=3D"#000080" =
SIZE=3D4 FACE=3D"Times New Roman">Monday, January 8, 2001, </FONT></B>
<BR><B><FONT COLOR=3D"#000080" SIZE=3D4 FACE=3D"Times New Roman">&gt; =
at 11am EST</FONT><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans =
MS">.</FONT></B>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">&gt; The time has =
been shifted one hour later.</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">&gt; </FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">&gt; The conference =
phone number is still:</FONT><B></B><B> <FONT SIZE=3D4 FACE=3D"Times =
New Roman">905-863-6338 (North America)</FONT></B><FONT FACE=3D"Times =
New Roman">.</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">&gt; The passcode<I> =
has changed</I>, it is now:</FONT><B></B><B> <FONT COLOR=3D"#000080" =
SIZE=3D4 FACE=3D"Times New Roman">923212#</FONT></B><FONT FACE=3D"Times =
New Roman">.</FONT><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS"><BR>
&gt; Don't forget the &quot;#&quot; sign.</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">&gt; The working =
agenda is (EST):</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 11:00am - =
12:05am&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; introductions</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 11:05am - =
12:35am&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; everyone (who wants to) =
</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">&gt; gets exactly =
</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2 minutes to articulate =
</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">&gt; a problem =
statement</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 11:35am - =
12:30am&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; debate</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12:30am - =
12:45am&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; next steps</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">&gt; </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">Not that it wasn't =
obvious, but I messed up my typing again. The</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">agenda should =
read:</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans =
MS">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 11:00am - =
11:05am&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; introductions</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans =
MS">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 11:05am - =
11:35am&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; everyone (who wants to) gets =
exactly </FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans =
MS">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2 minutes to =
articulate&nbsp; a problem statement</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans =
MS">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 11:35am - =
12:30am&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; debate</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans =
MS">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12:30am - =
13:00am&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; next steps</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">Now I obviously must =
make an appointment with an optometrist.</FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Comic Sans MS">Gary</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C07753.0CF35B40--


From owner-seamoby@diameter.org  Fri Jan  5 18:05:10 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25164
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 18:05:08 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05MI2r08602
	for seamoby-list; Fri, 5 Jan 2001 14:18:02 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05MHwW08597
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 14:17:59 -0800
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06499;
	Fri, 5 Jan 2001 13:25:31 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA19680;
	Fri, 5 Jan 2001 13:25:31 -0800 (PST)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA14794;
	Fri, 5 Jan 2001 13:25:30 -0800 (PST)
Message-Id: <200101052125.NAA14794@nasnfs.eng.sun.com>
Date: Fri, 5 Jan 2001 13:25:47 -0800 (PST)
From: James Kempf <James.Kempf@eng.sun.com>
Reply-To: James Kempf <James.Kempf@eng.sun.com>
Subject: RE: [seamoby] Some thoughts and issues
To: neumiller@telocity.com, Pat.Calhoun@eng.sun.com,
        gkenward@nortelnetworks.com
Cc: Madjid.Nakhjiri@motorola.com, campbell@comet.columbia.edu,
        James.Kempf@eng.sun.com, Phil_Neumiller@3Com.com, dblair@cisco.com,
        seamoby@diameter.org, cellularip@comet.columbia.edu
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 2Xk+7PxD+yVSMSSRXUktGg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Gary,

>We still seem to be having a hard time defining what micro-mobility is in
>the SeaMoby sense. Dare I ask what "micromobility in the classic sense"
>means?
>

This probably isn't going to help much, but we've defined micromobility
in MWIF as mobility within a radio access network, and macromobility
as between radio access networks.

		jak



From owner-seamoby@diameter.org  Fri Jan  5 18:06:57 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25191
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 18:06:57 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05MQba08645
	for seamoby-list; Fri, 5 Jan 2001 14:26:37 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from prserv.net (out1.prserv.net [32.97.166.31])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05MQZW08640
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 14:26:35 -0800
Received: from [32.101.227.10] ([32.101.227.10])
          by prserv.net (out1) with ESMTP
          id <2001010521341120100gs6hbe>; Fri, 5 Jan 2001 21:34:12 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: ahmrphd@pop3.attglobal.net (Unverified)
Message-Id: <v04011700b67bec839729@[129.37.42.236]>
Date: Fri, 5 Jan 2001 13:29:20 -0800
To: Phil Neumiller <neumiller@telocity.com>,
        Gary Kenward <gkenward@nortelnetworks.com>
From: Arthur Ross <a.ross@ieee.org>
Subject: Re: Deconstructing Cellular WAS -> Re: [seamoby] Micromobility
 Problem   Statement
Cc: "'Michael Thomas'" <mat@cisco.com>, seamoby@diameter.org
Sender: owner-seamoby@diameter.org
Precedence: bulk

Apologies for the overly-large attachment. It's now available on

http://www.fastq.com/~ahmrphd/

   -- A

   Dr. Arthur H. M. Ross
   1004 Cottage Way
   Encinitas, CA 92024



From owner-seamoby@diameter.org  Fri Jan  5 18:30:03 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25429
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 18:30:03 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05Mmev08734
	for seamoby-list; Fri, 5 Jan 2001 14:48:40 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (witbier.cisco.com [171.71.152.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05MmcW08729
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 14:48:38 -0800
Received: from Ramalho-Family (sjc-vpn-90.cisco.com [10.21.64.90])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id NAA01450;
	Fri, 5 Jan 2001 13:55:29 -0800 (PST)
Message-Id: <4.1.20010105163743.00a605b0@witbier.cisco.com>
X-Sender: mramalho@witbier.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 05 Jan 2001 16:57:40 -0500
To: James Kempf <James.Kempf@eng.sun.com>, neumiller@telocity.com,
        Pat.Calhoun@eng.sun.com, gkenward@nortelnetworks.com
From: "Michael A. Ramalho" <mramalho@cisco.com>
Subject: RE: [seamoby] Some thoughts and issues
Cc: Madjid.Nakhjiri@motorola.com, campbell@comet.columbia.edu,
        James.Kempf@eng.sun.com, Phil_Neumiller@3Com.com, dblair@cisco.com,
        seamoby@diameter.org, cellularip@comet.columbia.edu
In-Reply-To: <200101052125.NAA14794@nasnfs.eng.sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-seamoby@diameter.org
Precedence: bulk

At 01:25 PM 1/5/01 -0800, James Kempf wrote:
>Gary,
>
>>We still seem to be having a hard time defining what micro-mobility is in
>>the SeaMoby sense. Dare I ask what "micromobility in the classic sense"
>>means?
>>
>
>This probably isn't going to help much, but we've defined micromobility
>in MWIF as mobility within a radio access network, and macromobility
>as between radio access networks.
>
>		jak
>

I think you are right. That definition might be OK for MWIF ... but ...
what would you call a "radio access network" outside of that context?

For example ... lets say I have an enterprise router with two types of radio
system access links on it ... and my mobile decides to request a handoff
between one wireless access link technology to the other ... but stays
connected to the same router.

Would that handoff ... probably within one subnet ... but between two different
types of radio access links ... be considered macromobility?

That would be odd, indeed!

I think IP-oriented people think of (micro)mobility w.r.t. subnets (or trust
boundaries or administrative domains) without regard for the actual technology
used on the access link. Conversely, cellular folks usually think of
(macro)mobility
between types of "radio access networks".

So what is our "[micro|macro]mobility" based on ... mobility between "networks"
or between IP "domains/subsets/domains/clouds"?

If we are talking IP mobility ... I'd suggest the latter ... but if I were
a cellular IP guy ... I'd probably argue the former.

This is why we need that problem definition .....


Michael A. Ramalho, Ph.D.
Office email: mramalho@cisco.com
Personal email: mar42@cornell.edu
Office: +1.732.449.5762
Cell: +1.732.809.0188
Pager: +1.800.365.4578


From owner-seamoby@diameter.org  Fri Jan  5 18:30:23 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25445
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 18:30:23 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05MwEK08767
	for seamoby-list; Fri, 5 Jan 2001 14:58:14 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05MwCW08761
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 14:58:12 -0800
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id OAA09611;
	Fri, 5 Jan 2001 14:04:36 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA20995; Fri, 5 Jan 2001 14:04:36 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14934.17652.2262.629258@thomasm-u1.cisco.com>
Date: Fri, 5 Jan 2001 14:04:35 -0800 (PST)
To: James Kempf <James.Kempf@eng.sun.com>
Cc: neumiller@telocity.com, Pat.Calhoun@eng.sun.com,
        gkenward@nortelnetworks.com, dblair@cisco.com,
        Madjid.Nakhjiri@motorola.com, campbell@comet.columbia.edu,
        Phil_Neumiller@3Com.com, seamoby@diameter.org,
        cellularip@comet.columbia.edu, seamoby-mm@cdma-2000.org
Subject: RE: [seamoby] Some thoughts and issues
In-Reply-To: <200101052154.NAA15777@nasnfs.eng.sun.com>
References: <200101052154.NAA15777@nasnfs.eng.sun.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

James Kempf writes:
 > Dana,
 > 
 > The question is whether it changes subnet when it moves
 > or not?

   I think we need to consider both cases. Not
   changing subnets (really, the mobile not changing
   its CoA) sounds like it will produce a lot less
   signaling in many cases. This is particularly 
   true if the AR terminates many AP's such that
   it's just an internal shuffling around
   of resources to the router. 

   Also: even if two physical routers own the two
   subnets, it may still be more economical to 
   shoot a host route to the other so long as
   the routes are summarized pretty quickly.


	      Mike


From owner-seamoby@diameter.org  Fri Jan  5 18:31:30 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25466
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 18:31:30 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05Me0D08685
	for seamoby-list; Fri, 5 Jan 2001 14:40:00 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (flipper.cisco.com [171.69.25.141])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05MduW08679
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 14:39:56 -0800
Received: from dblair-pc (dhcp-atlanta-220-52.cisco.com [161.44.220.52])
	by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id NAA28911;
	Fri, 5 Jan 2001 13:46:52 -0800 (PST)
Message-Id: <4.1.20010105162601.04740c60@flipper.cisco.com>
X-Sender: dblair@flipper.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 05 Jan 2001 16:35:42 -0500
To: James Kempf <James.Kempf@eng.sun.com>, neumiller@telocity.com,
        Pat.Calhoun@eng.sun.com, gkenward@nortelnetworks.com
From: "Dana L. Blair" <dblair@cisco.com>
Subject: RE: [seamoby] Some thoughts and issues
Cc: Madjid.Nakhjiri@motorola.com, campbell@comet.columbia.edu,
        James.Kempf@eng.sun.com, Phil_Neumiller@3Com.com, dblair@cisco.com,
        seamoby@diameter.org, cellularip@comet.columbia.edu,
        seamoby-mm@cdma-2000.org
In-Reply-To: <200101052125.NAA14794@nasnfs.eng.sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-seamoby@diameter.org
Precedence: bulk

At 01:25 PM 1/5/01 -0800, James Kempf wrote:
>Gary,
>
>>We still seem to be having a hard time defining what micro-mobility is in
>>the SeaMoby sense. Dare I ask what "micromobility in the classic sense"
>>means?
>>

This thread is very long so this may have already been mentioned.
Defining "micromobility in the SEAMOBY sense" means defining micromobility
in the internet sense since SEAMOBY is an IETF working group.  Micromobility
addresses directing data to/from a moving endpoint.  For the internet,
the endpoint has an IP address.

Therefore,  I believe that micromobility in the SEAMOBY sense should
address movement of an IP device while it uses the same IP address.  So the point
of the attachment (link) of an IP device may change as it moves, but the IP address assigned
to the device will not if the device is micro-mobile.

I have copied the micromobility alias since this discussion directly relates the problem
statement for micromobility.

thanks,
Dana

>
>This probably isn't going to help much, but we've defined micromobility
>in MWIF as mobility within a radio access network, and macromobility
>as between radio access networks.
>
>		jak
>



From owner-seamoby@diameter.org  Fri Jan  5 18:32:36 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25481
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 18:32:36 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05Mkpc08722
	for seamoby-list; Fri, 5 Jan 2001 14:46:51 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05MkjW08711
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 14:46:45 -0800
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA06118;
	Fri, 5 Jan 2001 13:54:17 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA27625;
	Fri, 5 Jan 2001 13:54:16 -0800 (PST)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA15777;
	Fri, 5 Jan 2001 13:54:15 -0800 (PST)
Message-Id: <200101052154.NAA15777@nasnfs.eng.sun.com>
Date: Fri, 5 Jan 2001 13:54:33 -0800 (PST)
From: James Kempf <James.Kempf@eng.sun.com>
Reply-To: James Kempf <James.Kempf@eng.sun.com>
Subject: RE: [seamoby] Some thoughts and issues
To: James.Kempf@eng.sun.com, neumiller@telocity.com, Pat.Calhoun@eng.sun.com,
        gkenward@nortelnetworks.com, dblair@cisco.com
Cc: Madjid.Nakhjiri@motorola.com, campbell@comet.columbia.edu,
        James.Kempf@eng.sun.com, Phil_Neumiller@3Com.com, dblair@cisco.com,
        seamoby@diameter.org, cellularip@comet.columbia.edu,
        seamoby-mm@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: rwRAPrji6a7NOh22Dc1ayA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Dana,

The question is whether it changes subnet when it moves
or not?

I agree that the MWIF definition won't perhaps help, but what I'm
trying to get at is if there is anything here not already handled
by mobile IP. If there is a change in subnet, then I don't
see much difference. If not, and there is still some need for
L3 protocol signalling action, then maybe there is. In as sense,
the definition of micromobility determines whether or not
there is a distinction from mobile IP.

In a sense, the MWIF definition basically doesn't the distinction, 
since there can be both inter- and intra-subnet movement in the RAN.

Does that make sense?

		jak
		
>X-Sender: dblair@flipper.cisco.com
>Date: Fri, 05 Jan 2001 16:35:42 -0500
>To: James Kempf <James.Kempf@eng.sun.com>, neumiller@telocity.com, 
Pat.Calhoun@eng.sun.com, gkenward@nortelnetworks.com
>From: "Dana L. Blair" <dblair@cisco.com>
>Subject: RE: [seamoby] Some thoughts and issues
>Cc: Madjid.Nakhjiri@motorola.com, campbell@comet.columbia.edu, 
James.Kempf@eng.sun.com, Phil_Neumiller@3Com.com, dblair@cisco.com, 
seamoby@diameter.org, cellularip@comet.columbia.edu, seamoby-mm@cdma-2000.org
>Mime-Version: 1.0
>
>At 01:25 PM 1/5/01 -0800, James Kempf wrote:
>>Gary,
>>
>>>We still seem to be having a hard time defining what micro-mobility is in
>>>the SeaMoby sense. Dare I ask what "micromobility in the classic sense"
>>>means?
>>>
>
>This thread is very long so this may have already been mentioned.
>Defining "micromobility in the SEAMOBY sense" means defining micromobility
>in the internet sense since SEAMOBY is an IETF working group.  Micromobility
>addresses directing data to/from a moving endpoint.  For the internet,
>the endpoint has an IP address.
>
>Therefore,  I believe that micromobility in the SEAMOBY sense should
>address movement of an IP device while it uses the same IP address.  So the 
point
>of the attachment (link) of an IP device may change as it moves, but the IP 
address assigned
>to the device will not if the device is micro-mobile.
>
>I have copied the micromobility alias since this discussion directly relates 
the problem
>statement for micromobility.
>
>thanks,
>Dana
>
>>
>>This probably isn't going to help much, but we've defined micromobility
>>in MWIF as mobility within a radio access network, and macromobility
>>as between radio access networks.
>>
>>		jak
>>
>



From owner-seamoby@diameter.org  Fri Jan  5 19:03:05 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25747
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 19:03:02 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05NCEE08856
	for seamoby-list; Fri, 5 Jan 2001 15:12:14 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05NCCW08851
	for <seamoby@cdma-2000.org>; Fri, 5 Jan 2001 15:12:12 -0800
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA13414
	for <seamoby@cdma-2000.org>; Fri, 5 Jan 2001 14:19:53 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA04635;
	Fri, 5 Jan 2001 14:19:51 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA16724;
	Fri, 5 Jan 2001 14:19:49 -0800 (PST)
Date: Fri, 5 Jan 2001 14:16:18 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: [seamoby] Minutes from 49th IETF Seamoby WG meeting
To: seamoby@cdma-2000.org
Cc: Pat.Calhoun@eng.sun.com
Message-ID: <Roam.SIMC.2.0.6.978732978.21490.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

Please review the attached meeting minutes before 1/12/2001, after which I
will send them to the secretariat.

Thanks,

PatC
----


49th IETF in San Diego
Seamoby Working Group

Chairs: Pat Calhoun (pcalhoun@eng.sun.com)
	Phil Neumiller (phil_neumiller@3com.com)

Reported by: La Monte Henry Piggy Yarroll (piggy@em.cig.mot.com)


Meeting Summary:

As a result of the meeting, three design groups were formed. James Kempf
(james.kempf@eng.sun.com) will lead the paging team, Dana Blair
(dblair@cisco.com) will lead the micro-mobility team, while Gary Kenward
(gkenward@nortelnetworks.com) will lead the context transfer team).

The design teams are responsible for coming up with a problem statement
for their respective area.


Minutes:

1. Agenda

  Agenda Bashing
  Ground Rules
	- Chairs are very firm about charter.
	- White gloves only
  Milestones
	- Layer 3 paging
	  A point was made that the working group should first handle context
	  transfer, given that this was the most complicated work item.
	  The chair stated that all work will progress in parallel.

	  Another point was made that paging should exist in the Mobile IP WG,
	  but MIP has already agreed that paging is not within its charter.

	- Micro-Mobility
	  A point was made that a succinct definition of WHAT Micro-mobility
	  IS, is lacking from OUR COMMON VOCABULARY.

	  Sampling question:  Do we need to reassess?  Is MobileIP becoming
	  sufficient (see 3 above)?
	  We need a clear problem statement.

	  A point was made that MIP may be sufficient, but there are scenarios
	  that might need more than MIP. We need some scenarios. Is MM mobility
	  within a subnet? Why doesn't MIP solve this? Why aren't the current
	  radio protocols sufficient?

	  The MIP WG co-chair stated that we should explore the possible
	  solutions which MIP is NOT exploring. There is an ID presented
	  that has such a problem description., which will be presented
	  in the meeting.

	  The chair stated that we need a set of requirements.  We need a
	  separate design team for a problem statement and a set of
	  requirements.

	  Ideally, submit candidate protocols around about 22 February.
	  REQUIRED is a document that compares the protocol to the
	  requirements.

	  A comment was made that we should not over-narrow the scope of the
	  WG. Another comment was made that some Mobile IP submissions might
	  be relevant to some of our work items, and that we should take a
	  closer look at what's going on in MIP.

	  An evaluation team will then select a protocol from the submitted
	  candidates. A comment was made that evaluation teams are against
	  the IETF mantra, and the working group should be the one that
	  decides. There was some concern as to whether one single solution
	  could be chosen, which the AD responded that one is sufficient,
	  more would create confusion in the marketplace. There was many
	  discussions on whether one or more problems are appropriate, and
	  the problem description should address that issue.

	  There was another thread that questioned what kind of solutions are
	  appropriate, whether it's routing, link or application. Some 
	  suggested routing.

	- State Transfer

	  There are three options that the WG should evaluate:
	    1. Have the network nodes transfer state
	    2. Let the mobiles upload their state
	    3. Let the mobiles renegotiate with network
	  Comments were made that the first option seems most likely, and
	  would probably best provide seamless mobility.

	  There was some discussion on what state transfer is, and isn't,
	  but a problem statement is required, as per our charter, for
	  the IESG to decide whether the work will be done.


2. Seamoby Reference Model

  Phil Neumiller presented a reference model with a picture of some
  kinds of MIP peer within IP and "Hints" going down to layer 2. The
  "dumb access point" only brings SeaMoby. There was also another
  diagram provided by Phil that shows a network doing a vertical
  handoff. There was much controversy on what the pictures meant, and
  where some functions resided, but the main focus was to show that
  multi-technology handoffs should be possible. How it is done is
  something that can only be answered once a problem statement has been
  written.

  There were more discussions on how QoS is affected in a seamoby
  environment, and another diagram showing an actual handoff taking
  place. There was a comment that Mobile IP already solves this problem,
  but Mobile IP doesn't handle mobile routers or subnets.


3. Seamoby Concerns (John Loughney)

  John Loughney presented some concerns, and in his presentations he showed
  a long list of handover types, followed by a list of definitions of the
  various handover types, such as seamless, fast, smooth, etc. There was
  a slide that discussed context transfer, which may include compression state,
  policy, security, etc. There was a question as to what kind of state we
  really want to send, what makes sense? There was a comment that end-to-end
  QoS is obviously out of scope, given that the edge has no control over
  the network (and the endpoint), so there are no QoS guarantees.

  John then presented some of his requirements, which are:
	-- IPv6-friendly
	-- Split micro/macro  (e.g. minimize reauthentication)
	-- Layer 2 independent, but use what we can
	   "Do what you can locally, but go global when necessary."
	-- minimize air signaling
	-- applications should not need to be mobile-aware
	-- Security is important

  His drafts will be announced on the mailing list.


4. SeaMoby Header Compression (Rajeev Koodli)

  Rejeev is presenting his two Internet Drafts:
	draft-koodli-rohc-hc-relocate-00.txt
	draft-koodli-mobileip-smoothv6-00.txt

  The problem is how to move the compression state from an
  old router to a new router. The proposed solution is HCRP,
  where the MN asks the new router to fetch the context from
  the old router.

  There are many compression profile types, so what kind of
  compression info is needed? A possible work item is to define
  a bunch of compression profiles, but a question was raised as
  to what the savings were. The response was that packet loss over
  the air could cause problems for state handoff.


5. Cellular IP

  Andrew Campbell presented Cellular IP, and stated that more information
  on Cellular IP can be found on the web site (both the code and the docs).
  The discussion was not Mobile IP does not scale as well as IP, and that
  something new is required. Many comments were made in regards to this
  presentation, but the fact of the matter is that we need to understand
  the problem before we look into the solutions.

  More questioned how a stateful protocol can be more scalable than a
  stateless protocol, and questions on how L3 paging can be used, etc.
  However, these were all solutions, and not requirements.

  There was a comment on why this presentation was made here, given that
  we aren't at the solutions stage yes, which drew some applause some the
  audience. The response from the chair was fairness.


6. State transfer between Access Routers during Handoff

  Context Transfer++ (draft-oneill-handoff-state-00.txt) was
  presented, and briefly summarized some of the states that need
  to be transferred to expose some of the gory bits. The transferred
  state might have some attachment to surrounding universe of the
  edge router. 

  Some approaches were discussed, such as allowing the mobile to rebuild
  the state on the new router using the appropriate protocols (e.g. RSVP,
  Mobile IP, etc). It was noted that it make take several seconds to
  rebuild the state. Another approach is to assume that the Mobile Node
  can securely upload all of the state to the new router, but the
  speaker stated that there are some trust issues in this model. Another
  model is to allow the routers to exchange the states directly.

  An example of state that could be transferred was multicast information.
  We could not do anything, and let the mobile rejoin, have the mobile 
  send IGMP information to the router, or have the old router send the
  IGMP information to the new router.

  The recommended approach was to document the state, design a solution
  and document it per protocol. First, we should document the requirements
  for generalized context transfer.

  There were questions whether this could be handled at layer 2, and 
  the feeling was no.

  A question was raised why is there a need for seamless handoff in the
  first place, where Charlie Perkins answered "S a m e s H nd  v r".


7. Buffer Mgmt (Charlie Perkins, the Tallest MIP Designer)

  Rate of beacons in MIP is too slow to do voice buffering, but if you
  increase the beacon rate you can make it work.
  Hand over 2-3 buffers and you get pretty-good results.
  Holy Grail:  Do smooth voice hand-over.
  Problem statement (paraphrase): "Mobile node has some context and
  needs to retrieve it later..."


8. Realtime Mobile IPv6

  Dana Blair presented draft-blair-rt-mobileipv6-seamoby-00.txt. The
  goals of the draft are:
	- Address HO for realtime within subnets (micro) and
	  between subnets (macro).
	- Address access, AAA, QoS, IPSec, handoff signaling.
	- Common terminology
  Dana presented some Micro-Mobility objectives, which should become
  requirements:
	- Minimize packets sent/received by mobile
	- Minimize time between access link changes
	- Minimize lots of other stuff...
	  Ditto for Macro-mobility

  There were a few proposed solutions:
	- Combine the whole mess into a single message from the mobile
	- Cache context
	- Re-use existing protocols
	- Avoid a new protocol

  There was a question whether minimizing packets meant round trips,
  and the speaker answered that packets matter too. Another questioned
  why multicasting was missing (as a state to transfer), and the answer
  was that it hadn't come up, and it did complicate the problem. Another
  questioned whether a single packet solution (to transfer state)
  generalized lots of other stuff, but someone stated that some state
  information may not fit in a single packet. Lastly, someone questioned
  the reliability of a single packet handoff.


9. Next steps
  Chair: Who wants to participate in the problem statement?  (Many hands)
  Who wants to do the administrative overhead?
  Context Transfer: Gary Kenward
  MM: Dana Blair
  Paging: James Kempf

  A comment was made that all micro-mobility people should simply post
  their comments to the main list. A follow-on stated that everybody has
  their own terminology, and a team would help tp to unify the terminology.

  Another comment was made that the dates in the milestone are too aggressive,
  which was caused by the amount of time it took for the charter to be
  fixed to address IESG concerns, and then approved.




From owner-seamoby@diameter.org  Fri Jan  5 19:06:32 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25761
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 19:06:30 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05MYS208666
	for seamoby-list; Fri, 5 Jan 2001 14:34:28 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05MYQW08661
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 14:34:26 -0800
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id NAA08992
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 13:42:03 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA20992; Fri, 5 Jan 2001 13:42:03 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14934.16299.363212.401762@thomasm-u1.cisco.com>
Date: Fri, 5 Jan 2001 13:42:03 -0800 (PST)
To: <seamoby@diameter.org>
Subject: [seamoby] nomenclature
In-Reply-To: <006901c075f0$5f6f3ba0$0100000a@david>
References: <Roam.SIMC.2.0.6.978556498.18348.pcalhoun@nasnfs>
	<006901c075f0$5f6f3ba0$0100000a@david>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


I don't want to pick on Dave in particular here,
but it seems to me that it would be good if we
could all try to converge on the same
nomenclature. I see that Dave is using "FA" here
which conjures up mipv4 FA's in my mind at least
which he may or may not be intending.

In draft-blair-rt-mobileip-seamoby-00, we tried to
gather up what we thought were the current
as-consensus-as-we-could-figure-out terms for the
various functional pieces out of MIPv6
discussions. In this particular case, the term
would be AR (= access router) instead of FA which
seems more v6/v4 neutral.

I'd encourage everybody here to look over the
nomenclature in the draft and either we decide to
use it as a basis going forward, a refinement, or
something else altogether, but I think it would
generally help move discussions forward if we
could come to some agreement on what we mean by
various pieces of functionality.

	       thx, Mike

Dave Martin writes:
 > <snipping stuff about problem statement needed>
 > 
 > Here's a crack at one problem I would like to see solved.
 > 
 > Mobile IP does a decent job of tracking mobility, but it needs some
 > improvements to support certain types of applications.  When a mobile node
 > crosses from on FA cloud to another, the network will likely lose several
 > packets while the network is updated with the mobiles new location.
 > Furthermore this period of "unreachability" while in the transitioning phase
 > generally lasts too long for time sensitive applications (e.g., duplex
 > voice, etc).  A mechanism is needed that will allow mobile nodes
 > unrestrained mobility while minimizing (eliminating?) packet loss and
 > latency.
 > 
 > It probably needs some word-smithing.
 > 
 > 


From owner-seamoby@diameter.org  Fri Jan  5 19:12:34 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25819
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 19:12:33 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05NHJO08870
	for seamoby-list; Fri, 5 Jan 2001 15:17:19 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05NHGW08865
	for <seamoby@cdma-2000.org>; Fri, 5 Jan 2001 15:17:16 -0800
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA14863
	for <seamoby@cdma-2000.org>; Fri, 5 Jan 2001 14:24:58 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA06131;
	Fri, 5 Jan 2001 14:24:58 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA16856;
	Fri, 5 Jan 2001 14:24:56 -0800 (PST)
Date: Fri, 5 Jan 2001 14:21:25 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [seamoby] Minutes from 49th IETF Seamoby WG meeting
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: seamoby@cdma-2000.org
In-Reply-To: "Your message with ID" <Roam.SIMC.2.0.6.978732978.21490.pcalhoun@nasnfs>
Message-ID: <Roam.SIMC.2.0.6.978733285.13378.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

I somehow failed to thank La Monte for his excellent minute taking skills.
Looking forward to having him present at the next meeting in Minn :)

PatC



From owner-seamoby@diameter.org  Fri Jan  5 19:17:15 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25857
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 19:17:15 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05N9nK08845
	for seamoby-list; Fri, 5 Jan 2001 15:09:49 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05N9kW08840
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 15:09:46 -0800
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id OAA09909;
	Fri, 5 Jan 2001 14:16:56 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA20998; Fri, 5 Jan 2001 14:16:55 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14934.18391.658713.248582@thomasm-u1.cisco.com>
Date: Fri, 5 Jan 2001 14:16:55 -0800 (PST)
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: David Frascone <dave@frascone.com>, seamoby@diameter.org
Subject: Re: [seamoby] Micromobility Problem Statement
In-Reply-To: <Roam.SIMC.2.0.6.978556498.18348.pcalhoun@nasnfs>
References: <20010103144234.J10666@newman.frascone.com>
	<Roam.SIMC.2.0.6.978556498.18348.pcalhoun@nasnfs>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat Calhoun writes:
 > ok, let me try one more time. 
 > 
 > How about we collaborate together to come up with a problem statement. One
 > that describes what problem we have today, and what micro-mobility is
 > attempting to achieve.
 > 
 > Talking about whether diffserv or intserv, what signaling protocols should be
 > used, physical wireless interface characterics seem to be stepping in the
 > solutions space.

Pat,

I guess this comes down to how fine-grained we
want to make the problem statement. I've been
refraining from getting into the nitty-gritty of
mechanism nuts and bolts, but I'm having a problem
if the problem statement can't even refer to
diffserv and intserv as those are standard IETF
mechanisms for delivering QoS enhanced traffic.

Is there something wrong with:

Seamoby must provide seamless mobility for traffic
from a mobile host which utilizes enhanced (> best
effort) quality of service, and must interoperate
well with the standard IETF diffserv, intserv and
combined diffserv/intserv methods of providing
enhanced quality of service. Seamoby should
endeavor to use standard quality of service
mechanisms where possible and should deliver a
problem statement to the appropriate working
groups if existing quality of service mechanisms
are found to be inadequate to support seamless
mobility.

?

		Mike


From owner-seamoby@diameter.org  Fri Jan  5 19:23:26 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25902
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 19:23:25 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05NXA808909
	for seamoby-list; Fri, 5 Jan 2001 15:33:10 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05NX6W08904
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 15:33:07 -0800
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA18871;
	Fri, 5 Jan 2001 14:40:44 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA10150;
	Fri, 5 Jan 2001 14:40:40 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA17399;
	Fri, 5 Jan 2001 14:40:39 -0800 (PST)
Date: Fri, 5 Jan 2001 14:37:07 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [seamoby] Micromobility Problem Statement ISSUE 2
To: Ramachandran Ramjee <ramjee@dnrc.bell-labs.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        Gary Kenward <gkenward@nortelnetworks.com>,
        "'Phil_Neumiller@3Com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
In-Reply-To: "Your message with ID" <3A56259C.4F89368A@dnrc.bell-labs.com>
Message-ID: <Roam.SIMC.2.0.6.978734227.26686.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk


> 3) The question of new FA finding the old FA (or old redirector) - this
> is needed only when the new FA gets only a L2 update and needs to 
> translate it to an L3 old FA address - this is really an optimization
> to avoid paging and I think it doesn't belong in seamoby.

But the example provided is where the AP is NOT the FA, and it must signal
link layer events over IP (similar to CDMA2000 R-P interface). If there are
many FAs assigned to each AP, how does an FA know which FA for a given AP it
should contact to perform the handoff?

In source triggered events, that is simple since the source Foreign Agent
would get a signal that the mobile is moving to a new "cell". However, for
target triggered events, this is much more complicated since there are more
than one FA on the old AP's net to worry about.

Hence the problem (assuming the above is a problem that even needs to be
solved). Again, I am just trying to understand that Micro-Mobility really is
all about (in the context of SeaMoby, of course).

PatC



From owner-seamoby@diameter.org  Fri Jan  5 19:26:26 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25923
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 19:26:26 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f05NNvT08892
	for seamoby-list; Fri, 5 Jan 2001 15:23:57 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f05NNsW08887
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 15:23:55 -0800
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14756;
	Fri, 5 Jan 2001 14:31:34 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA07866;
	Fri, 5 Jan 2001 14:31:34 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA17106;
	Fri, 5 Jan 2001 14:31:32 -0800 (PST)
Date: Fri, 5 Jan 2001 14:28:00 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [seamoby] Micromobility Problem Statement
To: Michael Thomas <mat@cisco.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>, David Frascone <dave@frascone.com>,
        seamoby@diameter.org
In-Reply-To: "Your message with ID" <14934.18391.658713.248582@thomasm-u1.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.978733680.30033.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk


> 
> Is there something wrong with:
> 
> Seamoby must provide seamless mobility for traffic
> from a mobile host which utilizes enhanced (> best
> effort) quality of service, and must interoperate
> well with the standard IETF diffserv, intserv and
> combined diffserv/intserv methods of providing
> enhanced quality of service. Seamoby should
> endeavor to use standard quality of service
> mechanisms where possible and should deliver a
> problem statement to the appropriate working
> groups if existing quality of service mechanisms
> are found to be inadequate to support seamless
> mobility.
> 

Just to be clear, I am not discounting the fact that QoS is
important. However, let's assume for the moment that I am in
fact a village idiot. The above text doesn't, in any way, shape,
or form, tell me what micro-mobility really is. If it means
packets get routed to the mobile, then how is this different 
from today's Mobile IP.

The reason why I sent some "example scenarios" yesterday with
multiple FAs on a subnet with one AP was to see if I did in
fact understand the problem. Still not sure that I am.

Is Micro-Mobility Mobile IP with some QoS enhancements? I felt
it was more than that.

:(

PatC



From owner-seamoby@diameter.org  Fri Jan  5 19:52:58 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26083
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 19:52:57 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f060NdU09204
	for seamoby-list; Fri, 5 Jan 2001 16:23:39 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f060NaW09199
	for <seamoby@cdma-2000.org>; Fri, 5 Jan 2001 16:23:37 -0800
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15139;
	Fri, 5 Jan 2001 15:31:16 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA07786;
	Fri, 5 Jan 2001 15:31:15 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA19015;
	Fri, 5 Jan 2001 15:31:13 -0800 (PST)
Date: Fri, 5 Jan 2001 15:27:42 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [seamoby] Re: [MOBILE-IP] Where can I find info on OBAST?
To: Karann Chew <k.chew@eim.surrey.ac.uk>
Cc: Peter Lei <peter.lei@motorola.com>, seamoby@cdma-2000.org
In-Reply-To: "Your message with ID" <Pine.GSO.4.21.0101052304450.24820-100000@carter.ee.surrey.ac.uk>
Message-ID: <Roam.SIMC.2.0.6.978737262.10001.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

> The objective of Seamoby is to support seamless mobility and handover
> between diverse access technologies, including heterogenous radio access
> techniques for wireless world.  My question is: how could this idea fit
> into current cellular network, given that it's network infrastructures are 
> closed-controlled by it's operator.  For example, could a mobile user
> currently being served by BS of Cellular_Operator_A handovered to another
> BS of Cellular_Operator_B?  Or this is scenario is out of the scope?  

in scope.

> 
> Another question:
> Am I right to say that micro mobility protocols (e.g HAWAII, CIP
> etc) should now be discussed here?

Micro-mobility, yes. Actual protocols, not at this time. We are in the process
of trying to specify a problem statement for Micro-Mobility to make sure that
we are all trying to solve the same problem.

PatC



From owner-seamoby@diameter.org  Fri Jan  5 19:59:07 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26138
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 19:59:07 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0605rE09070
	for seamoby-list; Fri, 5 Jan 2001 16:05:53 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0605nW09059
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 16:05:49 -0800
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06654;
	Fri, 5 Jan 2001 15:13:20 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA03392;
	Fri, 5 Jan 2001 15:13:14 -0800 (PST)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA18472;
	Fri, 5 Jan 2001 15:13:13 -0800 (PST)
Message-Id: <200101052313.PAA18472@nasnfs.eng.sun.com>
Date: Fri, 5 Jan 2001 15:13:30 -0800 (PST)
From: James Kempf <James.Kempf@eng.sun.com>
Reply-To: James Kempf <James.Kempf@eng.sun.com>
Subject: Re: [seamoby] Some thoughts and issues
To: dblair@cisco.com, ramjee@dnrc.bell-labs.com
Cc: James.Kempf@eng.sun.com, neumiller@telocity.com, Pat.Calhoun@eng.sun.com,
        gkenward@nortelnetworks.com, Madjid.Nakhjiri@motorola.com,
        campbell@comet.columbia.edu, Phil_Neumiller@3Com.com,
        seamoby@diameter.org, cellularip@comet.columbia.edu,
        seamoby-mm@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: wRKGeCJZVbNxcWS7FGDYag==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk


>
>Dana Blair wrote:
>> Therefore,  I believe that micromobility in the SEAMOBY sense should
>> address movement of an IP device while it uses the same IP address.  So the 
point
>> of the attachment (link) of an IP device may change as it moves, but the IP 
address assigned
>> to the device will not if the device is micro-mobile.
>
>I like this definition a lot. 
>
>1) It clearly distinguishes micro-mobility from Mobile IP (where
>the IP address of the mobile changes)
>

I think you need to say the CoA, not just the IP address. Because
the IP address doesn't change in mobile IP if you are talking
about the home address.

This definition covers a number of areas that I've been thinking of.

>2) It also illustrates the fact the micro-mobility can be handled
>in L2 as is done in cellular and wireless LAN networks and 
>in L3 if seamoby/IETF proposes a solution.
>
>Now, IF we all agree to this definition, then the BIG question is
>why do we need L3 micro-mobility and that is a separate thread
>in itself.
>


		jak



From owner-seamoby@diameter.org  Fri Jan  5 20:08:18 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26291
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 20:08:17 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f060HBk09149
	for seamoby-list; Fri, 5 Jan 2001 16:17:11 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f060H2W09144
	for <seamoby@cdma-2000.org>; Fri, 5 Jan 2001 16:17:02 -0800
Received: from carter-e0.ee.surrey.ac.uk ([131.227.86.16])
	by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1)
	id 14EgDx-0005Df-00; Fri, 05 Jan 2001 23:24:41 +0000
Date: Fri, 5 Jan 2001 23:24:41 +0000 (GMT)
From: Karann Chew <k.chew@eim.surrey.ac.uk>
To: Peter Lei <peter.lei@motorola.com>
cc: seamoby@cdma-2000.org
Subject: [seamoby] Re: [MOBILE-IP] Where can I find info on OBAST?
In-Reply-To: <3A5652ED.839DDFD4@motorola.com>
Message-ID: <Pine.GSO.4.21.0101052304450.24820-100000@carter.ee.surrey.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk


Yes I read about CARPS & OBAST some times ago.  But didn't keep close
track on it, and didn't know and a Seamoby WG was formed.

Please allow me to ask a question...

The objective of Seamoby is to support seamless mobility and handover
between diverse access technologies, including heterogenous radio access
techniques for wireless world.  My question is: how could this idea fit
into current cellular network, given that it's network infrastructures are 
closed-controlled by it's operator.  For example, could a mobile user
currently being served by BS of Cellular_Operator_A handovered to another
BS of Cellular_Operator_B?  Or this is scenario is out of the scope?  

Another question:
Am I right to say that micro mobility protocols (e.g HAWAII, CIP
etc) should now be discussed here?

Thanks again.

	Karann

++++++++++++++++++++++++++++++++++++++++++
Karann Chew 
Mobile Communications Research Group
Centre for Communication Systems Research   
University of Surrey                 
++++++++++++++++++++++++++++++++++++++++++


On Fri, 5 Jan 2001, Peter Lei wrote:

> It essentially came from the "seamless mobility"...  The history:
> 
> The OBAST concept was presented to a couple of AD's at IETF-47 in Adelaide,
> Australia by some interested parties (Phil Neumiller, me, Randy Stewart, 
> Qiaobing Xie).  It resulted in a CRAPS (Common Radio Access Protocol Set)
> BOF at IETF-48 in Pittsburgh, PA. where OBAST was presented and hence the
> drafts.  It "transformed" into the Seamoby WG just before IETF-49 in San
> Diego after discussions with the Mobile IP WG chairs and the IESG.
> 
> OBAST itself isn't really being discussed per se in the WG, but the concepts
> certainly are--
>   seamless mobility across diverse access technologies (wireless, wired)
>   intelligence at the edges (like the internet)
>   etc...
> 
> --peter
> 
> Karann Chew wrote:
> > 
> > Peter,
> > 
> > By the way, do you know what acronym "Seamoby" stands for?
> > 
> > ++++++++++++++++++++++++++++++++++++++++++
> > Karann Chew
> > Mobile Communications Research Group
> > Centre for Communication Systems Research
> > University of Surrey
> > ++++++++++++++++++++++++++++++++++++++++++
> > 
> > On Fri, 5 Jan 2001, Karann Chew wrote:
> > 
> > >
> > > Thanks Peter!
> > >
> > > > What specifically are you looking for??  (I am one of the primary
> > >
> > > Nothing in specific, just want to know more about it.  I'm currently
> > > involve in a project, something to do with 'All-IP network'.  So, I want
> > > to know more about OBAST, or any thing related to it.
> > >
> > > > There are currently only two IETF drafts published on it-- it was
> > >
> > > Yes, they are only two, both pointed out the general requirements.  No
> > > concrete proposals yet.  I'm looking forward to seeing more discussions.
> > >
> > > > There is an article detailing some more about OBAST in the upcoming
> > > > issue of
> > > > Mobile Computing and Communications Review published by ACM's
> > > > Sigmobile--
> > > > I know this doesn't help you right now...  Unfortunately, it's the only
> > > > article besides the drafts tha
> > >
> > > Thanks.  I will read the paper when it is available.
> > >
> > > Regards,
> > >       Karann
> > >
> > > ++++++++++++++++++++++++++++++++++++++++++
> > > Karann Chew
> > > Mobile Communications Research Group
> > > Centre for Communication Systems Research
> > > University of Surrey
> > > ++++++++++++++++++++++++++++++++++++++++++
> > >
> > >
> > > On Fri, 5 Jan 2001, Peter Lei wrote:
> > >
> > > > What specifically are you looking for??  (I am one of the primary authors).
> > > >
> > > > There are currently only two IETF drafts published on it-- it was partially
> > > > the driver for the IETF Seamoby WG.  Similar concepts are being discussed
> > > > there.
> > > >
> > > > There is an article detailing some more about OBAST in the upcoming issue of
> > > > Mobile Computing and Communications Review published by ACM's Sigmobile--
> > > > I know this doesn't help you right now...  Unfortunately, it's the only
> > > > article besides the drafts that is "cleared" for publication.
> > > >
> > > > --peter
> > > >
> > > >
> > > > Karann Chew wrote:
> > > > >
> > > > > Hi There!
> > > > >
> > > > > Could any body tell me where I can get more information or discussion on
> > > > > OBAST?  I could find only two drafts on it.
> > > > >
> > > > > Thanks in advance.
> > > > >
> > > > > Karann
> > > >
> > >
> > >
> 



From owner-seamoby@diameter.org  Fri Jan  5 20:09:54 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26325
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 20:09:51 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f060ijq09256
	for seamoby-list; Fri, 5 Jan 2001 16:44:45 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f060ieW09246
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 16:44:40 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 5 Jan 2001 18:52:03 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBQM5T>; Fri, 5 Jan 2001 18:52:06 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8AAB@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Dana L. Blair'" <dblair@cisco.com>,
        James Kempf <James.Kempf@eng.sun.com>, neumiller@telocity.com,
        Pat.Calhoun@eng.sun.com
Cc: Madjid.Nakhjiri@motorola.com, campbell@comet.columbia.edu,
        James.Kempf@eng.sun.com, Phil_Neumiller@3Com.com, seamoby@diameter.org,
        cellularip@comet.columbia.edu, seamoby-mm@cdma-2000.org
Subject: RE: [seamoby] Some thoughts and issues
Date: Fri, 5 Jan 2001 18:52:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C07772.7FD7F390"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C07772.7FD7F390
Content-Type: text/plain;
	charset="iso-8859-1"

Thanks Dana.
I think your definition works in the context of MIP/SeaMoby. Like Pat, I 
suspect something is missing, but I don't know what. At least we have
something
to think around.

Other then James' explanation of the MWIF definition, I am unclear as to
what "classic micromobility" is. With all respect to MWIF, I'm not sure
they are the definitive source of "classic" definitions. 

More realistically, I shouldn't really worry about it. The point is that the
definition is context sensitive. E.g. the MWIF description holds only if
their
is a RAN that is distinct from a "core" network. I personally believe that
there
is no real requirement for a "RAN" as defined by 2G and 3G networks (I'm 
not a big fan of hierarchical network topolgies).

But then, this is off topic. 

Gary

> -----Original Message-----
> From: Dana L. Blair [mailto:dblair@cisco.com]
> Sent: Friday, January 05, 2001 4:36 PM
> To: James Kempf; neumiller@telocity.com; Pat.Calhoun@eng.sun.com;
> Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: Madjid.Nakhjiri@motorola.com; campbell@comet.columbia.edu;
> James.Kempf@eng.sun.com; Phil_Neumiller@3Com.com; dblair@cisco.com;
> seamoby@diameter.org; cellularip@comet.columbia.edu;
> seamoby-mm@cdma-2000.org
> Subject: RE: [seamoby] Some thoughts and issues
> 
> 
> At 01:25 PM 1/5/01 -0800, James Kempf wrote:
> >Gary,
> >
> >>We still seem to be having a hard time defining what 
> micro-mobility is in
> >>the SeaMoby sense. Dare I ask what "micromobility in the 
> classic sense"
> >>means?
> >>
> 
> This thread is very long so this may have already been mentioned.
> Defining "micromobility in the SEAMOBY sense" means defining 
> micromobility
> in the internet sense since SEAMOBY is an IETF working group. 
>  Micromobility
> addresses directing data to/from a moving endpoint.  For the internet,
> the endpoint has an IP address.
> 
> Therefore,  I believe that micromobility in the SEAMOBY sense should
> address movement of an IP device while it uses the same IP 
> address.  So the point
> of the attachment (link) of an IP device may change as it 
> moves, but the IP address assigned
> to the device will not if the device is micro-mobile.
> 
> I have copied the micromobility alias since this discussion 
> directly relates the problem
> statement for micromobility.
> 
> thanks,
> Dana
> 
> >
> >This probably isn't going to help much, but we've defined 
> micromobility
> >in MWIF as mobility within a radio access network, and macromobility
> >as between radio access networks.
> >
> >		jak
> >
> 
> 

------_=_NextPart_001_01C07772.7FD7F390
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] Some thoughts and issues</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Thanks Dana.</FONT>
<BR><FONT SIZE=2>I think your definition works in the context of MIP/SeaMoby. Like Pat, I </FONT>
<BR><FONT SIZE=2>suspect something is missing, but I don't know what. At least we have something</FONT>
<BR><FONT SIZE=2>to think around.</FONT>
</P>

<P><FONT SIZE=2>Other then James' explanation of the MWIF definition, I am unclear as to</FONT>
<BR><FONT SIZE=2>what &quot;classic micromobility&quot; is. With all respect to MWIF, I'm not sure</FONT>
<BR><FONT SIZE=2>they are the definitive source of &quot;classic&quot; definitions. </FONT>
</P>

<P><FONT SIZE=2>More realistically, I shouldn't really worry about it. The point is that the</FONT>
<BR><FONT SIZE=2>definition is context sensitive. E.g. the MWIF description holds only if their</FONT>
<BR><FONT SIZE=2>is a RAN that is distinct from a &quot;core&quot; network. I personally believe that there</FONT>
<BR><FONT SIZE=2>is no real requirement for a &quot;RAN&quot; as defined by 2G and 3G networks (I'm </FONT>
<BR><FONT SIZE=2>not a big fan of hierarchical network topolgies).</FONT>
</P>

<P><FONT SIZE=2>But then, this is off topic. </FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Dana L. Blair [<A HREF="mailto:dblair@cisco.com">mailto:dblair@cisco.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Friday, January 05, 2001 4:36 PM</FONT>
<BR><FONT SIZE=2>&gt; To: James Kempf; neumiller@telocity.com; Pat.Calhoun@eng.sun.com;</FONT>
<BR><FONT SIZE=2>&gt; Kenward, Gary [WDLN2:AN10:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Cc: Madjid.Nakhjiri@motorola.com; campbell@comet.columbia.edu;</FONT>
<BR><FONT SIZE=2>&gt; James.Kempf@eng.sun.com; Phil_Neumiller@3Com.com; dblair@cisco.com;</FONT>
<BR><FONT SIZE=2>&gt; seamoby@diameter.org; cellularip@comet.columbia.edu;</FONT>
<BR><FONT SIZE=2>&gt; seamoby-mm@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [seamoby] Some thoughts and issues</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; At 01:25 PM 1/5/01 -0800, James Kempf wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt;Gary,</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;We still seem to be having a hard time defining what </FONT>
<BR><FONT SIZE=2>&gt; micro-mobility is in</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;the SeaMoby sense. Dare I ask what &quot;micromobility in the </FONT>
<BR><FONT SIZE=2>&gt; classic sense&quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;means?</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; This thread is very long so this may have already been mentioned.</FONT>
<BR><FONT SIZE=2>&gt; Defining &quot;micromobility in the SEAMOBY sense&quot; means defining </FONT>
<BR><FONT SIZE=2>&gt; micromobility</FONT>
<BR><FONT SIZE=2>&gt; in the internet sense since SEAMOBY is an IETF working group. </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; Micromobility</FONT>
<BR><FONT SIZE=2>&gt; addresses directing data to/from a moving endpoint.&nbsp; For the internet,</FONT>
<BR><FONT SIZE=2>&gt; the endpoint has an IP address.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Therefore,&nbsp; I believe that micromobility in the SEAMOBY sense should</FONT>
<BR><FONT SIZE=2>&gt; address movement of an IP device while it uses the same IP </FONT>
<BR><FONT SIZE=2>&gt; address.&nbsp; So the point</FONT>
<BR><FONT SIZE=2>&gt; of the attachment (link) of an IP device may change as it </FONT>
<BR><FONT SIZE=2>&gt; moves, but the IP address assigned</FONT>
<BR><FONT SIZE=2>&gt; to the device will not if the device is micro-mobile.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I have copied the micromobility alias since this discussion </FONT>
<BR><FONT SIZE=2>&gt; directly relates the problem</FONT>
<BR><FONT SIZE=2>&gt; statement for micromobility.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; thanks,</FONT>
<BR><FONT SIZE=2>&gt; Dana</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;This probably isn't going to help much, but we've defined </FONT>
<BR><FONT SIZE=2>&gt; micromobility</FONT>
<BR><FONT SIZE=2>&gt; &gt;in MWIF as mobility within a radio access network, and macromobility</FONT>
<BR><FONT SIZE=2>&gt; &gt;as between radio access networks.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; jak</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C07772.7FD7F390--


From owner-seamoby@diameter.org  Fri Jan  5 20:21:13 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26460
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 20:21:11 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f060lhu09268
	for seamoby-list; Fri, 5 Jan 2001 16:47:43 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f060leW09263
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 16:47:40 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 5 Jan 2001 18:55:01 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBQM59>; Fri, 5 Jan 2001 18:55:03 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8AAC@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Michael Thomas'" <mat@cisco.com>, seamoby <seamoby@diameter.org>
Subject: RE: [seamoby] nomenclature
Date: Fri, 5 Jan 2001 18:54:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C07772.E95CBD00"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C07772.E95CBD00
Content-Type: text/plain;
	charset="iso-8859-1"

I agree in that we should not MIP nomenclature
until we understand the relationships between functional
entities.

Of course, if we are discussing MIP, we have to use
MIP nomenclature. Let's just not prematurely 
introduce it into SeaMoby.

Gary

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Friday, January 05, 2001 4:42 PM
> To: seamoby
> Subject: [seamoby] nomenclature
> 
> 
> 
> I don't want to pick on Dave in particular here,
> but it seems to me that it would be good if we
> could all try to converge on the same
> nomenclature. I see that Dave is using "FA" here
> which conjures up mipv4 FA's in my mind at least
> which he may or may not be intending.
> 
> In draft-blair-rt-mobileip-seamoby-00, we tried to
> gather up what we thought were the current
> as-consensus-as-we-could-figure-out terms for the
> various functional pieces out of MIPv6
> discussions. In this particular case, the term
> would be AR (= access router) instead of FA which
> seems more v6/v4 neutral.
> 
> I'd encourage everybody here to look over the
> nomenclature in the draft and either we decide to
> use it as a basis going forward, a refinement, or
> something else altogether, but I think it would
> generally help move discussions forward if we
> could come to some agreement on what we mean by
> various pieces of functionality.
> 
> 	       thx, Mike
> 
> Dave Martin writes:
>  > <snipping stuff about problem statement needed>
>  > 
>  > Here's a crack at one problem I would like to see solved.
>  > 
>  > Mobile IP does a decent job of tracking mobility, but it needs some
>  > improvements to support certain types of applications.  
> When a mobile node
>  > crosses from on FA cloud to another, the network will 
> likely lose several
>  > packets while the network is updated with the mobiles new location.
>  > Furthermore this period of "unreachability" while in the 
> transitioning phase
>  > generally lasts too long for time sensitive applications 
> (e.g., duplex
>  > voice, etc).  A mechanism is needed that will allow mobile nodes
>  > unrestrained mobility while minimizing (eliminating?) 
> packet loss and
>  > latency.
>  > 
>  > It probably needs some word-smithing.
>  > 
>  > 
> 

------_=_NextPart_001_01C07772.E95CBD00
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] nomenclature</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I agree in that we should not MIP nomenclature</FONT>
<BR><FONT SIZE=2>until we understand the relationships between functional</FONT>
<BR><FONT SIZE=2>entities.</FONT>
</P>

<P><FONT SIZE=2>Of course, if we are discussing MIP, we have to use</FONT>
<BR><FONT SIZE=2>MIP nomenclature. Let's just not prematurely </FONT>
<BR><FONT SIZE=2>introduce it into SeaMoby.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Michael Thomas [<A HREF="mailto:mat@cisco.com">mailto:mat@cisco.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Friday, January 05, 2001 4:42 PM</FONT>
<BR><FONT SIZE=2>&gt; To: seamoby</FONT>
<BR><FONT SIZE=2>&gt; Subject: [seamoby] nomenclature</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I don't want to pick on Dave in particular here,</FONT>
<BR><FONT SIZE=2>&gt; but it seems to me that it would be good if we</FONT>
<BR><FONT SIZE=2>&gt; could all try to converge on the same</FONT>
<BR><FONT SIZE=2>&gt; nomenclature. I see that Dave is using &quot;FA&quot; here</FONT>
<BR><FONT SIZE=2>&gt; which conjures up mipv4 FA's in my mind at least</FONT>
<BR><FONT SIZE=2>&gt; which he may or may not be intending.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In draft-blair-rt-mobileip-seamoby-00, we tried to</FONT>
<BR><FONT SIZE=2>&gt; gather up what we thought were the current</FONT>
<BR><FONT SIZE=2>&gt; as-consensus-as-we-could-figure-out terms for the</FONT>
<BR><FONT SIZE=2>&gt; various functional pieces out of MIPv6</FONT>
<BR><FONT SIZE=2>&gt; discussions. In this particular case, the term</FONT>
<BR><FONT SIZE=2>&gt; would be AR (= access router) instead of FA which</FONT>
<BR><FONT SIZE=2>&gt; seems more v6/v4 neutral.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I'd encourage everybody here to look over the</FONT>
<BR><FONT SIZE=2>&gt; nomenclature in the draft and either we decide to</FONT>
<BR><FONT SIZE=2>&gt; use it as a basis going forward, a refinement, or</FONT>
<BR><FONT SIZE=2>&gt; something else altogether, but I think it would</FONT>
<BR><FONT SIZE=2>&gt; generally help move discussions forward if we</FONT>
<BR><FONT SIZE=2>&gt; could come to some agreement on what we mean by</FONT>
<BR><FONT SIZE=2>&gt; various pieces of functionality.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; thx, Mike</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Dave Martin writes:</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; &lt;snipping stuff about problem statement needed&gt;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; Here's a crack at one problem I would like to see solved.</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; Mobile IP does a decent job of tracking mobility, but it needs some</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; improvements to support certain types of applications.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; When a mobile node</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; crosses from on FA cloud to another, the network will </FONT>
<BR><FONT SIZE=2>&gt; likely lose several</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; packets while the network is updated with the mobiles new location.</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; Furthermore this period of &quot;unreachability&quot; while in the </FONT>
<BR><FONT SIZE=2>&gt; transitioning phase</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; generally lasts too long for time sensitive applications </FONT>
<BR><FONT SIZE=2>&gt; (e.g., duplex</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; voice, etc).&nbsp; A mechanism is needed that will allow mobile nodes</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; unrestrained mobility while minimizing (eliminating?) </FONT>
<BR><FONT SIZE=2>&gt; packet loss and</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; latency.</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; It probably needs some word-smithing.</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C07772.E95CBD00--


From owner-seamoby@diameter.org  Fri Jan  5 20:44:50 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26713
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 20:44:50 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f060br909228
	for seamoby-list; Fri, 5 Jan 2001 16:37:53 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f060boW09222
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 16:37:50 -0800
Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com;
          Fri, 5 Jan 2001 18:42:19 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBQMYR>; Fri, 5 Jan 2001 18:42:22 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8AA9@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'James Kempf'" <James.Kempf@eng.sun.com>, neumiller@telocity.com,
        Pat.Calhoun@eng.sun.com
Cc: Madjid.Nakhjiri@motorola.com, campbell@comet.columbia.edu,
        Phil_Neumiller@3Com.com, dblair@cisco.com, seamoby@diameter.org,
        cellularip@comet.columbia.edu
Subject: RE: [seamoby] Some thoughts and issues
Date: Fri, 5 Jan 2001 18:42:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C07771.248416A0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C07771.248416A0
Content-Type: text/plain;
	charset="iso-8859-1"

Hmmm. It helps if this is what Phil was referring to. 

Thanks,
Gary

> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@eng.sun.com]
> Sent: Friday, January 05, 2001 4:26 PM
> To: neumiller@telocity.com; Pat.Calhoun@eng.sun.com; Kenward, Gary
> [WDLN2:AN10:EXCH]
> Cc: Madjid.Nakhjiri@motorola.com; campbell@comet.columbia.edu;
> James.Kempf@eng.sun.com; Phil_Neumiller@3Com.com; dblair@cisco.com;
> seamoby@diameter.org; cellularip@comet.columbia.edu
> Subject: RE: [seamoby] Some thoughts and issues
> 
> 
> Gary,
> 
> >We still seem to be having a hard time defining what 
> micro-mobility is in
> >the SeaMoby sense. Dare I ask what "micromobility in the 
> classic sense"
> >means?
> >
> 
> This probably isn't going to help much, but we've defined 
> micromobility
> in MWIF as mobility within a radio access network, and macromobility
> as between radio access networks.
> 
> 		jak
> 
> 

------_=_NextPart_001_01C07771.248416A0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] Some thoughts and issues</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hmmm. It helps if this is what Phil was referring to. </FONT>
</P>

<P><FONT SIZE=2>Thanks,</FONT>
<BR><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: James Kempf [<A HREF="mailto:James.Kempf@eng.sun.com">mailto:James.Kempf@eng.sun.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Friday, January 05, 2001 4:26 PM</FONT>
<BR><FONT SIZE=2>&gt; To: neumiller@telocity.com; Pat.Calhoun@eng.sun.com; Kenward, Gary</FONT>
<BR><FONT SIZE=2>&gt; [WDLN2:AN10:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Cc: Madjid.Nakhjiri@motorola.com; campbell@comet.columbia.edu;</FONT>
<BR><FONT SIZE=2>&gt; James.Kempf@eng.sun.com; Phil_Neumiller@3Com.com; dblair@cisco.com;</FONT>
<BR><FONT SIZE=2>&gt; seamoby@diameter.org; cellularip@comet.columbia.edu</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [seamoby] Some thoughts and issues</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Gary,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;We still seem to be having a hard time defining what </FONT>
<BR><FONT SIZE=2>&gt; micro-mobility is in</FONT>
<BR><FONT SIZE=2>&gt; &gt;the SeaMoby sense. Dare I ask what &quot;micromobility in the </FONT>
<BR><FONT SIZE=2>&gt; classic sense&quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt;means?</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; This probably isn't going to help much, but we've defined </FONT>
<BR><FONT SIZE=2>&gt; micromobility</FONT>
<BR><FONT SIZE=2>&gt; in MWIF as mobility within a radio access network, and macromobility</FONT>
<BR><FONT SIZE=2>&gt; as between radio access networks.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; jak</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C07771.248416A0--


From owner-seamoby@diameter.org  Fri Jan  5 20:51:23 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26794
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 20:51:22 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0612lp09288
	for seamoby-list; Fri, 5 Jan 2001 17:02:47 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0612jW09283
	for <seamoby@diameter.org>; Fri, 5 Jan 2001 17:02:45 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 5 Jan 2001 19:04:58 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBQM7V>; Fri, 5 Jan 2001 19:05:01 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8AAD@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Michael A. Ramalho'" <mramalho@cisco.com>,
        James Kempf <James.Kempf@eng.sun.com>, neumiller@telocity.com,
        Pat.Calhoun@eng.sun.com
Cc: Madjid.Nakhjiri@motorola.com, campbell@comet.columbia.edu,
        James.Kempf@eng.sun.com, Phil_Neumiller@3Com.com, dblair@cisco.com,
        seamoby@diameter.org, cellularip@comet.columbia.edu
Subject: RE: [seamoby] Some thoughts and issues
Date: Fri, 5 Jan 2001 19:04:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C07774.4C4ED3C0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C07774.4C4ED3C0
Content-Type: text/plain;
	charset="iso-8859-1"

I think this discussion highlights what is appealing about Dana's
description of micromobility. If we try and define micromobility
in terms of what it does for a RAN we run into the problem of
defining a RAN, which leads to debates over the mobility support
in different RAN technologies, which iterates back over issues
concerning the definition of the RAN boundaries.

Perhaps we can defined micromobility in terms of mobility between
APs (and thus between an abstract Access Network which could
represent a single wireless link, a wireless PAN, a wireless LAN, or a 
complete wireless network), without change in the MN IP address.

I think that at some point an informational ID may be required to
describe micromobility for each wireless networking technology, and
I suspect that each description will differ. The challenge will be to
minimize the differences and ensure that they are options, not
customizations.

Gary

> -----Original Message-----
> From: Michael A. Ramalho [mailto:mramalho@cisco.com]
> Sent: Friday, January 05, 2001 4:58 PM
> To: James Kempf; neumiller@telocity.com; Pat.Calhoun@eng.sun.com;
> Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: Madjid.Nakhjiri@motorola.com; campbell@comet.columbia.edu;
> James.Kempf@eng.sun.com; Phil_Neumiller@3Com.com; dblair@cisco.com;
> seamoby@diameter.org; cellularip@comet.columbia.edu
> Subject: RE: [seamoby] Some thoughts and issues
> 
> 
> At 01:25 PM 1/5/01 -0800, James Kempf wrote:
> >Gary,
> >
> >>We still seem to be having a hard time defining what 
> micro-mobility is in
> >>the SeaMoby sense. Dare I ask what "micromobility in the 
> classic sense"
> >>means?
> >>
> >
> >This probably isn't going to help much, but we've defined 
> micromobility
> >in MWIF as mobility within a radio access network, and macromobility
> >as between radio access networks.
> >
> >		jak
> >
> 
> I think you are right. That definition might be OK for MWIF 
> ... but ...
> what would you call a "radio access network" outside of that context?
> 
> For example ... lets say I have an enterprise router with two 
> types of radio
> system access links on it ... and my mobile decides to 
> request a handoff
> between one wireless access link technology to the other ... but stays
> connected to the same router.
> 
> Would that handoff ... probably within one subnet ... but 
> between two different
> types of radio access links ... be considered macromobility?
> 
> That would be odd, indeed!
> 
> I think IP-oriented people think of (micro)mobility w.r.t. 
> subnets (or trust
> boundaries or administrative domains) without regard for the 
> actual technology
> used on the access link. Conversely, cellular folks usually think of
> (macro)mobility
> between types of "radio access networks".
> 
> So what is our "[micro|macro]mobility" based on ... mobility 
> between "networks"
> or between IP "domains/subsets/domains/clouds"?
> 
> If we are talking IP mobility ... I'd suggest the latter ... 
> but if I were
> a cellular IP guy ... I'd probably argue the former.
> 
> This is why we need that problem definition .....
> 
> 
> Michael A. Ramalho, Ph.D.
> Office email: mramalho@cisco.com
> Personal email: mar42@cornell.edu
> Office: +1.732.449.5762
> Cell: +1.732.809.0188
> Pager: +1.800.365.4578
> 

------_=_NextPart_001_01C07774.4C4ED3C0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] Some thoughts and issues</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I think this discussion highlights what is appealing about Dana's</FONT>
<BR><FONT SIZE=2>description of micromobility. If we try and define micromobility</FONT>
<BR><FONT SIZE=2>in terms of what it does for a RAN we run into the problem of</FONT>
<BR><FONT SIZE=2>defining a RAN, which leads to debates over the mobility support</FONT>
<BR><FONT SIZE=2>in different RAN technologies, which iterates back over issues</FONT>
<BR><FONT SIZE=2>concerning the definition of the RAN boundaries.</FONT>
</P>

<P><FONT SIZE=2>Perhaps we can defined micromobility in terms of mobility between</FONT>
<BR><FONT SIZE=2>APs (and thus between an abstract Access Network which could</FONT>
<BR><FONT SIZE=2>represent a single wireless link, a wireless PAN, a wireless LAN, or a </FONT>
<BR><FONT SIZE=2>complete wireless network), without change in the MN IP address.</FONT>
</P>

<P><FONT SIZE=2>I think that at some point an informational ID may be required to</FONT>
<BR><FONT SIZE=2>describe micromobility for each wireless networking technology, and</FONT>
<BR><FONT SIZE=2>I suspect that each description will differ. The challenge will be to</FONT>
<BR><FONT SIZE=2>minimize the differences and ensure that they are options, not</FONT>
<BR><FONT SIZE=2>customizations.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Michael A. Ramalho [<A HREF="mailto:mramalho@cisco.com">mailto:mramalho@cisco.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Friday, January 05, 2001 4:58 PM</FONT>
<BR><FONT SIZE=2>&gt; To: James Kempf; neumiller@telocity.com; Pat.Calhoun@eng.sun.com;</FONT>
<BR><FONT SIZE=2>&gt; Kenward, Gary [WDLN2:AN10:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Cc: Madjid.Nakhjiri@motorola.com; campbell@comet.columbia.edu;</FONT>
<BR><FONT SIZE=2>&gt; James.Kempf@eng.sun.com; Phil_Neumiller@3Com.com; dblair@cisco.com;</FONT>
<BR><FONT SIZE=2>&gt; seamoby@diameter.org; cellularip@comet.columbia.edu</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [seamoby] Some thoughts and issues</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; At 01:25 PM 1/5/01 -0800, James Kempf wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt;Gary,</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;We still seem to be having a hard time defining what </FONT>
<BR><FONT SIZE=2>&gt; micro-mobility is in</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;the SeaMoby sense. Dare I ask what &quot;micromobility in the </FONT>
<BR><FONT SIZE=2>&gt; classic sense&quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;means?</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;This probably isn't going to help much, but we've defined </FONT>
<BR><FONT SIZE=2>&gt; micromobility</FONT>
<BR><FONT SIZE=2>&gt; &gt;in MWIF as mobility within a radio access network, and macromobility</FONT>
<BR><FONT SIZE=2>&gt; &gt;as between radio access networks.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; jak</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I think you are right. That definition might be OK for MWIF </FONT>
<BR><FONT SIZE=2>&gt; ... but ...</FONT>
<BR><FONT SIZE=2>&gt; what would you call a &quot;radio access network&quot; outside of that context?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; For example ... lets say I have an enterprise router with two </FONT>
<BR><FONT SIZE=2>&gt; types of radio</FONT>
<BR><FONT SIZE=2>&gt; system access links on it ... and my mobile decides to </FONT>
<BR><FONT SIZE=2>&gt; request a handoff</FONT>
<BR><FONT SIZE=2>&gt; between one wireless access link technology to the other ... but stays</FONT>
<BR><FONT SIZE=2>&gt; connected to the same router.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Would that handoff ... probably within one subnet ... but </FONT>
<BR><FONT SIZE=2>&gt; between two different</FONT>
<BR><FONT SIZE=2>&gt; types of radio access links ... be considered macromobility?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; That would be odd, indeed!</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I think IP-oriented people think of (micro)mobility w.r.t. </FONT>
<BR><FONT SIZE=2>&gt; subnets (or trust</FONT>
<BR><FONT SIZE=2>&gt; boundaries or administrative domains) without regard for the </FONT>
<BR><FONT SIZE=2>&gt; actual technology</FONT>
<BR><FONT SIZE=2>&gt; used on the access link. Conversely, cellular folks usually think of</FONT>
<BR><FONT SIZE=2>&gt; (macro)mobility</FONT>
<BR><FONT SIZE=2>&gt; between types of &quot;radio access networks&quot;.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; So what is our &quot;[micro|macro]mobility&quot; based on ... mobility </FONT>
<BR><FONT SIZE=2>&gt; between &quot;networks&quot;</FONT>
<BR><FONT SIZE=2>&gt; or between IP &quot;domains/subsets/domains/clouds&quot;?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; If we are talking IP mobility ... I'd suggest the latter ... </FONT>
<BR><FONT SIZE=2>&gt; but if I were</FONT>
<BR><FONT SIZE=2>&gt; a cellular IP guy ... I'd probably argue the former.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; This is why we need that problem definition .....</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Michael A. Ramalho, Ph.D.</FONT>
<BR><FONT SIZE=2>&gt; Office email: mramalho@cisco.com</FONT>
<BR><FONT SIZE=2>&gt; Personal email: mar42@cornell.edu</FONT>
<BR><FONT SIZE=2>&gt; Office: +1.732.449.5762</FONT>
<BR><FONT SIZE=2>&gt; Cell: +1.732.809.0188</FONT>
<BR><FONT SIZE=2>&gt; Pager: +1.800.365.4578</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C07774.4C4ED3C0--


From owner-seamoby@diameter.org  Fri Jan  5 20:56:50 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26846
	for <seamoby-archive@odin.ietf.org>; Fri, 5 Jan 2001 20:56:43 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f061E2409318
	for seamoby-list; Fri, 5 Jan 2001 17:14:02 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f061DxW09313
	for <seamoby@cdma-2000.org>; Fri, 5 Jan 2001 17:13:59 -0800
Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com;
          Fri, 5 Jan 2001 19:21:16 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBQM90>; Fri, 5 Jan 2001 19:21:18 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8AAF@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Karann Chew'" <k.chew@eim.surrey.ac.uk>,
        Peter Lei <peter.lei@motorola.com>
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] Re: [MOBILE-IP] Where can I find info on OBAST?
Date: Fri, 5 Jan 2001 19:21:16 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C07776.958A9EF0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C07776.958A9EF0
Content-Type: text/plain;
	charset="iso-8859-1"

Karann:

   I think that one answer to your question is that SeaMoby solutions
should enable the operator to "loosen" their control on the network.
This would enable true mobility into service environments not well
served by the cellular network approach (e.g. campuses, in building).

   This is internetworking, and, pardon me for saying it, but the role
and the power of IP technologies. Whether the cellular operators 
desire this feature, whether public wireless data remains the sole
purview of cellular networks or whether wireless PAN/LAN technologies 
become significant or even dominant public services is up to the market 
to decide.

Gary

> -----Original Message-----
> From: Karann Chew [mailto:k.chew@eim.surrey.ac.uk]
> Sent: Friday, January 05, 2001 6:25 PM
> To: Peter Lei
> Cc: seamoby@cdma-2000.org
> Subject: [seamoby] Re: [MOBILE-IP] Where can I find info on OBAST?
> 
> 
> 
> Yes I read about CARPS & OBAST some times ago.  But didn't keep close
> track on it, and didn't know and a Seamoby WG was formed.
> 
> Please allow me to ask a question...
> 
> The objective of Seamoby is to support seamless mobility and handover
> between diverse access technologies, including heterogenous 
> radio access
> techniques for wireless world.  My question is: how could 
> this idea fit
> into current cellular network, given that it's network 
> infrastructures are 
> closed-controlled by it's operator.  For example, could a mobile user
> currently being served by BS of Cellular_Operator_A 
> handovered to another
> BS of Cellular_Operator_B?  Or this is scenario is out of the scope?  
> 
> Another question:
> Am I right to say that micro mobility protocols (e.g HAWAII, CIP
> etc) should now be discussed here?
> 
> Thanks again.
> 
> 	Karann
> 
> ++++++++++++++++++++++++++++++++++++++++++
> Karann Chew 
> Mobile Communications Research Group
> Centre for Communication Systems Research   
> University of Surrey                 
> ++++++++++++++++++++++++++++++++++++++++++
> 
> 
> On Fri, 5 Jan 2001, Peter Lei wrote:
> 
> > It essentially came from the "seamless mobility"...  The history:
> > 
> > The OBAST concept was presented to a couple of AD's at 
> IETF-47 in Adelaide,
> > Australia by some interested parties (Phil Neumiller, me, 
> Randy Stewart, 
> > Qiaobing Xie).  It resulted in a CRAPS (Common Radio Access 
> Protocol Set)
> > BOF at IETF-48 in Pittsburgh, PA. where OBAST was presented 
> and hence the
> > drafts.  It "transformed" into the Seamoby WG just before 
> IETF-49 in San
> > Diego after discussions with the Mobile IP WG chairs and the IESG.
> > 
> > OBAST itself isn't really being discussed per se in the WG, 
> but the concepts
> > certainly are--
> >   seamless mobility across diverse access technologies 
> (wireless, wired)
> >   intelligence at the edges (like the internet)
> >   etc...
> > 
> > --peter
> > 
> > Karann Chew wrote:
> > > 
> > > Peter,
> > > 
> > > By the way, do you know what acronym "Seamoby" stands for?
> > > 
> > > ++++++++++++++++++++++++++++++++++++++++++
> > > Karann Chew
> > > Mobile Communications Research Group
> > > Centre for Communication Systems Research
> > > University of Surrey
> > > ++++++++++++++++++++++++++++++++++++++++++
> > > 
> > > On Fri, 5 Jan 2001, Karann Chew wrote:
> > > 
> > > >
> > > > Thanks Peter!
> > > >
> > > > > What specifically are you looking for??  (I am one of 
> the primary
> > > >
> > > > Nothing in specific, just want to know more about it.  
> I'm currently
> > > > involve in a project, something to do with 'All-IP 
> network'.  So, I want
> > > > to know more about OBAST, or any thing related to it.
> > > >
> > > > > There are currently only two IETF drafts published on 
> it-- it was
> > > >
> > > > Yes, they are only two, both pointed out the general 
> requirements.  No
> > > > concrete proposals yet.  I'm looking forward to seeing 
> more discussions.
> > > >
> > > > > There is an article detailing some more about OBAST 
> in the upcoming
> > > > > issue of
> > > > > Mobile Computing and Communications Review published by ACM's
> > > > > Sigmobile--
> > > > > I know this doesn't help you right now...  
> Unfortunately, it's the only
> > > > > article besides the drafts tha
> > > >
> > > > Thanks.  I will read the paper when it is available.
> > > >
> > > > Regards,
> > > >       Karann
> > > >
> > > > ++++++++++++++++++++++++++++++++++++++++++
> > > > Karann Chew
> > > > Mobile Communications Research Group
> > > > Centre for Communication Systems Research
> > > > University of Surrey
> > > > ++++++++++++++++++++++++++++++++++++++++++
> > > >
> > > >
> > > > On Fri, 5 Jan 2001, Peter Lei wrote:
> > > >
> > > > > What specifically are you looking for??  (I am one of 
> the primary authors).
> > > > >
> > > > > There are currently only two IETF drafts published on 
> it-- it was partially
> > > > > the driver for the IETF Seamoby WG.  Similar concepts 
> are being discussed
> > > > > there.
> > > > >
> > > > > There is an article detailing some more about OBAST 
> in the upcoming issue of
> > > > > Mobile Computing and Communications Review published 
> by ACM's Sigmobile--
> > > > > I know this doesn't help you right now...  
> Unfortunately, it's the only
> > > > > article besides the drafts that is "cleared" for publication.
> > > > >
> > > > > --peter
> > > > >
> > > > >
> > > > > Karann Chew wrote:
> > > > > >
> > > > > > Hi There!
> > > > > >
> > > > > > Could any body tell me where I can get more 
> information or discussion on
> > > > > > OBAST?  I could find only two drafts on it.
> > > > > >
> > > > > > Thanks in advance.
> > > > > >
> > > > > > Karann
> > > > >
> > > >
> > > >
> > 
> 
> 

------_=_NextPart_001_01C07776.958A9EF0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] Re: [MOBILE-IP] Where can I find info on OBAST?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Karann:</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; I think that one answer to your question is that SeaMoby solutions</FONT>
<BR><FONT SIZE=2>should enable the operator to &quot;loosen&quot; their control on the network.</FONT>
<BR><FONT SIZE=2>This would enable true mobility into service environments not well</FONT>
<BR><FONT SIZE=2>served by the cellular network approach (e.g. campuses, in building).</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; This is internetworking, and, pardon me for saying it, but the role</FONT>
<BR><FONT SIZE=2>and the power of IP technologies. Whether the cellular operators </FONT>
<BR><FONT SIZE=2>desire this feature, whether public wireless data remains the sole</FONT>
<BR><FONT SIZE=2>purview of cellular networks or whether wireless PAN/LAN technologies </FONT>
<BR><FONT SIZE=2>become significant or even dominant public services is up to the market </FONT>
<BR><FONT SIZE=2>to decide.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Karann Chew [<A HREF="mailto:k.chew@eim.surrey.ac.uk">mailto:k.chew@eim.surrey.ac.uk</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Friday, January 05, 2001 6:25 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Peter Lei</FONT>
<BR><FONT SIZE=2>&gt; Cc: seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: [seamoby] Re: [MOBILE-IP] Where can I find info on OBAST?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Yes I read about CARPS &amp; OBAST some times ago.&nbsp; But didn't keep close</FONT>
<BR><FONT SIZE=2>&gt; track on it, and didn't know and a Seamoby WG was formed.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Please allow me to ask a question...</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The objective of Seamoby is to support seamless mobility and handover</FONT>
<BR><FONT SIZE=2>&gt; between diverse access technologies, including heterogenous </FONT>
<BR><FONT SIZE=2>&gt; radio access</FONT>
<BR><FONT SIZE=2>&gt; techniques for wireless world.&nbsp; My question is: how could </FONT>
<BR><FONT SIZE=2>&gt; this idea fit</FONT>
<BR><FONT SIZE=2>&gt; into current cellular network, given that it's network </FONT>
<BR><FONT SIZE=2>&gt; infrastructures are </FONT>
<BR><FONT SIZE=2>&gt; closed-controlled by it's operator.&nbsp; For example, could a mobile user</FONT>
<BR><FONT SIZE=2>&gt; currently being served by BS of Cellular_Operator_A </FONT>
<BR><FONT SIZE=2>&gt; handovered to another</FONT>
<BR><FONT SIZE=2>&gt; BS of Cellular_Operator_B?&nbsp; Or this is scenario is out of the scope?&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Another question:</FONT>
<BR><FONT SIZE=2>&gt; Am I right to say that micro mobility protocols (e.g HAWAII, CIP</FONT>
<BR><FONT SIZE=2>&gt; etc) should now be discussed here?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thanks again.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Karann</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ++++++++++++++++++++++++++++++++++++++++++</FONT>
<BR><FONT SIZE=2>&gt; Karann Chew </FONT>
<BR><FONT SIZE=2>&gt; Mobile Communications Research Group</FONT>
<BR><FONT SIZE=2>&gt; Centre for Communication Systems Research&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; University of Surrey&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; ++++++++++++++++++++++++++++++++++++++++++</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; On Fri, 5 Jan 2001, Peter Lei wrote:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; It essentially came from the &quot;seamless mobility&quot;...&nbsp; The history:</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; The OBAST concept was presented to a couple of AD's at </FONT>
<BR><FONT SIZE=2>&gt; IETF-47 in Adelaide,</FONT>
<BR><FONT SIZE=2>&gt; &gt; Australia by some interested parties (Phil Neumiller, me, </FONT>
<BR><FONT SIZE=2>&gt; Randy Stewart, </FONT>
<BR><FONT SIZE=2>&gt; &gt; Qiaobing Xie).&nbsp; It resulted in a CRAPS (Common Radio Access </FONT>
<BR><FONT SIZE=2>&gt; Protocol Set)</FONT>
<BR><FONT SIZE=2>&gt; &gt; BOF at IETF-48 in Pittsburgh, PA. where OBAST was presented </FONT>
<BR><FONT SIZE=2>&gt; and hence the</FONT>
<BR><FONT SIZE=2>&gt; &gt; drafts.&nbsp; It &quot;transformed&quot; into the Seamoby WG just before </FONT>
<BR><FONT SIZE=2>&gt; IETF-49 in San</FONT>
<BR><FONT SIZE=2>&gt; &gt; Diego after discussions with the Mobile IP WG chairs and the IESG.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; OBAST itself isn't really being discussed per se in the WG, </FONT>
<BR><FONT SIZE=2>&gt; but the concepts</FONT>
<BR><FONT SIZE=2>&gt; &gt; certainly are--</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp; seamless mobility across diverse access technologies </FONT>
<BR><FONT SIZE=2>&gt; (wireless, wired)</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp; intelligence at the edges (like the internet)</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp; etc...</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; --peter</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Karann Chew wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Peter,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; By the way, do you know what acronym &quot;Seamoby&quot; stands for?</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; ++++++++++++++++++++++++++++++++++++++++++</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Karann Chew</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Mobile Communications Research Group</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Centre for Communication Systems Research</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; University of Surrey</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; ++++++++++++++++++++++++++++++++++++++++++</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; On Fri, 5 Jan 2001, Karann Chew wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Thanks Peter!</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; What specifically are you looking for??&nbsp; (I am one of </FONT>
<BR><FONT SIZE=2>&gt; the primary</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Nothing in specific, just want to know more about it.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; I'm currently</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; involve in a project, something to do with 'All-IP </FONT>
<BR><FONT SIZE=2>&gt; network'.&nbsp; So, I want</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; to know more about OBAST, or any thing related to it.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; There are currently only two IETF drafts published on </FONT>
<BR><FONT SIZE=2>&gt; it-- it was</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Yes, they are only two, both pointed out the general </FONT>
<BR><FONT SIZE=2>&gt; requirements.&nbsp; No</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; concrete proposals yet.&nbsp; I'm looking forward to seeing </FONT>
<BR><FONT SIZE=2>&gt; more discussions.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; There is an article detailing some more about OBAST </FONT>
<BR><FONT SIZE=2>&gt; in the upcoming</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; issue of</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; Mobile Computing and Communications Review published by ACM's</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; Sigmobile--</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; I know this doesn't help you right now...&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; Unfortunately, it's the only</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; article besides the drafts tha</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Thanks.&nbsp; I will read the paper when it is available.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Regards,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Karann</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; ++++++++++++++++++++++++++++++++++++++++++</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Karann Chew</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Mobile Communications Research Group</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Centre for Communication Systems Research</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; University of Surrey</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; ++++++++++++++++++++++++++++++++++++++++++</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; On Fri, 5 Jan 2001, Peter Lei wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; What specifically are you looking for??&nbsp; (I am one of </FONT>
<BR><FONT SIZE=2>&gt; the primary authors).</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; There are currently only two IETF drafts published on </FONT>
<BR><FONT SIZE=2>&gt; it-- it was partially</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; the driver for the IETF Seamoby WG.&nbsp; Similar concepts </FONT>
<BR><FONT SIZE=2>&gt; are being discussed</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; there.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; There is an article detailing some more about OBAST </FONT>
<BR><FONT SIZE=2>&gt; in the upcoming issue of</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; Mobile Computing and Communications Review published </FONT>
<BR><FONT SIZE=2>&gt; by ACM's Sigmobile--</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; I know this doesn't help you right now...&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; Unfortunately, it's the only</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; article besides the drafts that is &quot;cleared&quot; for publication.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; --peter</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; Karann Chew wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; Hi There!</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; Could any body tell me where I can get more </FONT>
<BR><FONT SIZE=2>&gt; information or discussion on</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; OBAST?&nbsp; I could find only two drafts on it.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; Thanks in advance.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; Karann</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C07776.958A9EF0--


From owner-seamoby@diameter.org  Sun Jan  7 02:19:33 2001
Received: from charizard.diameter.org (nobody@[24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05717
	for <seamoby-archive@odin.ietf.org>; Sun, 7 Jan 2001 02:19:32 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f076aIK10465
	for seamoby-list; Sat, 6 Jan 2001 22:36:18 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f076ZJW10460
	for <seamoby@diameter.org>; Sat, 6 Jan 2001 22:35:19 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <ZJFR8XQV>; Sun, 7 Jan 2001 00:43:05 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B7F@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: seamoby@diameter.org
Subject: [seamoby] Real-time Mobile IPv6 Framework nomenclature
Date: Sun, 7 Jan 2001 00:42:59 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk


I have reviewed draft-blair-rt-mobileipv6-seamoby-00.txt.

Possible Problem Statement:

"Seamoby will perform the Real-Time switching of packet flows for mobile
devices traveling within and across all types of IP networks"

We cannot guarantee seamless behavior where the new path is significantly
longer than the old path (i.e. switching to satellite).  Our switching will
always be "best effort".

My intent is to provide suggestions that are network neutral.  Referring to
the draft:

Policy Decision Point:

Responsible for: 

- access authorization 
- QoS authorization
- billing and settlement issues

Only wireless Billable Minutes business models require "billing and
settlement issues", or Accounting. Some wireless networks have EAA
(Encryption, Authentication, Authorization) in place of AAA.

Instead of talking about AAA:

Authorization
Authentication
Accounting ( billing of minutes )

We can talk about just AA.  This has the advantage of not having to transfer
the old state.  A mobile may choose to, under a reactive handoff not to
request that the old state be transferred when transferring only reliable
microflows.  Instead, it may choose to get AA at the new AP.  This will
result in faster handoffs for mobiles that don't need Accounting.  The old
AP and PDP can be notified after the handoff.

A PDP in a *particular network* is implemented in the Mobile.  I think we
want to say the AP's PDP since we are dealing with an edge network. 

Key Distribution Center:

I have a problem with a key distribution entity sending keys over a wireless
link.  Anyone nearby listening to the wireless transmission has the
potential to sniff the key.  There should be a requirement for the correct
level of encryption to be enabled before a key is sent, or a requirement
that a wired link be used.

The KDC may not exist in the Home Node.  The KDC in a *particular network*
is implemented in the Mobile.  A mobile with a KDC may have greater
authority than a mobile without an internal KDC.  

I think if we need to contact a particular entity for a particular service,
lets say an Accounting service for billable minutes, then this service would
have a KDC associated with it.  A *particular network* using a Billable
Minutes business model could make the Accounting service mandatory when its
interface is activated.

I am also thinking of a banking service like "Account Inquiry", or "Bill
Payment" provided by a bank.  A bank will want its own separate KDC.  When a
mobile requests the "Account Inquiry" service the bank's PDP would set KDC
policy.  Such as what level of encryption is mandatory, and how the keys
must be exchanged, etc.

What this suggests is that Accounting is an application layer service that
wireless networks using a Billable Minutes business model have placed lower
down in the stack.  By moving Accounting out the Seamoby protocol and
attaching it to a particular interface, we can make Seamoby more network
independant.  

Wake-up Sequence:

The problem with this sequence is that it does not require positive
confirmation of a mobile's existence after sleep mode is initiated.  This is
similar to a memory leak in an OS.  Failing, absent, or devices experiencing
interference are not detected.  Unused network resources are not recovered
in a well bounded time limit.  Since we want real-time performance, we want
all network activity to be well bounded.  Also, since only a downlink is
provided there is no way for the mobile to ever ask for an uplink.  The user
may want to send something: The sleep of death. :)

A better way is for the mobile to provide positive confirmation of its
operational status by transmitting a small ID, or Null packet at an agreed
upon time interval.  This is the only practical solution to the "Ships in
the Night" problem.


Uplink/Downlink:  Some networks have bi-directional links (Simplex).  Maybe,
upstream and downstream, or upflow and downflow are more link independent
terms.

Some new terms,

The issuing of a Switch Trigger is the point-of-no-return.  A switch timeout
will be started to ensure that the mobile has not failed, or lost
communications.  The mobile will select the moment such that end user
activity is least affected.  A Switch Trigger will start the critical
portion of a transfer process for the APs. 

In-order Switch Trigger:  A mobile requests that the old state be
transferred first before the new link is made active.  Reliable micro-flows
will be redirected in a timely manner.  Unreliable micro-flows will be
started at the new AP.  Proactive handoff trigger required.

Reliable Micro-flow Switch Trigger:  A mobile requests that the link be made
active first, and that the old state be terminated in a timely manner.
Reliable micro-flows will be redirected in a timely manner.  No unreliable
micro-flows exist.  Fast reactive handoff trigger possible.

Unreliable Micro-flow Switch Trigger:  A mobile requests that only
unreliable micro-flow context be transferred first, before a new link is
made active.  Reliable micro-flows will be re-directed in a timely manner.
Unreliable micro-flows will be started at the new AP.  Fast proactive
handoff trigger possible. 

Mobile Switch Start Command:  If the mobile sent the switch trigger the old
AP may provide switch parameters with this message.  If the AP sent the
switch trigger the mobile may combine the switch parameters with the switch
trigger message.

Mobile Switch Complete Event:  The Mobile indicates to new AP that the
Mobile switch is complete.  The new AP directs old AP to complete switch.

Old AP Switch Complete Event:  The old AP indicates to new AP that the old
AP switch is complete.

A Switch Trigger may be preceded by a Handoff Request (Proactive).
Depending on circumstances, or network type either the mobile, or AP may
perform a handoff decision followed by a Handoff Request.  A Handoff Request
causes both sides to make preparations for a transfer, knowing that the
issuing of a Handoff Cancel Request will abort the Handoff process.

When the old state is terminated, any "in flight" packets between the access
router and old AP are forwarded in a timely manner.  A mobile moving inside
of a network type (micro-mobility?) may not need the old state transferred
if it is using only reliable flows.  The access router may be asked to
re-associate the state for the mobile to the new AP.

Mobile Node IP Address:  An IPv6 address that is constant for the life of
the mobile.

Mobile Repository:  A fixed location where a Mobile Locator Table is stored
that maps Mobile Node IP addresses to Current Access Router IPv6 addresses.
Can be used to redirect microflows to mobile.  A Mobile Node Locator Entry
may appear in multiple repositories to efficiently route microflows, but the
Current Access Router IP address must be the same in all entries.  

Home Router: The router where a mobile could be attached as a stationary
device without a Locator Entry.  There will be at least one MR at the Home
router.  The Home router will know the location of all MRs by way of a MR
Locator Table.  There will be one and only one active MR Locator Table and
it will be located at the Home router.

Current Access Router:  The current access router will be the router located
nearest the current AP and old AP.  The AR will also have a Mobile Locator
Table.  The AR will notify the MR(s) of Access Router changes in a
transaction based manner.

Next Access Router:  The new access router will be the closest router
located between the current AP and the next AP.


- Kulwinder.


From owner-seamoby@diameter.org  Sun Jan  7 13:33:53 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09370
	for <seamoby-archive@odin.ietf.org>; Sun, 7 Jan 2001 13:33:52 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f07HRmc16257
	for seamoby-list; Sun, 7 Jan 2001 09:27:48 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f07HReW16252
	for <seamoby@cdma-2000.org>; Sun, 7 Jan 2001 09:27:40 -0800
Received: from carter-e0.ee.surrey.ac.uk ([131.227.86.16])
	by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1)
	id 14FImq-0005aG-00; Sun, 07 Jan 2001 16:35:16 +0000
Date: Sun, 7 Jan 2001 16:35:16 +0000 (GMT)
From: Karann Chew <k.chew@eim.surrey.ac.uk>
To: Gary Kenward <gkenward@nortelnetworks.com>
cc: "'Karann Chew'" <k.chew@eim.surrey.ac.uk>,
        Peter Lei <peter.lei@motorola.com>, seamoby@cdma-2000.org
Subject: RE: [seamoby] Re: [MOBILE-IP] Where can I find info on OBAST?
In-Reply-To: <13E2EF604DE5D111B2E50000F80824E8057A8AAF@zwdld001.ca.nortel.com>
Message-ID: <Pine.GSO.4.21.0101071615200.10888-100000@carter.ee.surrey.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk


Dear All,

Thanks Pat and Gary for answering!

I'm trying to go through all the mails in the WG.  Just read
the Description of Working Group again.  Please allow me to clear my
doubts.

One of the statements in the Description read :
<<The SeaMoby Working Group will develop a protocol to provide fast 
mobility _WITHIN_AN_ACCESS_NETWORK_, and thereby reduce the latency of the 
data/traffic flow to/from the mobile node. By improving the performance of
_INTRA-DOMAIN_ handoffs, the protocol will also help the overall latency 
of traffic using multiple, heterogeneous network access
infrastructures. The protocol will provide "micro-mobility", where
specialized signalling is used in an _ADMINISTRATIVE_DOMAIN_ to support
the movement of IP nodes across IP subnets.>>

This sound like to support mobility, and enhance handover performance
WITHIN A SAME DOMAIN.  Nevertheless, the access point could be of
different technology (diff radio access tech, or diff medium).  

So, may I ask the question again:
... For example, could a mobile user currently being served by BS of
Operator_A handovered to another nearby BS of Operator_B, given that
Operator_A and Operator_B manage their own network, and each has it own
Network ID, i.e. each is of different domain.  



Another question,
Micro-mobility generally refers to mobility withing the same domain.  How
about mobility among different SUBNET, but within the same domain?  
  

Hope that my question make sense to you all.

Cheers,
	Karann




> The objective of Seamoby is to support seamless mobility and handover
> between diverse access technologies, including heterogenous radio access
> techniques for wireless world.  My question is: how could this idea fit
> into current cellular network, given that it's network infrastructures
> are closed-controlled by it's operator.  For example, could a mobile
user
> currently being served by BS of Cellular_Operator_A handovered to
another
> BS of Cellular_Operator_B?  Or this is scenario is out of the scope?  
 
in scope.



On Fri, 5 Jan 2001, Gary Kenward wrote:

> Karann:
> 
>    I think that one answer to your question is that SeaMoby solutions
> should enable the operator to "loosen" their control on the network.
> This would enable true mobility into service environments not well
> served by the cellular network approach (e.g. campuses, in building).
> 
>    This is internetworking, and, pardon me for saying it, but the role
> and the power of IP technologies. Whether the cellular operators 
> desire this feature, whether public wireless data remains the sole
> purview of cellular networks or whether wireless PAN/LAN technologies 
> become significant or even dominant public services is up to the market 
> to decide.
> 
> Gary
--> 
> > -----Original Message-----
> > From: Karann Chew [mailto:k.chew@eim.surrey.ac.uk]
> > Sent: Friday, January 05, 2001 6:25 PM
> > To: Peter Lei
> > Cc: seamoby@cdma-2000.org
> > Subject: [seamoby] Re: [MOBILE-IP] Where can I find info on OBAST?
> > 
> > 
> > 
> > Yes I read about CARPS & OBAST some times ago.  But didn't keep close
> > track on it, and didn't know and a Seamoby WG was formed.
> > 
> > Please allow me to ask a question...
> > 
> > The objective of Seamoby is to support seamless mobility and handover
> > between diverse access technologies, including heterogenous 
> > radio access
> > techniques for wireless world.  My question is: how could 
> > this idea fit
> > into current cellular network, given that it's network 
> > infrastructures are 
> > closed-controlled by it's operator.  For example, could a mobile user
> > currently being served by BS of Cellular_Operator_A 
> > handovered to another
> > BS of Cellular_Operator_B?  Or this is scenario is out of the scope?  
> > 
> > Another question:
> > Am I right to say that micro mobility protocols (e.g HAWAII, CIP
> > etc) should now be discussed here?
> > 
> > Thanks again.
> > 
> > 	Karann
> > 
> > ++++++++++++++++++++++++++++++++++++++++++
> > Karann Chew 
> > Mobile Communications Research Group
> > Centre for Communication Systems Research   
> > University of Surrey                 
> > ++++++++++++++++++++++++++++++++++++++++++
> > 
> > 
> > On Fri, 5 Jan 2001, Peter Lei wrote:
> > 
> > > It essentially came from the "seamless mobility"...  The history:
> > > 
> > > The OBAST concept was presented to a couple of AD's at 
> > IETF-47 in Adelaide,
> > > Australia by some interested parties (Phil Neumiller, me, 
> > Randy Stewart, 
> > > Qiaobing Xie).  It resulted in a CRAPS (Common Radio Access 
> > Protocol Set)
> > > BOF at IETF-48 in Pittsburgh, PA. where OBAST was presented 
> > and hence the
> > > drafts.  It "transformed" into the Seamoby WG just before 
> > IETF-49 in San
> > > Diego after discussions with the Mobile IP WG chairs and the IESG.
> > > 
> > > OBAST itself isn't really being discussed per se in the WG, 
> > but the concepts
> > > certainly are--
> > >   seamless mobility across diverse access technologies 
> > (wireless, wired)
> > >   intelligence at the edges (like the internet)
> > >   etc...
> > > 
> > > --peter
> > > 
> > > Karann Chew wrote:
> > > > 
> > > > Peter,
> > > > 
> > > > By the way, do you know what acronym "Seamoby" stands for?
> > > > 
> > > > ++++++++++++++++++++++++++++++++++++++++++
> > > > Karann Chew
> > > > Mobile Communications Research Group
> > > > Centre for Communication Systems Research
> > > > University of Surrey
> > > > ++++++++++++++++++++++++++++++++++++++++++
> > > > 
> > > > On Fri, 5 Jan 2001, Karann Chew wrote:
> > > > 
> > > > >
> > > > > Thanks Peter!
> > > > >
> > > > > > What specifically are you looking for??  (I am one of 
> > the primary
> > > > >
> > > > > Nothing in specific, just want to know more about it.  
> > I'm currently
> > > > > involve in a project, something to do with 'All-IP 
> > network'.  So, I want
> > > > > to know more about OBAST, or any thing related to it.
> > > > >
> > > > > > There are currently only two IETF drafts published on 
> > it-- it was
> > > > >
> > > > > Yes, they are only two, both pointed out the general 
> > requirements.  No
> > > > > concrete proposals yet.  I'm looking forward to seeing 
> > more discussions.
> > > > >
> > > > > > There is an article detailing some more about OBAST 
> > in the upcoming
> > > > > > issue of
> > > > > > Mobile Computing and Communications Review published by ACM's
> > > > > > Sigmobile--
> > > > > > I know this doesn't help you right now...  
> > Unfortunately, it's the only
> > > > > > article besides the drafts tha
> > > > >
> > > > > Thanks.  I will read the paper when it is available.
> > > > >
> > > > > Regards,
> > > > >       Karann
> > > > >
> > > > > ++++++++++++++++++++++++++++++++++++++++++
> > > > > Karann Chew
> > > > > Mobile Communications Research Group
> > > > > Centre for Communication Systems Research
> > > > > University of Surrey
> > > > > ++++++++++++++++++++++++++++++++++++++++++
> > > > >
> > > > >
> > > > > On Fri, 5 Jan 2001, Peter Lei wrote:
> > > > >
> > > > > > What specifically are you looking for??  (I am one of 
> > the primary authors).
> > > > > >
> > > > > > There are currently only two IETF drafts published on 
> > it-- it was partially
> > > > > > the driver for the IETF Seamoby WG.  Similar concepts 
> > are being discussed
> > > > > > there.
> > > > > >
> > > > > > There is an article detailing some more about OBAST 
> > in the upcoming issue of
> > > > > > Mobile Computing and Communications Review published 
> > by ACM's Sigmobile--
> > > > > > I know this doesn't help you right now...  
> > Unfortunately, it's the only
> > > > > > article besides the drafts that is "cleared" for publication.
> > > > > >
> > > > > > --peter
> > > > > >
> > > > > >
> > > > > > Karann Chew wrote:
> > > > > > >
> > > > > > > Hi There!
> > > > > > >
> > > > > > > Could any body tell me where I can get more 
> > information or discussion on
> > > > > > > OBAST?  I could find only two drafts on it.
> > > > > > >
> > > > > > > Thanks in advance.
> > > > > > >
> > > > > > > Karann
> > > > > >
> > > > >
> > > > >
> > > 
> > 
> > 
> 



From owner-seamoby@diameter.org  Mon Jan  8 19:43:44 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19072
	for <seamoby-archive@odin.ietf.org>; Mon, 8 Jan 2001 19:43:43 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f08NmF518399
	for seamoby-list; Mon, 8 Jan 2001 15:48:15 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (omega.cisco.com [171.69.63.141])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f08NmDW18394
	for <seamoby@diameter.org>; Mon, 8 Jan 2001 15:48:13 -0800
Received: from gopal.cisco.com (dhcp-171-70-57-73.cisco.com [171.70.57.73])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA29654;
	Mon, 8 Jan 2001 14:55:55 -0800 (PST)
Message-Id: <4.3.2.7.2.20010108143755.00c7fe10@omega.cisco.com>
X-Sender: gdommety@omega.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 08 Jan 2001 14:41:29 -0800
To: seamoby-paging@egroups.com, James Kempf <James.Kempf@eng.sun.com>,
        James.Kempf@eng.sun.com, ramjee@dnrc.bell-labs.com
From: Gopal Dommety <gdommety@cisco.com>
Subject: Re: [seamoby-paging] RE: [seamoby] Some thoughts on paging
  problem
Cc: seamoby@diameter.org, Phil_Neumiller@3Com.com, seamoby-paging@egroups.com
In-Reply-To: <FC0292EA4D13D34EA2E5FC728D70A8E3078B3D@NEPTUNE.zucotto.com
 >
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-seamoby@diameter.org
Precedence: bulk

At 09:16 PM 20/12/00 -0500, Kulwinder Atwal wrote:


>> -----Original Message-----
>> From: Gopal Dommety [mailto:gdommety@cisco.com]
>> Sent: Wednesday, December 20, 2000 6:39 PM
>> To: James Kempf; James.Kempf@eng.sun.com; ramjee@dnrc.bell-labs.com
>> Cc: seamoby@diameter.org; Phil_Neumiller@3com.com;
>> seamoby-paging@egroups.com
>> Subject: Re: [seamoby] Some thoughts on paging problem
>> 
>> 
>> 
>> Proactive draft  works well in the case that the old FA 
>> knows where the mobile is moving to (i.e, the new FA).  
>> But this is not always the case.
>
>The only way to determine this is for the mobile to be forced to periodicaly
>transmit a small
>ID packet, or have the connection be terminated by the network.
>
>The network FAs would use the RSSI to determine where the mobile was headed.
>RSSI (Receive Signal Strength Indicator) is used to measure the RF power
>level of mobiles.
>  The FAs compare the results.  The mobile is moving toward the FA with the
>stronger 
>value.  The FA gets to service the mobile.

Two observations from what you are stating:

1. RSSI happens at L1 and L2 and FA and mobile IP stuff happens at L3
2. there are scenarios where AP (terminating the wireless L2) and FA could 
be over a routed cloud.

>This is already done in Cellular and Bluetooth.  No need to re-invent the
>wheel. 

You seem to be make some assumptions on the tight-coupledness of L2 and L3. this is not 
necessarly bad, but there is merit in leaving them loosely coupled or no coupling at all.

-gopal




>> 
>> -Gopal
>> 
>> At 12:40 PM 20/12/00 -0800, James Kempf wrote:
>> >Ram,
>> >
>> >The mechanism proposed in the draft does double duty. During 
>> an active
>> >call, it allows handoff of an RTP stream with minimal latency. If the
>> >mobile is dormant, it allows the network to track the mobile so that
>> >the mobile's CoA reflects its current location. Consequently, a 
>> >specialized paging mechanism is not needed.
>> >
>> >There might perhaps be some changes needed for IPv6 due to the need
>> >for authenticated binding updates, but I think a mechanism that
>> >allows the network to track the mobile, either through MIPv6 
>> CoA update
>> >or through standard routing table update, would be better than
>> >a specialized paging mechanism. 
>> >
>> >                jak
>> >
>> >>Date: Wed, 20 Dec 2000 20:33:17 +0000
>> >>From: Ramachandran Ramjee <ramjee@dnrc.bell-labs.com>
>> >>X-Accept-Language: en
>> >>MIME-Version: 1.0
>> >>To: James Kempf <James.Kempf@eng.sun.com>
>> >>CC: seamoby@diameter.org, Phil_Neumiller@3com.com, 
>> seamoby-paging@egroups.com
>> >>Subject: Re: [seamoby] Some thoughts on paging problem
>> >>Content-Transfer-Encoding: 7bit
>> >>
>> >>Hi James,
>> >>
>> >>James wrote..
>> >>> One could, I suppose, make an argument for
>> >>> having a specialized L3 mechanism participate in finding 
>> a dormant mobile, 
>> >but
>> >>> there ways to achieve this without a specialized mechanism, for
>> >>> example, pro-active handoff 
>> (draft-calhoun-mobileip-proactive-fa-03.txt).
>> >>
>> >>I think IP paging is exactly that - a specialized L3 mechanism 
>> >>for finding a dormant mobile. 
>> >>
>> >>If pro-active handoff solves this and is general enough, then that's
>> >>great.
>> >>
>> >>Cheers,
>> >>Ram
>> 
>
>-------------------------- eGroups Sponsor -------------------------~-~>
>eLerts
>It's Easy. It's Fun. Best of All, it's Free!
>http://click.egroups.com/1/9699/1/_/_/_/977365002/
>---------------------------------------------------------------------_->
>
>To unsubscribe from this group, send an email to:
>seamoby-paging-unsubscribe@egroups.com



From owner-seamoby@diameter.org  Tue Jan  9 09:57:04 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13066
	for <seamoby-archive@odin.ietf.org>; Tue, 9 Jan 2001 09:57:04 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f09Dr2R19514
	for seamoby-list; Tue, 9 Jan 2001 05:53:02 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f09Dr0W19509
	for <seamoby@cdma-2000.org>; Tue, 9 Jan 2001 05:53:00 -0800
Received: from carter-e0.ee.surrey.ac.uk ([131.227.86.16])
	by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1)
	id 14FyOS-00013J-00
	for seamoby@cdma-2000.org; Tue, 09 Jan 2001 13:00:52 +0000
Date: Tue, 9 Jan 2001 13:00:51 +0000 (GMT)
From: Karann Chew <k.chew@eim.surrey.ac.uk>
To: seamoby@cdma-2000.org
Subject: [seamoby] change of subnet==macro-mobility?
Message-ID: <Pine.GSO.4.21.0101091239100.11106-100000@carter.ee.surrey.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk


I'm not sure if I should post question like this to SeaMoby or 
SeaMoby-Micro-Mobility mailing list...  

Anyway, could anyone help me to understand...

Which of the following statement is true?

1. Movement that creates a change in subnet, but within the same
domain, is considered as micro-mobility (i.e. The network ID of new AP
does not change, but the subnet ID does).
This could happen when a user move out of his/her room, disconnected from
his WPAN room, and then reconnected to a WLAN in the building.  Given that
the WPAN and WLAN are of different subnet id, but both under the same
network id and the admin domain.

Or

2. A change in subnet id is treated the same as change in network id
or network domain.  This is considered as a macro-mobility and should be
handled by MIP.

I guess 2 is correct.  Could anyone clarify if my understanding is wrong.

Thanks in advance.

	Karann



From owner-seamoby@diameter.org  Tue Jan  9 11:53:22 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16330
	for <seamoby-archive@odin.ietf.org>; Tue, 9 Jan 2001 11:53:22 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f09Fgn819628
	for seamoby-list; Tue, 9 Jan 2001 07:42:49 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mailhost.abrandnewworld.se ([62.119.17.2])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f09FgkW19623
	for <seamoby@cdma-2000.org>; Tue, 9 Jan 2001 07:42:47 -0800
Received: from nthele ([192.168.9.194])
	by mailhost.abrandnewworld.se (8.8.8/8.8.5) with SMTP id PAA22994
	for <seamoby@cdma-2000.org>; Tue, 9 Jan 2001 15:43:32 +0100 (CET)
Received: by localhost with Microsoft MAPI; Tue, 9 Jan 2001 15:50:26 +0100
Message-ID: <01C07A53.E2A40C50.henrik.levkowetz@abrandnewworld.se>
From: Henrik Levkowetz <henrik.levkowetz@abrandnewworld.se>
To: "seamoby@cdma-2000.org" <seamoby@cdma-2000.org>
Subject: RE: [seamoby] change of subnet==macro-mobility?
Date: Tue, 9 Jan 2001 15:50:25 +0100
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Karann Chew wrote:
> 
> I'm not sure if I should post question like this to SeaMoby or 
> SeaMoby-Micro-Mobility mailing list...  
> 
> Anyway, could anyone help me to understand...
> 
> Which of the following statement is true?
> 
> 1. Movement that creates a change in subnet, but within the same
> domain, is considered as micro-mobility (i.e. The network ID of new AP
> does not change, but the subnet ID does).
> This could happen when a user move out of his/her room, disconnected from
> his WPAN room, and then reconnected to a WLAN in the building.  Given that
> the WPAN and WLAN are of different subnet id, but both under the same
> network id and the admin domain.
> 
> Or
> 
> 2. A change in subnet id is treated the same as change in network id
> or network domain.  This is considered as a macro-mobility and should be
> handled by MIP.
> 
> I guess 2 is correct.  Could anyone clarify if my understanding is wrong.

	Karann,

	I tend to agree with you, although I'm not sure that the working
group has a consensus on this.

	What complicates the question is, I think, that in order to provide
good seamless mobility, you may need support (e.g. for context transfer)
also in case 1.

	So my viewpoint is that 2 above defined micro-mobility, but
seamless mobility may require solutions which assists MIP in case 1.

	Other viewpoints?

		Henrik


From owner-seamoby@diameter.org  Tue Jan  9 16:01:00 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21347
	for <seamoby-archive@odin.ietf.org>; Tue, 9 Jan 2001 16:00:59 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f09JUH619956
	for seamoby-list; Tue, 9 Jan 2001 11:30:17 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f09JTlW19951
	for <seamoby@diameter.org>; Tue, 9 Jan 2001 11:29:47 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <CTQSVT3S>; Tue, 9 Jan 2001 13:37:41 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E322599D@NEPTUNE.zucotto.com>
From: Colin Elliott <celliott@zucotto.com>
To: seamoby-paging@egroups.com, James Kempf <James.Kempf@eng.sun.com>,
        James.Kempf@eng.sun.com, ramjee@dnrc.bell-labs.com
Cc: seamoby@diameter.org, Phil_Neumiller@3Com.com, seamoby-paging@egroups.com
Subject: Re: [seamoby-paging] RE: [seamoby] Some thoughts on paging proble
	m
Date: Tue, 9 Jan 2001 13:37:40 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

At 09:16 PM 20/12/00 -0500, Kulwinder Atwal wrote:


>> -----Original Message-----
>> From: Gopal Dommety [mailto:gdommety@cisco.com]
>> Sent: Wednesday, December 20, 2000 6:39 PM
>> To: James Kempf; James.Kempf@eng.sun.com; ramjee@dnrc.bell-labs.com
>> Cc: seamoby@diameter.org; Phil_Neumiller@3com.com;
>> seamoby-paging@egroups.com
>> Subject: Re: [seamoby] Some thoughts on paging problem
>> 
>> 
>> 
>> Proactive draft  works well in the case that the old FA 
>> knows where the mobile is moving to (i.e, the new FA).  
>> But this is not always the case.
>
>The only way to determine this is for the mobile to be forced to
periodicaly
>transmit a small
>ID packet, or have the connection be terminated by the network.
>
>The network FAs would use the RSSI to determine where the mobile was
headed.
>RSSI (Receive Signal Strength Indicator) is used to measure the RF power
>level of mobiles.
>  The FAs compare the results.  The mobile is moving toward the FA with the
>stronger 
>value.  The FA gets to service the mobile.

Two observations from what you are stating:

1. RSSI happens at L1 and L2 and FA and mobile IP stuff happens at L3
2. there are scenarios where AP (terminating the wireless L2) and FA could 
be over a routed cloud.

>This is already done in Cellular and Bluetooth.  No need to re-invent the
>wheel. 

You seem to be make some assumptions on the tight-coupledness of L2 and L3.
this is not 
necessarly bad, but there is merit in leaving them loosely coupled or no
coupling at all.

-gopal




>> 
>> -Gopal
>> 
>> At 12:40 PM 20/12/00 -0800, James Kempf wrote:
>> >Ram,
>> >
>> >The mechanism proposed in the draft does double duty. During 
>> an active
>> >call, it allows handoff of an RTP stream with minimal latency. If the
>> >mobile is dormant, it allows the network to track the mobile so that
>> >the mobile's CoA reflects its current location. Consequently, a 
>> >specialized paging mechanism is not needed.
>> >
>> >There might perhaps be some changes needed for IPv6 due to the need
>> >for authenticated binding updates, but I think a mechanism that
>> >allows the network to track the mobile, either through MIPv6 
>> CoA update
>> >or through standard routing table update, would be better than
>> >a specialized paging mechanism. 
>> >
>> >                jak
>> >
>> >>Date: Wed, 20 Dec 2000 20:33:17 +0000
>> >>From: Ramachandran Ramjee <ramjee@dnrc.bell-labs.com>
>> >>X-Accept-Language: en
>> >>MIME-Version: 1.0
>> >>To: James Kempf <James.Kempf@eng.sun.com>
>> >>CC: seamoby@diameter.org, Phil_Neumiller@3com.com, 
>> seamoby-paging@egroups.com
>> >>Subject: Re: [seamoby] Some thoughts on paging problem
>> >>Content-Transfer-Encoding: 7bit
>> >>
>> >>Hi James,
>> >>
>> >>James wrote..
>> >>> One could, I suppose, make an argument for
>> >>> having a specialized L3 mechanism participate in finding 
>> a dormant mobile, 
>> >but
>> >>> there ways to achieve this without a specialized mechanism, for
>> >>> example, pro-active handoff 
>> (draft-calhoun-mobileip-proactive-fa-03.txt).
>> >>
>> >>I think IP paging is exactly that - a specialized L3 mechanism 
>> >>for finding a dormant mobile. 
>> >>
>> >>If pro-active handoff solves this and is general enough, then that's
>> >>great.
>> >>
>> >>Cheers,
>> >>Ram
>> 
>
>-------------------------- eGroups Sponsor -------------------------~-~>
>eLerts
>It's Easy. It's Fun. Best of All, it's Free!
>http://click.egroups.com/1/9699/1/_/_/_/977365002/
>---------------------------------------------------------------------_->
>
>To unsubscribe from this group, send an email to:
>seamoby-paging-unsubscribe@egroups.com




From owner-seamoby@diameter.org  Tue Jan  9 20:22:05 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24106
	for <seamoby-archive@odin.ietf.org>; Tue, 9 Jan 2001 20:22:04 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0A0JdX20248
	for seamoby-list; Tue, 9 Jan 2001 16:19:39 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0A0JaW20243
	for <seamoby@diameter.org>; Tue, 9 Jan 2001 16:19:36 -0800
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id QAA07686 for <seamoby@diameter.org>; Tue, 9 Jan 2001 16:27:31 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA05730 for <seamoby@diameter.org>; Tue, 9 Jan 2001 16:27:31 -0700 (MST)]
Received: from ripcord756 (d50-497f.cig.mot.com [160.47.73.127]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58)
	id ZNMBN91W; Tue, 9 Jan 2001 17:24:12 -0600
From: "Ajoy Singh" <asingh1@email.mot.com>
To: "Gopal Dommety" <gdommety@cisco.com>, <seamoby-paging@egroups.com>,
        "James Kempf" <James.Kempf@eng.sun.com>, <James.Kempf@eng.sun.com>,
        <ramjee@dnrc.bell-labs.com>
Cc: <seamoby@diameter.org>, <Phil_Neumiller@3Com.com>,
        <seamoby-paging@egroups.com>
Subject: RE: [seamoby-paging] RE: [seamoby] Some thoughts on paging problem
Date: Tue, 9 Jan 2001 17:38:49 -0600
Message-ID: <NEBBIAJKILPAOLFLFNJOMEDDCGAA.asingh1@email.mot.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <4.3.2.7.2.20010108143755.00c7fe10@omega.cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello All,
Sorry, I have not followed all the emails exchanged in this context.
So my reply may be out of context here. But I have some comment about the
following statement. Please correct me if my understanding is wrong.
regards,
ajoy

> Proactive draft  works well in the case that the old FA
>>> knows where the mobile is moving to (i.e., the new FA).
>>> But this is not always the case.

<AS> I think that the proactive draft also works when new FA receives target
trigger during link layer handoff. I recollect reading somewhere that, in
802.11,
the new access network(AP) knows about the AP ID of the source AP during
link
layer handoff. So is it not possible to maintain a mapping of AP ID VS. FA
address at the target AP and use that information to initiate
target trigger required for proactive draft ?  Pl correct me if am wrong.
<AS>


>-----Original Message-----
>From: owner-seamoby@diameter.org [mailto:owner-seamoby@diameter.org]On
>Behalf Of Gopal Dommety
>Sent: Monday, January 08, 2001 4:41 PM
>To: seamoby-paging@egroups.com; James Kempf; James.Kempf@eng.sun.com;
>ramjee@dnrc.bell-labs.com
>Cc: seamoby@diameter.org; Phil_Neumiller@3Com.com;
>seamoby-paging@egroups.com
>Subject: Re: [seamoby-paging] RE: [seamoby] Some thoughts on paging
>problem
>
>
>At 09:16 PM 20/12/00 -0500, Kulwinder Atwal wrote:
>
>
>>> -----Original Message-----
>>> From: Gopal Dommety [mailto:gdommety@cisco.com]
>>> Sent: Wednesday, December 20, 2000 6:39 PM
>>> To: James Kempf; James.Kempf@eng.sun.com; ramjee@dnrc.bell-labs.com
>>> Cc: seamoby@diameter.org; Phil_Neumiller@3com.com;
>>> seamoby-paging@egroups.com
>>> Subject: Re: [seamoby] Some thoughts on paging problem
>>>
>>>
>>>
>>> Proactive draft  works well in the case that the old FA
>>> knows where the mobile is moving to (i.e, the new FA).
>>> But this is not always the case.
>>
>>The only way to determine this is for the mobile to be forced to
>periodicaly
>>transmit a small
>>ID packet, or have the connection be terminated by the network.
>>
>>The network FAs would use the RSSI to determine where the mobile
>was headed.
>>RSSI (Receive Signal Strength Indicator) is used to measure the RF power
>>level of mobiles.
>>  The FAs compare the results.  The mobile is moving toward the
>FA with the
>>stronger
>>value.  The FA gets to service the mobile.
>
>Two observations from what you are stating:
>
>1. RSSI happens at L1 and L2 and FA and mobile IP stuff happens at L3
>2. there are scenarios where AP (terminating the wireless L2) and FA could
>be over a routed cloud.
>
>>This is already done in Cellular and Bluetooth.  No need to re-invent the
>>wheel.
>
>You seem to be make some assumptions on the tight-coupledness of
>L2 and L3. this is not
>necessarly bad, but there is merit in leaving them loosely coupled
>or no coupling at all.
>
>-gopal
>
>
>
>
>>>
>>> -Gopal
>>>
>>> At 12:40 PM 20/12/00 -0800, James Kempf wrote:
>>> >Ram,
>>> >
>>> >The mechanism proposed in the draft does double duty. During
>>> an active
>>> >call, it allows handoff of an RTP stream with minimal latency. If the
>>> >mobile is dormant, it allows the network to track the mobile so that
>>> >the mobile's CoA reflects its current location. Consequently, a
>>> >specialized paging mechanism is not needed.
>>> >
>>> >There might perhaps be some changes needed for IPv6 due to the need
>>> >for authenticated binding updates, but I think a mechanism that
>>> >allows the network to track the mobile, either through MIPv6
>>> CoA update
>>> >or through standard routing table update, would be better than
>>> >a specialized paging mechanism.
>>> >
>>> >                jak
>>> >
>>> >>Date: Wed, 20 Dec 2000 20:33:17 +0000
>>> >>From: Ramachandran Ramjee <ramjee@dnrc.bell-labs.com>
>>> >>X-Accept-Language: en
>>> >>MIME-Version: 1.0
>>> >>To: James Kempf <James.Kempf@eng.sun.com>
>>> >>CC: seamoby@diameter.org, Phil_Neumiller@3com.com,
>>> seamoby-paging@egroups.com
>>> >>Subject: Re: [seamoby] Some thoughts on paging problem
>>> >>Content-Transfer-Encoding: 7bit
>>> >>
>>> >>Hi James,
>>> >>
>>> >>James wrote..
>>> >>> One could, I suppose, make an argument for
>>> >>> having a specialized L3 mechanism participate in finding
>>> a dormant mobile,
>>> >but
>>> >>> there ways to achieve this without a specialized mechanism, for
>>> >>> example, pro-active handoff
>>> (draft-calhoun-mobileip-proactive-fa-03.txt).
>>> >>
>>> >>I think IP paging is exactly that - a specialized L3 mechanism
>>> >>for finding a dormant mobile.
>>> >>
>>> >>If pro-active handoff solves this and is general enough, then that's
>>> >>great.
>>> >>
>>> >>Cheers,
>>> >>Ram
>>>
>>
>>-------------------------- eGroups Sponsor -------------------------~-~>
>>eLerts
>>It's Easy. It's Fun. Best of All, it's Free!
>>http://click.egroups.com/1/9699/1/_/_/_/977365002/
>>---------------------------------------------------------------------_->
>>
>>To unsubscribe from this group, send an email to:
>>seamoby-paging-unsubscribe@egroups.com
>



From owner-seamoby@diameter.org  Wed Jan 10 07:36:48 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14404
	for <seamoby-archive@odin.ietf.org>; Wed, 10 Jan 2001 07:36:48 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0AAd2J20912
	for seamoby-list; Wed, 10 Jan 2001 02:39:02 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0AAd0W20907
	for <seamoby@diameter.org>; Wed, 10 Jan 2001 02:39:00 -0800
Received: from esvir10nok.nokia.com (esvir10nokt.ntc.nokia.com [172.21.143.42])
	by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0A9kuc08091
	for <seamoby@diameter.org>; Wed, 10 Jan 2001 11:46:56 +0200 (EET)
Received: from esebh03nok.ntc.nokia.com (unverified) by esvir10nok.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tac158f2a5104f04403@esvir10nok.nokia.com>;
 Wed, 10 Jan 2001 11:46:45 +0200
Received: by esebh03nok with Internet Mail Service (5.5.2652.78)
	id <Z1JQHY0H>; Wed, 10 Jan 2001 11:46:15 +0200
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DF59E@eseis04nok>
From: john.loughney@nokia.com
To: gkenward@nortelnetworks.com, mramalho@cisco.com, James.Kempf@eng.sun.com,
        neumiller@telocity.com, Pat.Calhoun@eng.sun.com
Cc: Madjid.Nakhjiri@motorola.com, campbell@comet.columbia.edu,
        Phil_Neumiller@3Com.com, dblair@cisco.com, seamoby@diameter.org
Subject: RE: [seamoby] Some thoughts and issues
Date: Wed, 10 Jan 2001 11:46:12 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi all,

> I think IP-oriented people think of (micro)mobility w.r.t. 
> subnets (or trust 
> boundaries or administrative domains) without regard for the 
> actual technology 
> used on the access link. Conversely, cellular folks usually think of 
> (macro)mobility 
> between types of "radio access networks". 
> 
> So what is our "[micro|macro]mobility" based on ... mobility 
> between "networks" 
> or between IP "domains/subsets/domains/clouds"? 
> 
> If we are talking IP mobility ... I'd suggest the latter ... 
> but if I were 
> a cellular IP guy ... I'd probably argue the former. 

I think that we should define micromobility as mobility
within a subnet and/or domain.  Macromobility then would
be mobility between subnets and/or domains.

This may even work for cellular folks.  I think that many in the 
near future, many companies will be rolling out base stations
which support multiple radio technologies, so that clear
boundaries within cellular networks will blur as well.

best regards,
John


From owner-seamoby@diameter.org  Thu Jan 11 04:09:24 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27834
	for <seamoby-archive@odin.ietf.org>; Thu, 11 Jan 2001 04:09:23 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0B8HA922732
	for seamoby-list; Thu, 11 Jan 2001 00:17:10 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from clarinet.u-strasbg.fr (IDENT:root@clarinet.u-strasbg.fr [130.79.90.157])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0B8FtW22727
	for <seamoby@cdma-2000.org>; Thu, 11 Jan 2001 00:15:56 -0800
Received: from mobinet (mobinet.u-strasbg.fr [130.79.90.159])
	by clarinet.u-strasbg.fr (8.9.3/8.9.3) with SMTP id IAA30450
	for <seamoby@cdma-2000.org>; Thu, 11 Jan 2001 08:23:54 +0100
From: "Thomas Noel" <Thomas.Noel@dpt-info.u-strasbg.fr>
To: <seamoby@cdma-2000.org>
Subject: [seamoby] CFP : RSRCP Journal - Mobility and Internet
Date: Thu, 11 Jan 2001 08:17:57 +0100
Message-ID: <000201c07b9e$9f238bd0$9f5a4f82@ustrasbg.fr>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-seamoby@diameter.org
Precedence: bulk
X-MIME-Autoconverted: from 8bit to quoted-printable by charizard.diameter.org id f0B8HA922732
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA27834

                 [Apologies if you receive multiple copies.]

                          CALL for PAPERS
                           SPECIAL ISSUE
                       MOBILITY AND INTERNET
                         of  RSRCP Journal
             http://www-r2.u-strasbg.fr/rsrcp/mintcfp.html


The RSRCP  journal, which  is now  specialized on  thematic issues on
Network and Distributed System is pleased to announce a special issue
on "Mobility and  Internet". This special  issue is sponsored by IEEE
Distributed Systems and the French IEEE Computer Chapter.

Wireless mobile access to the Internet will add new dimensions to the
way we access information and communicate. Currently, several network
protocols  are  being  studied  to  maintain communication between  a
mobile  host  and   its   correspondents  during  the  mobile  host's
movements. This  special  issue  is  devoted  to  the presentation of
recent research on  network  protocols and services  for mobile hosts
and wireless communication on the Internet.

We solicit high quality papers reporting original work in theoretical
or experimental  research. Topics  of  interest include, but  are not
limited to the following :

-  Ad hoc networks
-  Cellular IP networks
-  Distributed system aspects of mobile systems
-  Handoffs in IP networks
-  Header compression in wireless networks
-  Hierarchical mobility
-  IP-based third generation mobile and wireless networks
-  Micro-mobility architectures and protocols
-  Multicast communications for mobile hosts
-  Mobility and IPv6
-  Mobile management
-  Network protocols for mobile nodes
-  QoS in a wireless/mobile environment
-  Security and authentication
-  Service location in wireless environnement
-  Wireless LAN

Important dates:
1. Submission deadline: June 30, 2001;
2. Notifications to the authors: September, 30, 2001;
3. Publication : December 2001;

Submissions: Contributions  should  follow the instructions  and  the
format of the journal edited by Hermes.
(see http://www-r2.u-strasbg.fr/rsrcp/authorsguidelines.pdf)

Contributions  should  be original ones and should not be longer than
25  pages. Submissions  should  be  forwarded  to  the  Guest Editors
(rsrcp@clarinet.u-strasbg.fr - PS or PDF format, compressed).

Guest Editors :

            Thomas Noel                          Andras Valko

  Universite Louis Pasteur - LSIIT	          Ericsson Research
Pole API - Boulevard Sébastien Brant          Traffic Laboratory
        F- 67400 - Illkirch              H-1037 Budapest, Laborc u 1.
              France                               Hungary



Editorial Board :

Scott Corson                            Francis Dupont
Flarion Technologies                    ENST - Bretagne
USA                                     France

Philip Eardley                          Andras Farago
British Telecom                         University of Texas - Dallas
UK                                      USA

Phil Neumiller                          Thomas Noel
3Com                                    LSIIT
USA                                     France

Hesham Soliman                          Tapio Suihko
Ericsson                                VTT Technical Research Center
Australia                               Finland

C.K. Toh                                Michel Trehel
Georgia Institute of Technology         Universite de Franche-Comte
USA                                     France

Andras Valko
Ericsson
Hungary

--
NOEL Thomas - ULP/LSIIT
Thomas.Noel@dpt-info.u-strasbg.fr
http://www-r2.u-strasbg.fr/~noel
tel: (33) 03 88 65 55 03 - fax: 03.88.65 55 01



From owner-seamoby@diameter.org  Thu Jan 11 18:47:53 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16551
	for <seamoby-archive@odin.ietf.org>; Thu, 11 Jan 2001 18:47:52 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0BMvro24122
	for seamoby-list; Thu, 11 Jan 2001 14:57:53 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0BMvpW24117
	for <seamoby@cdma-2000.org>; Thu, 11 Jan 2001 14:57:51 -0800
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA10957
	for <seamoby@cdma-2000.org>; Thu, 11 Jan 2001 14:05:52 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA28898
	for <seamoby@cdma-2000.org>; Thu, 11 Jan 2001 14:05:51 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA27507
	for <seamoby@cdma-2000.org>; Thu, 11 Jan 2001 14:05:50 -0800 (PST)
Date: Thu, 11 Jan 2001 14:02:12 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: [seamoby] Majordomo bug?
To: seamoby@cdma-2000.org
Message-ID: <Roam.SIMC.2.0.6.979250532.2226.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

All,

It looks as if a bug in Majordomo is causing some old mail to be resent. I am
looking into this, and I appologize for the inconvenience...

PatC



From owner-seamoby@diameter.org  Thu Jan 11 19:15:43 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16696
	for <seamoby-archive@odin.ietf.org>; Thu, 11 Jan 2001 19:15:41 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0BNTl624165
	for seamoby-list; Thu, 11 Jan 2001 15:29:47 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0BNTiW24160
	for <seamoby@cdma-2000.org>; Thu, 11 Jan 2001 15:29:44 -0800
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA20992
	for <seamoby@cdma-2000.org>; Thu, 11 Jan 2001 14:37:43 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA08886
	for <seamoby@cdma-2000.org>; Thu, 11 Jan 2001 14:37:39 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA29079
	for <seamoby@cdma-2000.org>; Thu, 11 Jan 2001 14:37:37 -0800 (PST)
Date: Thu, 11 Jan 2001 14:33:59 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: [seamoby] action item: definition of context transfer (Fwd)
To: seamoby@cdma-2000.org
In-Reply-To: "Your message with ID" <13E2EF604DE5D111B2E50000F80824E805B22528@zwdld001.ca.nortel.com>
Message-ID: <Roam.SIMC.2.0.6.979252439.8479.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

>----------------Begin Forwarded Message----------------<

Date: Wed, 10 Jan 2001 14:50:14 -0500
From: "Hamid Syed" <hmsyed@nortelnetworks.com>
Subject: action item: definition of context transfer
To: "'Patrice Calhoun'" <Pat.Calhoun@eng.sun.com>

Hi Pat,

I tried to post the "context transfer denition" (an action item for me ) but
unable to do that..There is some problem with the Nortel's server. I dont
know how long that problem would take to solve. Can i request you to post
the attached text to context transfer design team for discussion. I would
appreciate that.

regards

Hamid Syed
****************************************************************************
***********************************

Hi,

Here sre some thoughts on "definition of context transfer: problem
statement". I tried to focus only on the issues that are related to context
transfer, assuming that the other part of the overall problem i.e. "the
context information identification and collection" has already been taken
care. So it assumes that the context information is collected and maintained
by a "single functional and physical" entity in the network and this entity
would be responsible for distribution of the context information as well

Feel free to post your comments

- Hamid Mahmood Syed

******************************************************
The context transfer is a mechanism (or a collection of meachanisms) after
completion of which the targeted entity(ies) (the access router) establishes
sufficient conditions to support the microflow(s) of a roaming mobile
without disrupting the service level. The context transfer does not
guarantee that the actual microflows would also be handed over to any or all
of the entities (access routers) that receives the context information. The
activity of defining a seamless context transfer may involve the following
issues to resolve;

1. selection of a generic architecture for context transfer
Two architectures can be discussed here: Centralized Vs Distributed

The first approach assumes a single central entity in the network or in a
defined domain that maintains the updated context information on behalf of a
set of access routers and is also responsible for distributing it amongst
the potential receivers. This role can be applied. for example, to the
access network gateway, an entity like a policy server or an elected access
router itself. This approach may suffer with scalability issues as the
number of microflow information per mobile per access router could be a very
large data to process and transfer in real-time with minimum delays

The second approach distributes the role of context maintainance and
distribution to the access routers itself. This approach seems to be more
appropriate as the access routers hold most of the context information (QoS,
Policy etc). Moreover, the access router is responsible for the context
information or the microflows of the mobiles that are connected thorugh them
which is a scalable 

2.  Defining the sender and the potential receiver(s) of the context
information and "events" that enable access routers become the members of
one "context set or group"
A mobile may have radio connectivity (at least it may receive RF signals)
from more than a single AP. The case where the APs are connected to the same
access router AR, no context transfer is required but when the potential APs
are connected to different ARs, the access routers may expect the mobile's
QoS sessions to arrive. These access routers, therefore, become the
potential receivers of the context information. A "context set" can be
defined as the set of potential access routers in the network that have, or
need to have, the context information related to a mobile. There are few
issues to resolve in the 'dynamic' formation of a context set;

-The addition and deletion of the members to a context set: This could be
triggered by certain network events. These events may be network
policy/configuration conditions that dictate the access routers to join a
context set or could be an event generated by the mobile's movement
prediction that dictates an access router to become the member of a context
set. 
- How does a (potential) new member identify the context set associated with
the mobile?: This requires an 'identifier' for each context set per mobile
and the information of the identifier should be propagated to any potential
member of the context set

3. Transfering the context information
- How does a new member of a context set would know about the sender of the
context?: The context information of the mobile are maintained by some
access router in the network or in other words, there is one potential
sender per context set. The new member need to know who to contact (within
the context set) in order to retrieve the current context. 
-When the context information be transfered?: Two possible approaches are
"reactive" and "proactive or make-before-break". In the later approach, the
context information is transfered to any new member as soon as it joins the
context set irrespective of the fact that the mobile may not choose the
access router for data connectivity. 
- How could any updates in the context be propagated to the members of the
context set and probably any associated events that trigger the context
update need to be understood.

4. Per packet or real-time context information transfer
There are pieces of information that an access router calculates and
maintains on a per packet basis. Metering in a diffserv-enabled router is
one example of such an information. The context transfer solution must
address how and when the per packet information could be transfered between
the access routers and what are the trade offs. For example, for a proactive
case, the transfered metering information may become irrelevantor obselete
at the new access router because of the instant of it was last updated and
the time when the router really needs this information could be large
enough. Even for a reactive transfer mode, by the time the information is
propagated to the new access router , it may become obselete or irrelevant. 

Conclusion:
In order to enable a seamless context transfer, any necessary
mechanisms/protocols are required to answer the issues listed above. 



>----------------End Forwarded Message----------------<



From owner-seamoby@diameter.org  Fri Jan 12 08:14:19 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08190
	for <seamoby-archive@odin.ietf.org>; Fri, 12 Jan 2001 08:14:12 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0CBxXw24666
	for seamoby-list; Fri, 12 Jan 2001 03:59:33 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from artemis.shef.ac.uk (artemis.shef.ac.uk [143.167.2.11])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0CBvnW24661
	for <seamoby@diameter.org>; Fri, 12 Jan 2001 03:57:49 -0800
Received: from [143.167.1.9] (helo=mailhub1.shef.ac.uk)
	by artemis.shef.ac.uk with esmtp (Exim 3.16 #2)
	id 14H1s1-0000f8-00; Fri, 12 Jan 2001 10:55:45 +0000
Received: from ridingwood.shef.ac.uk ([143.167.59.249])
	by mailhub1.shef.ac.uk with esmtp (Exim 3.16 #1)
	id 14H1s0-00043P-00; Fri, 12 Jan 2001 10:55:44 +0000
Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48);
    12 Jan 01 10:55:44 +0000
Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 12 Jan 01 10:55:33 +0000
Received: from Mobile1 (143.167.59.146) by ridingwood.shef.ac.uk (Mercury 1.48);
    12 Jan 01 10:55:25 +0000
Message-ID: <013401c07c85$b7962960$923ba78f@Mobile1>
Reply-To: "cnyap" <cny@ieee.org>
From: "cnyap" <cny@dcs.shef.ac.uk>
To: "Kumarendra Sivarajah" <ks51@ukc.ac.uk>,
        "Praveen Muley" <p_muley@yahoo.com>,
        "Xingang Liang" <liangxg@catt.ac.cn>,
        "Shahrier, Sharif M." <Sharif.Shahrier@interdigital.com>,
        <jtphilli@alpha.engr.twsu.edu>,
        "Iyer, Prakash" <prakash.iyer@intel.com>,
        "Kulwinder Atwal" <kulwinder.atwal@herc.zucotto.com>,
        "Lee, Jiwoong" <porce@kaist.ac.kr>,
        "Larry McFarland" <yylarry@lerc.nasa.gov>, <ccfoo@hawk.ee.nus.edu.sg>,
        "Brenda" <ybrenda@STARNET.GOV.SG>,
        "Coulibaly Yahaya" <coulibaly@excite.com>
Cc: <matthias_kraner@hotmail.com>, "Dave Ludlam" <Dave.Ludlam@marconi.com>,
        "MIP List" <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>,
        <seamoby@diameter.org>
Subject: [seamoby] draft-cnyap-iip-02.txt
Date: Fri, 12 Jan 2001 10:52:11 -0000
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0130_01C07C85.B77497A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Scanner: exiscan@artemis *14H1s1-0000f8-00* http://duncanthrax.net/exiscan/
Sender: owner-seamoby@diameter.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0130_01C07C85.B77497A0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0131_01C07C85.B77497A0"


------=_NextPart_001_0131_01C07C85.B77497A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

A New Internet-Draft is available from the on-line Internet-Drafts =
directories.

        Title            : Itinerant Internet Protocol
        Author(s)    : Chern Nam Yap et al.
        Filename     : draft-cnyap-iip-02.txt
        Pages          : 45
        Date            : 10-Jan-01

This document specifies a protocol that allows any IP node to
communicate with other IP nodes in the mobile environment without any
fundamental changes to TCP/IP. Any mobile aware nodes are able to
communicate with one another with standard IP routing. Mobile
awareness is achieved by means of address updates through a query
mechanism. Backward compatibility capability is supported via the
means of one or more anchoring points that are put in place.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-cnyap-iip-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the =
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-cnyap-iip-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-cnyap-iip-02.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail =
readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


------=_NextPart_001_0131_01C07C85.B77497A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4207.2601" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>A New=20
Internet-Draft is available from the on-line Internet-Drafts=20
directories.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;Itinerant Internet =
Protocol<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Author(s)&nbsp;&nbsp;&nbsp; :&nbsp;Chern Nam Yap&nbsp;et=20
al.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Filename&nbsp;&nbsp;&nbsp;&nbsp; :=20
draft-cnyap-iip-02.txt<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Pages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;45<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =

10-Jan-01<BR><BR>This document specifies a protocol that allows any IP =
node=20
to<BR>communicate with other IP nodes in the mobile environment without=20
any<BR>fundamental changes to TCP/IP. Any mobile aware nodes are able=20
to<BR>communicate with one another with standard IP routing. =
Mobile<BR>awareness=20
is achieved by means of address updates through a query<BR>mechanism. =
Backward=20
compatibility capability is supported via the<BR>means of one or more =
anchoring=20
points that are put in place.<BR><BR>A URL for this Internet-Draft=20
is:<BR></FONT><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-cnyap-iip-02.txt"><FONT=
=20
face=3D"Times New Roman"=20
size=3D3>http://www.ietf.org/internet-drafts/draft-cnyap-iip-02.txt</FONT=
></A><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-appli=
cability-04.txt"></A><BR><BR><FONT=20
face=3D"Times New Roman" size=3D3>Internet-Drafts are also available by =
anonymous=20
FTP. Login with the username<BR>"anonymous" and a password of your =
e-mail=20
address. After logging in,<BR>type "cd internet-drafts" and=20
then<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "get=20
draft-cnyap-iip-02.txt".<BR><BR>A list of Internet-Drafts directories =
can be=20
found in<BR></FONT><A href=3D"http://www.ietf.org/shadow.html"><FONT=20
face=3D"Times New Roman"=20
size=3D3>http://www.ietf.org/shadow.html</FONT></A><BR><FONT=20
face=3D"Times New Roman" size=3D3>or </FONT><A=20
href=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt"><FONT face=3D"Times =
New Roman"=20
size=3D3>ftp://ftp.ietf.org/ietf/1shadow-sites.txt</FONT></A><BR><BR><FON=
T=20
face=3D"Times New Roman" size=3D3>Internet-Drafts can also be obtained =
by=20
e-mail.<BR><BR>Send a message =
to:<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</FONT><A href=3D"mailto:mailserv@ietf.org"><FONT face=3D"Times New =
Roman"=20
size=3D3>mailserv@ietf.org</FONT></A><FONT face=3D"Times New Roman" =
size=3D3>.<BR>In=20
the body type:<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "FILE=20
/internet-drafts/draft-cnyap-iip-02.txt".<BR><BR>NOTE:&nbsp;&nbsp; The =
mail=20
server at ietf.org can return the document=20
in<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIME-encoded form by =
using the=20
"mpack" utility.&nbsp; To use =
this<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
feature, insert the command "ENCODING mime" before the=20
"FILE"<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command.&nbsp; To =
decode=20
the response(s), you will need "munpack"=20
or<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a MIME-compliant mail=20
reader.&nbsp; Different MIME-compliant mail=20
readers<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exhibit different=20
behavior, especially when dealing=20
with<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "multipart" MIME =
messages=20
(i.e. documents which have been=20
split<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; up into multiple =
messages),=20
so check your local documentation=20
on<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; how to manipulate these =

messages.<BR><BR><BR>Below is the data which will enable a MIME =
compliant mail=20
reader<BR>implementation to automatically retrieve the ASCII version of=20
the<BR>Internet-Draft.</FONT><BR></FONT></DIV></BODY></HTML>

------=_NextPart_001_0131_01C07C85.B77497A0--

------=_NextPart_000_0130_01C07C85.B77497A0
Content-Type: text/plain;
	name="draft-cnyap-iip-02.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-cnyap-iip-02.txt"
Content-Transfer-Encoding: 7bit

Network Working Group                                    Chern Nam Yap
Internet Draft                                         Matthias Kraner
<draft-cnyap-iip-02.txt>                       University of Sheffield
                                                                      
                                                        Srba Cvetkovic
                                                                Logica
                                                       10 January 2000

                      Itinerant Internet Protocol

Status of this memo
This document is an Internet-Draft and is in full conformance with all
provisions of section 10 of RFC 2026.

Internet Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet Drafts.

Internet Drafts are draft documents, valid for maximum of six months,
and may be updated, replaced, or obsolete by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress".

The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/lid-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ieft.org/shadow.html

Abstract

This document specifies a protocol that allows any IP node to
communicate with other IP nodes in the mobile environment without any
fundamental changes to TCP/IP. Any mobile aware nodes are able to
communicate with one another with standard IP routing. Mobile
awareness is achieved by means of address updates through a query
mechanism. Backward compatibility capability is supported via the
means of one or more anchoring points that are put in place.












Chern Nam Yap et al.      Expires 10 July 2001                  Page i
Internet Draft        Itinerant Internet Protocol      10 January 2000

                                Contents

Status of This Memo                                                 i

Abstract                                                            i

 1. Introduction                                                    1

 2. Comparison with Mobile IP for IPv4                              2

 3. Terminology                                                     4
     3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 4
     3.2. Itinerant Internet Protocol Terms . . . . . . . . . . . . 4
     3.3. Specification Language  . . . . . . . . . . . . . . . . . 6

 4. Overview of Itinerant Internet Protocol                         7
     4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 7
     4.2. Short Circuit Mechanism . . . . . . . . . . . . . . . . . 9
     4.2. Itinerant Internet Protocol Signalling  . . . . . . . . .10
     4.3. IPSec Requirements for Binding Updates and Binding
          Acknowledgement . . . . . . . . . . . . . . . . . . . . .11
     4.4. Conceptual Data Structures  . . . . . . . . . . . . . . .11
     4.5. Binding Management  . . . . . . . . . . . . . . . . . . .14

5. Itinerant Internet Protocol Signalling Message Type  . . . . . .15
     5.1. Binding Update packet . . . . . . . . . . . . . . . . . .15
     5.2. Binding Acknowledgement packet  . . . . . . . . . . . . .18
     5.3. Binding Request packet  . . . . . . . . . . . . . . . . .20

6. Requirements for IP Nodes                                       22
     6.1. Requirements for All Mobile Aware Nodes . . . . . . . . .22
     6.2. Requirements for Base Home Register . . . . . . . . . . .22
     6.3. Requirements for Temporary Visit Register . . . . . . . .23
     6.4. Requirements for Near Correspondent Register  . . . . . .24

7. Correspondent Node Operation                                    25
     7.1. Receiving Binding Updates . . . . . . . . . . . . . . . .25
     7.2. Request to Cache a Binding  . . . . . . . . . . . . . . .26
     7.3. Sending Binding Acknowledgements  . . . . . . . . . . . .26
     7.4. Sending Binding Requests  . . . . . . . . . . . . . . . .27
     7.5. Cache Replacement Policy  . . . . . . . . . . . . . . . .27
     7.6. Sending Packet to a Mobile Node . . . . . . . . . . . . .28

8. Base Home Register Operation                                    29
     8.1. Co-located Address Registration . . . . . . . . . . . . .29
     8.2. Intercepting Packets for a Mobile Node  . . . . . . . . .30
     8.3. Tunnelling Intercepted Packets to a Mobile Node . . . . .30

Chern Nam Yap             Expires 10 July 2001                 Page ii
Internet Draft        Itinerant Internet Protocol      10 January 2000

9. Temporary Visit Register Operation                              31
     9.1. Co-located Address Registration . . . . . . . . . . . . .31
     9.2. Intercepting Packets for a Mobile Node  . . . . . . . . .32

10. Near Correspondent Register Operation                          33
     10.1. Near Correspondent Registration  . . . . . . . . . . . .33
     10.2. Intercepting Packets for a Mobile Node . . . . . . . . .34
     10.3. Tunnelling Intercepted Packets to a Mobile Node  . . . .34

11. Mobile Node Operation                                          35
     11.1. Sending Packets While Away from Home . . . . . . . . . .35
     11.2. Receiving Packets While Away from Home . . . . . . . . .35
     11.3. Movement Detection . . . . . . . . . . . . . . . . . . .35
     11.4. Sending Binding Updates to the Base Home Register  . . .36
     11.5. Sending Binding Updates to the Temporary Visit Register.37
     11.6. Sending Binding Updates to the Near Correspondent Visit
           Register . . . . . . . . . . . . . . . . . . . . . . . .37
     11.7. Sending Binding Updates to Correspondent Nodes . . . . .38
     11.8. Retransmit Binding Updates . . . . . . . . . . . . . . .39
     11.9. Receiving Binding Acknowledgements . . . . . . . . . . .39
     11.10. Routing Multicast Packets . . . . . . . . . . . . . . .40

12. Protocol Constants                                             42

13. IANA Considerations                                            43

References                                                         44

Authors' Addresses                                                 45



















Chern Nam Yap             Expires 10 July 2001                Page iii
Internet Draft        Itinerant Internet Protocol      10 January 2000

1. Introduction

This document specifies a protocol that allows any IP node to
communicate with any other IP node in the mobile environment with
minimum changes to TCP/IP. Without mobility awareness or mobility
management on an IP machine, communicating would not be possible when
either side changes IP subnets. This is because current IP routing is
subnet prefix based and not Host based. In order to allow
communication in spite of the move, address updating to all sides of
the communication is required. This allows communication in this
scenario to be unaffected. Such a scheme is defined as a protocol
known as "Itinerant Internet Protocol" (IIP).

- In the basic scheme, all nodes are mobile aware. The initialising
node MUST send a query for the destination node's latest address. In
order not to incur any delay, data is sent immediately after the query
has been sent. The query SHOULD be responded to and the initialising
node SHOULD reconstruct the data packet destination address with the
latest information to send to the mobile node. Moreover, data
transmission and subsequent updates of address MAY be multi-homed. All
data traffic is pure standard IP routing.

- In the backward compatibility scheme where the correspondent node is
not mobile aware, there are two cases of communication.

Case 1
The initialising node is the mobile node. When the mobile node leaves
a particular subnet and the correspondent node sends data to the
mobile node, the previous subnet's anchoring point SHOULD forward all
the packets to the mobile node.

Case 2
The initialising node is the correspondent node. The mobile node's
home anchoring point SHOULD always first forward all the packets to
the mobile node. If a mobile aware anchoring point is discovered
between correspondent node and the home anchoring point, this mobile
aware anchoring point will the forward the packets to the mobile node.
In order to support ingress filtering, in the reverse traffic (from
the mobile node to the correspondent node) will still done through the
home anchoring point.

IIP is suitable for mobility across both homogenous and heterogeneous
media. One can think that IIP is a solution to the 3G IP mobility
problems as it is designed to do so.




Chern Nam Yap             Expires 10 July 2001                  Page 1
Internet Draft        Itinerant Internet Protocol      10 January 2000

2. Comparison with Mobile IP

IIP is designed to work across both IPv4 and IPv6. IIP is situated at
a layer between TCP/IP and applications. This layer is known as
Management Layer, and because of this IIP reduces the need to concern
or to do any harm to the progression of IP development. The
differences between Mobile IP and IIP are described as follows:

- Diversion is a MUST for IIP mobile aware correspondent nodes. Data
traffic after diversion does not incur encapsulation. IIP always tries
to avoid using the forwarding mechanism whenever possible. Diversion
is a method to change IP address of any IP packet before the packet is
being sent out. This is normally done after the packet is formed. This
is so that there SHOULD NOT have any effect on the transport layer
whenever a mobile node moves hence it is transparent to any transport
layer.

- IIP uses a "first communication contact addressing mechanism" and
"short circuit mechanism" to improve triangular routing. Temporary
Visit Register and Near Correspondent Register are invented to achieve
such effect. In many case, IIP SHOULD assume each subnet would have at
least one anchoring entity that act as a BHR/NCR/TVR. Temporary Visit
Register can be upgraded to a Base Home Register to increase
reliability in connections. NCR is assumed MAY exist in between
Correspondent Node and BHR. Thus there is no complex Hierarchical
topology in IIP scheme for mobile network.

- A mobile node in IIP MUST always use its latest co-located address
in the source field in any of its IP packets. In such manner, mobile
node is always in the right topology, and hence it has no problem with
ingress filtering [1].

- IIP Binding Updates contain the latest transport port value allowing
multi-home and MPLS operation to be carried out. Many application uses
dynamic ports allocation while the connection is kept. With support
latest transport port value allows easier applications creation.

- No mobility action takes place during cell-to-cell switching in a
single IP subnet. This is due to fact subnet prefix switching
mechanism, like PPP [12], is used. Hence no periodic Agent
Advertisements would be need that significantly cut down traffic
between mobile node and the core network. Thus IIP uses simple control
signalling rather many different complex type of signalling.





Chern Nam Yap             Expires 10 July 2001                  Page 2
Internet Draft        Itinerant Internet Protocol      10 January 2000

- No need to worry for IPv4 to IPv6 transitions, fully compatible with
both IPv4 and IPv6 at the same time. Machines that can handle both
IPv4 and IPv6 SHOULD not have problems receiving IPv4 and IPv6 packets
in the mobile environment.












































Chern Nam Yap             Expires 10 July 2001                  Page 3
Internet Draft        Itinerant Internet Protocol      10 January 2000

3. Terminology

3.1 General Term

IP
Internet Protocol.

IIP
Itinerant Internet Protocol.

Node
A device that implements IP.

Router
A node that forwards IP packets not explicitly address to itself.

Host
Any node that is not a router.

Link
The Layer underneath IP.

Subnet prefix
A bit string that consist of a number of initial bits of an IP
address.

Packet
An IP header plus payload.

3.2 Itinerant Internet Protocol Terms

Home Address
An IP address assigned to a mobile node within the HOME link.

Visit Address
An IP address assigned to a mobile node within a visit link.

Near Address
An IP address either belongs to a Near Correspondent Register

Home Subnet Prefix
The subnet prefix associated with the mobile node's Home Address.

Visit Subnet Prefix
The subnet prefix associated with mobile node's Visit Address.




Chern Nam Yap             Expires 10 July 2001                  Page 4
Internet Draft        Itinerant Internet Protocol      10 January 2000

HOME link
The link where the mobile node's home subnet prefix is defined.

Visit Link
The link where mobile node's visit subnet prefix is defined.

Old link
The link where a mobile node is assigned a Home/Visit Address. It can
be either HOME link or Visit link.

New link
The link that a mobile node has just entered, it can be either a HOME
link or Visit link.

Mobile node
A node whose movement between subnets has minimum effect on its
applications.

Movement
A change in link, when a mobile node moves from an OLD link to a NEW
link.

Correspondent node
A peer node that the mobile node is communicating with. It can be
mobile or stationary.

BHR (Base Home Register)
An anchoring point for the mobile node at the HOME link that aids the
mobile node to diverse its address. It also forwards packets to the
mobile node when there is necessity to do so.

TVR (Temporary Visit Register)
An anchoring point for the mobile node at a visit link that aids in
forwarding packets to the mobile node when the mobile node leaves the
OLD link.

NCR (Near Correspondent Register)
An anchoring point for the mobile node situate between the
correspondent node and BHR. It aids in forwarding packets to the
mobile node to route optimise the link from the correspondent node to
the mobile node if the correspondent node is not mobile aware and
initialised the traffic first.






Chern Nam Yap             Expires 10 July 2001                  Page 5
Internet Draft        Itinerant Internet Protocol      10 January 2000

Co-located Address
An IP address that the mobile node uses to co-locate itself. This
address is used by the Mobile aware correspondent nodes, the BHR and
the TVR to send packets to the mobile node.

Binding
The association of the Home/Visit address with the co-located address
for any mobile node, along with the remaining lifetime of that
association.

Shorted Flag
A flag in TOS field for mobile short-circuiting.

3.3 Specification Language
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENEDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.































Chern Nam Yap             Expires 10 July 2001                  Page 6
Internet Draft        Itinerant Internet Protocol      10 January 2000

4. Overview of Itinerant Internet Protocol

4.1 Basic Operation
In the basic scheme, a mobile node SHOULD be addressed by its co-
located address, whether or not it is currently attached to the HOME
link or a visit link. Standard IP routing is used when the mobile node
is at home and there is no OLD link after the mobile node is switched
on. When a mobile node moves to a NEW link, it SHOULD be assigned a co-
located address. The mobile node SHOULD then register this address
with its BHR and TVR. This is done through the means of address
binding updates. Similarly, a correspondent node that is in
communication with the mobile node SHOULD also get address binding
updates. Packets sent to the mobile node SHOULD then either be
forwarded or diverted to mobile node's latest co-located address.

Example:
 A mobile node is switched on at Visit link, and it moves to its HOME
 link. In this case the Visit link is its OLD link and the HOME link
 is its NEW link. A new co-located address SHOULD be assigned to the
 mobile node and SHOULD be sent to the BHR and TVR. Since the mobile
 node is in the HOME link, the home address SHOULD be assigned to it.
 Packets that go straight to the HOME link SHOULD have not additional
 processing. If a communication was started in the OLD link (Visit
 link), the packets SHOULD be forwarded to the mobile node via the TVR
 by the means of tunnelling [6]. Hence the co-located address can
 either be the Home address or a Visit Address.

The association between a mobile node's Home/Visit Address and co-
located address is known as "Binding" for the mobile node. A mobile
node typically acquires its co-located address through PPP [12].
Other methods of acquiring a co-located address are possible, but
details of other methods are currently beyond the scope of this
document.

While a mobile node moves, it registers it newly acquired address with
the BHR and TVR. Moreover, a mobile node can also upgrade one of its
TVR to BHR in the case if its BHR is not working. The mobile node
sends a "Binding Update" packet to achieve the above binding
registration. The BHR or TVR SHOULD reply to the registration by
sending a "Binding Acknowledgement" packet.








Chern Nam Yap             Expires 10 July 2001                  Page 7
Internet Draft        Itinerant Internet Protocol      10 January 2000

In IPv4, the mobile node's BHR/TVR SHOULD use "proxy ARP/gratuitous
ARP" [7] to intercept any IP packets addressed to the mobile node's
home/visit address.

In IPv6, the mobile node's BHR/TVR SHOULD use "neighbour discovery
mechanism" to intercept any IP packets addressed to the mobile node's
home/visit address.

The BHR/TVR MUST then divert (Address Binding Updates) or tunnel [6]
the packets to the mobile node's co-located address.

A mobile aware correspondent node MUST always use the diversion
method. In which case, the correspondent node MUST send a "Binding
Request". It is RECOMMENDED that data packets be sent immediately,
without waiting for the "Binding Update" reply.

In the backward compatibility scheme, communication between the mobile
node and the correspondent node SHOULD depend on who has started the
communication first.

If the correspondent started the communication, the correspondent node
could only have known the mobile node's home address (through DNS).
Hence the BHR SHOULD tunnels [6] all traffic to the mobile node's
latest co-located address. When the mobile node moves from one Visit
Link to another, the TVR MUST intercept the mobile node's traffic and
aid the tunnelling [6] process. The reason for this is simple, since
the TVR in this sense provides smooth handoffs. Moreover, the mobile
node will initiate a NCR discovery mechanism (Short Circuit
mechanism). Once a NCR is found along the way between the
correspondent node and BHR, NCR will take over the forwarding
functionality of the BHR in the direction towards the mobile node.

If the mobile node starts the communication, then it SHOULD depend on
where the mobile node is located. If the mobile node is located at the
HOME link, then it is very much the same as if the correspondent node
started the communication. If the mobile node is located at a visit
link, due to the fact the mobile node SHOULD use the visit address as
the source field in the IP packet, the correspondent SHOULD send all
the traffic to this visit address. As the mobile node moves to a NEW
link, the OLD link TVR SHOULD intercept the packets for the mobile
node and tunnel [6] them to the mobile node.







Chern Nam Yap             Expires 10 July 2001                  Page 8
Internet Draft        Itinerant Internet Protocol      10 January 2000

All mobile nodes MUST be mobile aware correspondent nodes and MUST be
able to do forwarding and reverse tunnelling [6]. In any case a
BHR/TVR/NCR can be a mobile node as well. If a BHR/TVR/NCR works as a
mobile node, it MUST first handover its functionality before it
becomes mobile. This functionality of BHR and TVR being mobile SHOULD
not be mentioned in this document, but on another document.

Any peer communicating with a mobile node is referred to in this
document as a "correspondent node". It MAY be either a mobile node or
stationary node.

Currently Binding Update, Binding Acknowledgment and Binding Request
are all in UDP [9] payload format. This might change in the future to
SCTP [14] payload format as well. Currently, the protocol will work on
port 700 that currently is unassigned by any protocol.

Mobile node MUST always source its packets using its NEW link co-
located address, whether it is a Home address or Visit address. Hence
the mobile node is always topologically correct. Thus IIP does not
need to deal with "ingress-filtering issues" [1].

4.2 Short Circuit Mechanism

As aforementioned this is a NCR discovery mechanism. Whenever a non-
mobile-aware correspondent node sends a packet to mobile node. The
packet will be tunnelled through the BHR. This forwarding process
indicated that the either mobile node is in anonymous mode or the
correspondent node is not mobile-aware. If shorted circuit were done,
the mobile node would as well receive a forwarded packet. Mobile Node
would ignore to re preformed "Short Circuit Mechanism" as there isn't
a need to. The first packet that mobile node send back to the
correspondent node in the IP header would have a flag <set> in the
unused TOS field.

Normal IPv4 header with the unused TOS field flag <set>
This flag is known as Shorted Flag throughout this document

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Ver   |  IHL  |    TOS      |1|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                                                               +
   |                                                               |

Chern Nam Yap             Expires 10 July 2001                  Page 9
Internet Draft        Itinerant Internet Protocol      10 January 2000

IP version 6 is not mentioned here is assumed that all IP version 6
node SHOULD be mobile aware, hence this feature is not required.

Since every router along the way would have to decode the IP header
(i.e. between the BHR and the Correspondent Node). If a NCR exist, it
should be able to pick up this and send a "Near Registration" to the
Mobile Node.

Hence once the two-way "Near Registration" (explained in 10.1) is
completed, the route from non-mobile aware correspondent node to
mobile node will be "short circuited" as the NCR would intercept
mobile node packet and forward to the mobile node's latest link. The
mobile node SHOULD send Binding Update refresh to keep this short
circuit.

4.2 Itinerant Internet Protocol Signalling

As discussed in general in Section 4.1, the following three new UDP
[9] packets are defined for IIP Signalling.

Binding Update
The mobile node notifies the BHR/TVR/NCR as well as in communication
with correspondent nodes using this packet. This packet is also used
by the BHR to reply to a correspondent node request of the mobile
node's current co-located address. At the same time this packet is
also used by the NCR start "short circuiting". The Binding Update sent
to the BHR to register the mobile node's co-located address is known
as "Home Registration". The Binding Update sent to the TVR to register
the mobile node's co-located address is known as "Visit Registration".
Any mobile node can upgrade its TVR to BHR using "Home Registration".
The Binding Update sent by NCR to Mobile Node for "short circuiting"
is known as "Near Registration".

This packet SHOULD be protected from security attacks. Currently,
IPSec [2] is used to protect this Binding Update packet as defined in
Section 4.3 to guard against any malicious Binding Updates.

Binding Acknowledgment
This packet is used to acknowledge receipt of Binding Update, if an
acknowledgement was requested in the Binding Update. This packet
SHOULD be protected from security attacks. Currently, IPSec [2] is
used to protect this Binding Acknowledgment packet as defined in
Section 4.3 to guard against any malicious Binding Acknowledgment.





Chern Nam Yap             Expires 10 July 2001                 Page 10
Internet Draft        Itinerant Internet Protocol      10 January 2000

Binding Request
Correspondent node uses this packet to request for mobile node's
latest co-located. This packet is normally sent to BHR/TVR, and a
correspondent node for refreshing binding also can use it. This is
sent as a normal packet, or it can also be sent with security
protection.

4.3 IPSec [2] Requirements for Binding Updates and Binding
Acknowledgement.

Currently, IPSec [2] MUST be used to protect both Binding Update and
Binding Acknowledgement packets. Specifically, any Binding Update or
Binding Acknowledgement packet MUST utilise IPSec [2] sender
authentication, data integrity protection, and replay protection.

Currently, IIP requires that this protection covering a Binding Update
or Binding Acknowledgement MUST use AH [4] and ESP [5]. IIP is a
transport payload, hence it is easily protected by AH [4] and ESP [5].

4.4 Conceptual Data Structures

This document describes IIP in terms of the following conceptual data
structures:

Mobile Binding Cache
Each mobile aware node needs to maintain a binding cache. This cache
contains bindings of the mobile aware node with any mobile nodes. The
Mobile Binding Cache MAY be implemented in any manner consistence with
the external behaviour described in this document.

Each Mobile Binding Cache entry conceptually contains the following
fields:

- Home/Visit Address of a mobile node. This field is used as the key
value to aid searching the Binding Cache for the destination address
of a packet being sent. When the destination address of the packet
matches Home/Visit Address in the Binding Cache entry, this entry
SHOULD be used in routing that packet.

- The co-located address of mobile node. It is the field in the same
entry that is associated with the Home/Visit field. If the destination
address of a packet being sent matches Home/Visit Address, then the
packet SHOULD be routed to this co-located address.





Chern Nam Yap             Expires 10 July 2001                 Page 11
Internet Draft        Itinerant Internet Protocol      10 January 2000

- A lifetime value that shows the remaining lifetime for this Binding
Cache entry. This value is initialised from the lifetime field in the
Binding Update that created or last modified this Binding Cache entry.
Once the lifetime on this entry has expires, the entry MUST be deleted
from the Binding Cache.

- A flag indicating whether this Binding Cache entry is a "Home
Registration" or "Visit Registration" or "Near Registration".

- The Maximum value of the Sequence Number field that is received in
previous Binding Updates for this mobile node home address. The
Sequence Number field is 32 bit long, and all comparisons between
Sequence Number values MUST be performed modulo 2^32.

- Binding Cache entry recent usage information. It is needed to
implement cache replacement policy in use in the Binding Cache.
This also assists in determining whether a Binding Request SHOULD be
sent when the lifetime on this entry is near expiration.

An entry in a node's Binding Cache for which the node is serving as a
BHR is marked as "Home Registration" entry (TVR is marked as "Visit
Registration" entry, NCR is marked as "Near Registration" entry). This
entry SHOULD NOT be deleted by the BHR/TVR/NCR until the expiration of
its binding lifetime. Other Binding Cache entries MAY be replaced at
any time by any reasonable local cache replacement policy but SHOULD
NOT unnecessary to be deleted. The node's Binding Cache MAY contain at
most one entry for each mobile node Home/Visit Address.

Binding Update List

Binding Update list that is maintained by each mobile node, records
information for each Binding Update sent by the mobile node for which
the lifetime sent in that Binding Update has not been expired. It
includes all bindings sent by the mobile node to its correspondent
nodes, BHR/TVR/NCR. However, for multiple Binding Updates sent to the
same destination address, the Binding Update List contains only the
most recent Binding Updates (where Greatest Sequence Number is used in
this case to confirm the most recent Binding Updates) sent to the
destination.

The Binding Update list MAY be implemented in any manner consistent
with the external behaviour as described in this document. Each Biding
update list entry conceptually contains the following fields:





Chern Nam Yap             Expires 10 July 2001                 Page 12
Internet Draft        Itinerant Internet Protocol      10 January 2000

- The IP address of the node to which a Binding Update was sent. If
the Binding Update was successfully received by that node and if that
node has not been deleted the entry before its expiration, this node
might still have a Binding Cache entry.

- The Home/Visit address for which that Binding update was sent. This
is meant for the mobile node to distinguish between co-located and
Home/Visit address.

- The co-located address of the Binding Update. This value is
necessary for the mobile node to determine if it has sent its latest
co-located address in the Binding Update to the right destination
after changing its co-located address.

- The initial value of the Lifetime field sent in that Binding Update.

- The remaining lifetime of that binding. This lifetime is initialised
from the lifetime value sent in the Binding Update and is decremented
until it reaches zero, at which time this entry MUST be deleted from
the Binding Update list.

- The maximum value of the Sequence Number field sent in previous
Binding Updates to this destination. The Sequence Number field is 32
bit long, and all comparisons between Sequence Number values MUST be
performed modulo 2^32.

- The time at which a Binding Update was last sent to this
destination, as needed to implement the rate limiting restriction for
sending Binding Updates.

- The state of any retransmissions needed for this Binding Update.
This state includes the time remaining until the next retransmission
attempts for the Binding Update, and the current state of the
exponential back-off mechanism for retransmissions.

- A flag that indicates that future Binding Updates SHOULD not be sent
to any particular destination when it is being set.











Chern Nam Yap             Expires 10 July 2001                 Page 13
Internet Draft        Itinerant Internet Protocol      10 January 2000

4.5 Binding Management

When a mobile node acquires a new co-located address, the mobile node
SHOULD register this new binding with its BHR/TVR/NCR by sending the
BHR/TVR/NCR a Binding Update. The mobile node indicates that an
acknowledgement is needed for this Binding Update and continues to
periodically retransmit it until it receives an acknowledgment. The
acknowledgement is in the form of Binding Acknowledgement packet as
mentioned above.

When a mobile node receives a packet tunnelled [6] to it from the
BHR/TVR/NCR, it SHOULD assume that the original sender is not mobile
aware, until it receives a packet that is send directly from the
sender to the mobile node, if the communication is not initiated by
the mobile node. When this takes place, as aforementioned "short
circuit mechanism" should take place.

A correspondent node with a Binding Cache entry for a mobile node MAY
wanted to refresh this binding, for example if the binding's lifetime
is near expiration, by the correspondent node MAY send a Binding
Request to the mobile node for a refresh for the Binding. Normally, a
correspondent node SHOULD only refresh a Binding Cache entry in this
way if it is actively having a ongoing communication with the mobile
node. (For example as an open TCP [10] connection to the mobile node)
When a mobile node receives a Binding Request, it replies by returning
a Binding Update to the node sending the Binding Request.

Since some correspondent nodes are mobile aware, it is expected that
correspondent nodes SHOULD usually route packets directly to the
mobile node's co-located address, so that the BHR is rarely involved
with the packet transmission to the mobile node. This is essential for
scalability and reliability, and for minimising overall network load.

Optimal routing of packets can be achieved from the correspondent node
to the mobile node, by caching the co-located address of a mobile
node. Routing packets directly to the mobile node's co-located address
also eliminates congestion at the mobile node's BHR and HOME link. In
addition, the impact of any possible failure of the BHR, the HOME
link, or intervening networks leading to or from the HOME link is
reduced, since these nodes and links are not involved in the delivery
of most packets to the mobile node. Mobile node should try to upgrade
all of its TVR to BHR to allow minimum loss of connection when BHR
fails. Hence IIP is a more reliable protocol.





Chern Nam Yap             Expires 10 July 2001                 Page 14
Internet Draft        Itinerant Internet Protocol      10 January 2000

5. Itinerant Internet Protocol Signalling Message Types

5.1 Binding Update Packet

The Binding Update is used by the mobile node to notify its
BHR/TVR/NCR Correspondent nodes of a newly assigned co-located
address.

The Binding Update packet is encoded in type-length value (TLV) format
as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |    Options    |    Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Lifetime                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Home / Visit / Near / Co-located IP address       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Port Number          |           Session ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type
 1

Length
The total length of the message, in bytes, excluding the Type and
Length bytes.

Options: Based on 8bit ASCII code
______________________________________________________________________

Acknowledge (A)
The Acknowledge (A) bit is set by the sending mobile node to request a
Binding Acknowledgement (Section 5.2) be returned upon receipt of the
Binding Update.

Mobile Node (M)
The Mobile Node (M) bit is set by the sending mobile node to the
correspondent node for identification.

Base Home Register (B)
The Base Home Register (B) bit is set by the BHR to the correspondent
node for identification.


Chern Nam Yap             Expires 10 July 2001                 Page 15
Internet Draft        Itinerant Internet Protocol      10 January 2000

Temporary Visit Register (T)
The Temporary Visit Register (T) bit is set by the TVR to the
correspondent node for identification.

Home Registration (H)
The Home Registration (H) bit is set by a mobile node to request the
receiving node to be its BHR. The destination of the packet carrying
this option MUST be a node sharing the same subnet prefix as the
mobile node Home address.

Visit Registration (V)
The Visit Registration (V) bit is set by a mobile node to request the
receiving node to be its TVR. The destination of the packet carrying
this option MUST be a node sharing the same subnet prefix as the
mobile node Visit address.

Near Registration (N)
The Near Registration (N) bit is set by a mobile node/NCR to
register/update NCR.

Privacy (P)
Privacy (P) bit is set by mobile node to allow it to run in privacy,
no binding update SHOULD be sent to correspondent node as the mobile
node wish to be anonymous.


Reserved
This field is unused. It MUST be initialised to zero by the sender and
MUST be ignored by the receiver.

Sequence Number
Used by the receiving node to sequence Binding Updates and by the
sending node to match a returned Binding Acknowledgement with this
Binding Update. Each Binding Update sent by a mobile node MUST use a
Sequence Number greater than the Sequence Number value sent in the
previous Binding Update (if any) to the same destination address
(modulo 2^32). There is no requirement, however, that the Sequence
Number value strictly increase by 1 with each new Binding Update sent
or received.

Lifetime
It is 32-bit unsigned integer. The number of seconds remaining before
the binding MUST be considered expired. A value of all one bits
(0xffffffff) indicates infinity. A value of zero indicates that the
Binding Cache entry for the mobile node MUST be deleted.



Chern Nam Yap             Expires 10 July 2001                 Page 16
Internet Draft        Itinerant Internet Protocol      10 January 2000


Home/Visit/Co-located Address

If the Home/Visit IP Address is sent to the BHR/TVR/NCR/Correspondent
Node to update Binding by the mobile node, then the M bit MUST be set
here.

If the Near IP Address is set to Mobile Node to "short-circuit" by the
NCR, then the N bit MUST be set here.

If the Co-located IP Address is sent to Correspondent Node to update
the Binding by the BHR, then the B bit MUST be set here.

If the Co-located IP Address is sent to Correspondent Node to update
the Binding by the TVR, then the T bit MUST be set here.

Port Number
This is a 16-bit value to allow change of port number that mobile node
and the correspondent node would agree on using for the future
communication.

Session ID
This is a 16-bit value to allow identification for corresponding
Binding Request/Binding Updates/Binding Acknowledgement.

The co-located address for the binding given in the Binding Update is
specified by the Source Address field. It is in the IP header of the
Binding Update.

A Binding Cache entry for the mobile node MUST NOT be created in
response to the following Binding Update packet:

  If present, or in the Source Address field in the packet's IP header
  is equal to the home address of the mobile node and if the lifetime
  field in the Binding Update is equal to 0.

The mobile node stores the Last Sequence Number value in Binding
Update list entry for a destination that it sent a Binding Update.
The correspondent node store the Last Sequence Number value that is
received from a mobile node in a Binding Update in its Binding Cache
entry for that mobile node. Thus, the mobile node and correspondent
node SHOULD have the knowledge of the Last Sequence Number and SHOULD
expire at the same time. If the sending mobile node has no Binding
Update List entry, the Sequence Number MAY start at any value. If the
receiving correspondent node has no Binding Cache entry for the
sending mobile node, it MUST accept any Sequence Number value in a
received Binding Update from the mobile node.

Chern Nam Yap             Expires 10 July 2001                 Page 17
Internet Draft        Itinerant Internet Protocol      10 January 2000

5.2 Binding Acknowledgement Packet

The Binding Acknowledgement packet is used to acknowledge receipt of a
Binding Update (Section 5.1). When a node receives the Binding Update
Packet, it MUST return a Binding Acknowledgement to the source of the
packet if the Acknowledge (A) bit is set in the Binding Update.

The Binding Acknowledgement packet is encoded in type-length-value
(TLV) format as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |    Status     |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Sequence Number                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Lifetime                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Port Number          |           Session ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type
2

Length
The total length of the message, in bytes, excluding the Type and
Length bytes.

Status
It is an 8-bit unsigned integer indicating the disposition of the
Binding Updates. Values of the Status field less than 128 indicate
that the receiving node accepted the Binding Updates. The following
such Status values are currently defined:

     0 Binding Update accepted












Chern Nam Yap             Expires 10 July 2001                 Page 18
Internet Draft        Itinerant Internet Protocol      10 January 2000

Values of the Status field greater than or equal to 128 indicate that
the receiving node rejected the Binding Updates. The following such
Status values are currently defined:

     128 Reason unspecified
     129 Administratively prohibited
     130 Insufficient resources
     131 Not BHR for this mobile node
     132 Not TVR for this mobile node
     133 Not NCR for this mobile node
     134 Home registrations not supported
     135 Visit registrations not supported
     136 Not home subnet
     137 Not visit subnet

Reserved
This field is unused. It MUST be initialised to zero by the sender and
MUST be ignored by the receiver.

Sequence Number
Sequence Number in the Binding Acknowledgment is copied form the
Sequence Number field in the Binding Update being acknowledge, for use
by the mobile node in matching this Acknowledgement with an
outstanding Binding Update.

Lifetime
The granted lifetime is in terms of seconds. If the node sending the
Binding Acknowledgement is serving as the mobile node's BHR/TVR, the
lifetime period SHOULD also indicate the period for which this node
SHOULD continue this service. If the mobile node requires BHR/TVR
service from this node beyond this period, the mobile node MUST send a
new Binding Update to it before the expiration of this period, in
order to extend the lifetime. The value of this field SHOULD be
undefined it the Status field indicated that the Binding Update was
rejected.

Port Number
This is a 16-bit value to allow change of port number that mobile node
and the correspondent node would agree on using for the future
communication.

Session ID
This is a 16-bit value to allow identification for corresponding
Binding Request/Binding Updates/Binding Acknowledgement.




Chern Nam Yap             Expires 10 July 2001                 Page 19
Internet Draft        Itinerant Internet Protocol      10 January 2000

If the node returning the Binding Acknowledgement accepts the Binding
Update for which the Acknowledgement is being returned (The value of
the Status field in the Acknowledgement is less than 128), this node
SHOULD have an entry for the mobile node in its Binding Cache and MUST
use this entry (which includes the co-located address received in the
Binding Update) to send the Binding Acknowledgement packet to the
mobile node.

The details of sending this packet to the mobile node are the same for
sending any packet to a mobile node using a binding, and are described
in Section 7.7. The packet is routed to the mobile node by way of its
co-located address recorded in the Binding Cache entry.

If the node returning the Binding Acknowledgement instead rejects the
Binding Update (the value of the status field in the Acknowledgement
is greater than or equal to 128), the co-located address used by this
node for sending the Binding Acknowledgement packet MUST be copied
from the co-located address received in the rejected Binding Update.
This node MUST NOT modify its Binding Cache in response to receiving
this rejected Binding Update and MUST ignore its Binding Cache in
sending this Binding Acknowledgement packet. This packet is routed to
the co-located address of the rejected Binding Updated packet.

5.3 Binding Request Packet

The Binding Request Packet is used to request a mobile node's binding
from the BHR. When the BHR receives a Binding request packet, it
SHOULD return a Binding Update (Section 5.1) to the source of the
Binding Request, if the mobile node has not requested privacy through
the use of the P bit.

The Binding Request packet is encoded in type-length-value (TLV)
format as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |          Session ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type
3

Length
The total length of the message, in bytes, excluding the Type and
Length bytes.


Chern Nam Yap             Expires 10 July 2001                 Page 20
Internet Draft        Itinerant Internet Protocol      10 January 2000


Session ID
This is a 16-bit value to allow identification for corresponding
Binding Request/Binding Updates/Binding Acknowledgement.
Session ID











































Chern Nam Yap             Expires 10 July 2001                 Page 21
Internet Draft        Itinerant Internet Protocol      10 January 2000

6. Requirement for IP Nodes

IIP places some requirements on the functions needed to make a node
mobile aware. This section summarises those requirements by
identifying the functionality each requirement is intended to support.
Further details on this functionality are provided in the following
sections.

6.1 Requirements for All Mobile Aware Nodes

Since any mobile node MAY at any time be a correspondent node, either
sending or receiving a packet, the following requirements apply to all
mobile nodes:

- Every mobile node MUST be able to process a Binding Update packet,
and to return a Binding Acknowledgement packet if the Acknowledge (A)
bit is set in the received Binding Update.

- Every mobile node SHOULD be able to maintain a Binding Cache of the
binding received in the accepted Binding Updates.

- Every mobile node MUST be able to decapsulate and reverse tunnel [6]
any packet to the BHR or TVR.

-Every mobile node MUST maintain a Binding Update List in which it
records the IP address of each node to which it has sent a Binding
Update, for which the lifetime sent in that binding has not expired.

6.2 Requirements for Base Home Register

In order to enable a mobile node to operate correctly while away from
home, there MUST be a node to act as BHR for the mobile node. The
following requirements apply to the BHR:

- Every BHR MUST be able to maintain an entry in its Binding Cache for
each mobile node it is serving. Each Binding Cache entry records the
mobile node binding with its co-located address.











Chern Nam Yap             Expires 10 July 2001                 Page 22
Internet Draft        Itinerant Internet Protocol      10 January 2000

- Every BHR MUST be able to intercept packets as mentioned above,
addressed to the mobile node, for which it is currently serving as the
BHR on the mobile node's HOME link, while the mobile node is away from
home.

- Every BHR MUST be able to encapsulate such packets in order to
tunnel [6] them to the co-located address of the mobile node indicated
in its binding in the BHR's Binding Cache.

- Every BHR MUST be able to return a Binding Acknowledgement packet in
response to a Binding Update packets received with (A) bit set.

- Every BHR MUST maintain a separate BHR List for each link on which
it is serving as a BHR.

- Every BHR MUST be able to process a Binding Request packet, and
response with a Binding Update. This Binding Update is sent back to
the correspondent node, and holds the requested mobile node's latest
co-located IP address.

6.3 Requirement for Temporary Visit Register

In order to enable a mobile node to operate correctly while away from
visit, there MUST be a node to act as a TVR for the mobile node. The
following requirements apply to the TVR:

- Every TVR MUST be able to maintain an entry in its Binding Cache for
each mobile node it serves. Each Binding Cache entry records the
mobile node's binding with its co-located address.

- Every TVR MUST be able to intercept packets addressed to a mobile
node for which it is currently serving as the TVR, while the mobile
node is away from its visit link.

- Every TVR MUST be able to encapsulate packets in order to tunnel [6]
them to the new co-located address for the mobile node indicated in
its binding in the TVR's Binding Cache.

- Every TVR MUST be able to return a Binding Acknowledgement packet in
response to Binding Update packets received with (A) bit set.

- Every TVR MUST maintain a separate TVR List for each link on which
it is serving as TVR.

- Every TVR SHOULD be able to upgraded to a BHR, if there are such
requests from a mobile node.


Chern Nam Yap             Expires 10 July 2001                 Page 23
Internet Draft        Itinerant Internet Protocol      10 January 2000

6.4 Requirements for Near Correspondent Register

In order to enable a mobile node to "short circuit", it is assume that
there MAY be a node to act as NCR for the mobile node. The following
requirements apply to the NCR:

- Every NCR MUST be able to maintain an entry in its Binding Cache for
each mobile node it is serving. Each Binding Cache entry records the
mobile node binding with its co-located address.

- Every NCR MUST be able to intercept packets as mentioned above,
addressed to the mobile node, for which it is currently serving as the
NCR.
- Every NCR MUST be able to encapsulate such packets in order to
tunnel [6] them to the co-located address of the mobile node indicated
in its binding in the NCR's Binding Cache.

- Every NCR MUST be able to return a Binding Acknowledgement packet in
response to a Binding Update packets received with (A) bit set.

- Every NCR MUST maintain a separate NCR List for each link on which
it is serving as a NCR.

- Every NCR MUST be able to process Shorted Flag and perform Near
Registration.

- A NCR MAY be upgraded to a BHR, if a mobile node requested and the
NCR can provide an IP address to the mobile node.




















Chern Nam Yap             Expires 10 July 2001                 Page 24
Internet Draft        Itinerant Internet Protocol      10 January 2000

7. Correspondent Node Operation

A correspondent node is any node communicating with a mobile node. The
correspondent node itself MAY be stationary or mobile. In this
section, only the mobile aware correspondent node SHOULD be mentioned,
as there is no point in mentioning non-mobile aware correspondent
node.

7.1 Receiving Binding Updates
Upon receiving a Binding Update in some packet, the receiving node
MUST validate the Biding Update according to the following tests:

- The packet meets the specific IPSec [2] requirements for Binding
Updates, defined in Section 4.3

- The address for binding is specified by the Home/Visit/Co-located
field. Either the M bit or the B bit MUST be set.

- The Sequence Number field in the Binding Update is greater than the
Sequence Number received in the previous Binding Update for this home
address, if any. As note in Section 4.6, this Sequence Number
comparison MUST be performed modulo 2^32.

Any invalid Binding Update MUST be silently ignored, and the Binding
Update packet MUST be discarded.

If the Binding Update is valid according to the tests above, then the
Binding Update is processed further as follows:

- If the lifetime specified in the Binding Update is nonzero and the
specified co-located address is not equal to the home address for the
binding, then this is a request to cache a binding for the mobile
node. If the Home Registration (H) bit is set in the Binding Update,
the Binding Update SHOULD be processed according to the procedure
specified in Section 8.1. If the Visit Registration (V) bit is set in
the Binding Update, the Binding Update is processed according to the
procedure specified in Section 9.1. Otherwise, it is processed
according to the procedure specified in Section 7.2.

- If the lifetime specified in the Binding Update is zero or the
specified co-located address matches the home address for the binding,
then this is a request to delete the mobile node's cached binding. If
the Home Registration (H) bit is set in the Binding Update, the
Binding Update is processed according to the procedure specified in
Section 8.2. If the Visit Registration (V) bit is set in the Binding
Update, the Binding Update is processed according to the procedure
specified in Section 9.2. Otherwise, it is processed according to the
procedure specified in Section 7.3.

Chern Nam Yap             Expires 10 July 2001                 Page 25
Internet Draft        Itinerant Internet Protocol      10 January 2000

7.2 Request to Cache a Binding

When a node receives a Binding Update, it MUST validate it and
determine the type of Binding Update according to the steps described
in Section 7.1. This section describes the processing of a valid
Binding Update that requests a node to cache a mobile node's binding,
for which the Home Registration (H) bit or Visit Registration (V) bit
is not set in the Binding Update.

In this case, the receiving node SHOULD create a new entry in its
Binding Cache for this mobile node (or update its existing Binding
Cache entry for this mobile node, if such an entry already exists).
The home address of the mobile node is taken from the Home/Visit
Address field. The new Binding Cache entry records the association
between this home address and the co-located address for the binding,
as specified in co-located address field of the Binding Update
packet's source address field. The lifetime for the Binding Cache
entry is initialised from the Lifetime field specified in the Binding
Update, although the node caching the binding MAY reduce this
lifetime. The lifetime for the Binding Cache entry MUST NOT be greater
than the Lifetime value specified in the Binding Update. Any Binding
Cache entry MUST be deleted after the expiration of this lifetime on
the Binding Cache entry.

7.3 Sending Binding Acknowledgements

When any node receives a Binding Update packet in which the
Acknowledge (A) bit is set, it SHOULD return a Binding Acknowledgement
packet acknowledging receipt of the Binding Update. If the node
accepts the Binding Update and creates or updates an entry in its
Binding Cache for this binding, the Status field in the Binding
Acknowledgement MUST be set to a value less than 128. If the node
rejects the Binding Update and does not create or update an entry for
this binding, the Status field in the Binding Acknowledgement MUST be
set to a value greater than or equal to 128. Specific values for the
Status field are described in Section 5.2.

The packet in which the Binding Acknowledgement is returned MUST meet
the specific IPSec [2] requirements for Binding Acknowledgements. The
packet MUST be sent to the mobile node using mobile node's co-located
address (even if the binding was rejected), as described in section
7.8. The packet is routed first to the co-located address contained in
the Binding Update being acknowledged and then mobile node home
address. This ensures that the Binding Acknowledgement packet SHOULD
be routed to the current location of the node sending the Binding
Update, whether the Binding Update was accepted or rejected.


Chern Nam Yap             Expires 10 July 2001                 Page 26
Internet Draft        Itinerant Internet Protocol      10 January 2000

7.4 Sending Binding Requests

Entries in a node's Binding Cache MUST be deleted when their lifetime
expires.  If such an entry is still in active use in sending packets
to a mobile node, a new Binding Request SHOULD be sent to the mobile
node's HOME link, where it SHOULD be intercepted and the BHR SHOULD
send a Binding Update to the sender, allowing it to create a new
Binding Cache entry for sending future packets to the mobile node.
Communication with the mobile node continues uninterrupted, but this
diversion creates overhead and latency in delivering packets to the
mobile node. Any correspondent node will use the Session ID value that
it sent to the BHR/TVR or the mobile node to verify which is the right
session it is talking about.

If the sender knows that the Binding Cache entry is still in active
use, it MAY send a Binding Request packet to the mobile node in an
attempt to avoid this overhead and latency due to deleting and
recreating the Binding Cache entry. When the mobile node receives a
Binding Request packet from some sender, it returns a Binding Update
packet to that sender, giving its current binding and a new lifetime.

7.5 Cache Replacement Policy

After the expiration of the Lifetime specified in the Binding Update
from which any entry was created or last updated, the entry in a
node's Binding Cache MUST be deleted. Conceptually, a node SHOULD
maintain a separate timer for each entry in its Binding Cache.  The
node sets the timer for this entry to the specified Lifetime period
when creating or updating a Binding Cache entry in response to a
received and accepted Binding Update.  When a Binding Cache entry's
timer expires, the node deletes the entry.

















Chern Nam Yap             Expires 10 July 2001                 Page 27
Internet Draft        Itinerant Internet Protocol      10 January 2000

Each node's Binding Cache SHOULD, by necessity, has a finite size. A
node MAY use any reasonable local policy for managing the space within
its Binding Cache, except that any entry marked as a "Home
Registration" (Section 8.3) MUST NOT be deleted from the cache until
the expiration of its lifetime period. This SHOULD as well apply to
"Visit Registration". When attempting to add a new "Home Registration"
entry in response to a Binding Update with the Home Registration (H)
bit set, if insufficient space exists (or can be reclaimed) in the
node's Binding Cache, the node MUST reject the Binding Update and
SHOULD return a Binding Acknowledgement to the sending mobile node, in
which the Status field is set to 130 (insufficient resources). When
otherwise attempting to add a new entry to its Binding Cache, a node
MAY, if needed, choose to drop any entry already in its Binding Cache,
other than a "Home Registration" or "Visit Registration" entry, in
order to make space for the new entry.  Normally a BHR/TVR should have
much more resources than normal nodes in a subnet, as it is
RECOMMENDED that these nodes are able to work in such environment.

Any binding dropped from a node's Binding Cache due to the lack of
cache space SHOULD be rediscovered and a new cache entry SHOULD be
created, if the binding is still in active use by the node for sending
packets. If the node sends a packet to a destination for which it has
dropped the entry from its Binding Cache, the packet SHOULD be routed
normally, leading to the mobile node's HOME link. There, the packet
SHOULD be intercepted by the mobile node's BHR and the BHR SHOULD
reply with a Binding Updates that allowing the correspondent node to
add an entry again for this destination mobile node to its Binding
Cache.

7.6 Sending Packets to a Mobile Node

Before sending any packet, the sending node SHOULD examine its Binding
Cache for an entry for the destination address to which the packet is
being sent.  If the sending node has a Binding Cache entry for this
address, the sending node SHOULD route the packet to this mobile node
(the destination node) by way of the co-located address in the binding
recorded in that Binding Cache entry.

If, instead, the sending node has no Binding Cache entry for the
destination address to which the packet is being sent, the sending
node simply sends the Binding Request packet and SHOULD be intercepted
by the mobile node's BHR which SHOULD sent the Binding Updates
allowing the sending node to create a Binding Cache entry for its use
in sending subsequent packets to this mobile node.




Chern Nam Yap             Expires 10 July 2001                 Page 28
Internet Draft        Itinerant Internet Protocol      10 January 2000

8. Base Home Register Operation

A mobile node SHOULD have a default BHR, and MUST register itself to
the BHR while it is at home.

8.1 Co-located Address Registration

When a node receives a Binding Update, it MUST validate it and
determine the type of Binding Update according to the steps described
in Section 7.1.  This section describes the processing of a valid
Binding Update that requests the receiving node to serve as its BHR
(Essentially a TVR), registering its co-located address.

To begin processing the Binding Update, the BHR MUST perform the
following sequence of tests:

- If the home address for the binding is not in the same HOME link
respect to the BHR links, then the BHR MUST reject the Binding Update
and SHOULD return a Binding Acknowledgement to the mobile node, in
which the Status field is set to 135 (Not home subnet).

- Else, if the BHR chooses to reject the Binding Update for any other
reason (e.g., insufficient resources to serve another mobile node as a
Home Register), then the BHR SHOULD return a Binding Acknowledgement
to the mobile node, in which the Status field is set to an appropriate
value to indicate the reason for the rejection. If the BHR does not
reject the Binding Update as described above, then it SHOULD update
its existing Binding Cache entry for this mobile node. The home
address of the mobile node is taken from the Home Address field. The
co-located address for this Binding Cache entry is taken from the
Source Address field in the packet header.

The BHR MUST mark this Binding Cache entry as a "Home Registration" to
indicate that the node is serving as a BHR for this binding. Binding
Cache entries mark as a "Home Registration" MUST be excluded from the
normal cache replacement policy used for the Binding Cache (Section
7.6) and MUST NOT be removed from the Binding Cache.

If the Acknowledge (A) bit is set in the Binding Update (it SHOULD
be), then the BHR MUST return a Binding Acknowledgement to the mobile
node, constructed as follows:

- The Status field MUST be set to a value indicating success (the
value MUST be less than 128).  The only currently defined success
Status value is 0, indicating simply that the Binding Update was
accepted.


Chern Nam Yap             Expires 10 July 2001                 Page 29
Internet Draft        Itinerant Internet Protocol      10 January 2000

- The Sequence Number field MUST be copied from the Sequence Number
given in the Binding Update.

- The Lifetime field MUST be set to the remaining lifetime for the
binding as set by the BHR in its "Home Registration" Binding Cache
entry for the mobile node.

In addition, the BHR MUST follow the procedure defined in Section 8.2
to intercept packets on the mobile node's HOME link addressed to the
mobile node.

8.2 Intercepting Packets for a Mobile Node

While a node is serving as the BHR for the mobile node (while the node
has an entry in its Binding Cache for this mobile node that is marked
as a "Home Registration"), this node MUST attempt to intercept packets
on the mobile node's HOME link addressed to the mobile node. It MUST
return any Binding Request for any mobile node in BHR Entry, and it
MUST tunnel [6] all data packets that are sent to the mobile node if
there are any.

8.3 Tunnelled [6] Intercepted packets to a Mobile Node

For forwarding each intercepted data packet to the mobile node, the
BHR MUST tunnelled [6] the packet to the mobile node using IP in IP
[6] encapsulation. The tunnel entry point node is the BHR, and the
tunnel exit point node is the co-located address as registered with
the BHR
(It is the mobile node NEW link assigned address). When a BHR
encapsulates an intercepted packet for forwarding to the mobile node,
the BHR SHOULD set the Source Address in the tunnel IP header to the
BHR own IP address, and SHOULD set the Destination Address in the
tunnel IP header to the mobile node's co-located address.  When
received by the mobile node (using its co-located address), normal
processing of the tunnel header SHOULD result in de-capsulation and
processing of the original packet by the mobile node.













Chern Nam Yap             Expires 10 July 2001                 Page 30
Internet Draft        Itinerant Internet Protocol      10 January 2000

9. Temporary Visit Register Operation

A mobile node MUST register itself to the TVR while it is at visit
link.

9.1 Co-located Address Registration

When a node receives a Binding Update, it MUST validate it and
determine the type of Binding Update according to the steps described
in Section 7.1.  This section describes the processing of a valid
Binding Update that requests the receiving node to serve as its TVR,
registering its co-located address.

To begin processing the Binding Update, the TVR MUST perform the
following sequence of tests:

- If the visit address for the binding is not in the same TVR links,
then the TVR MUST reject the Binding Update and SHOULD return a
Binding Acknowledgement to the mobile node, in which the Status field
is set to 136 (Not visit subnet).

- Else, if the TVR chooses to reject the Binding Update for any other
reason (e.g., insufficient resources to serve another mobile node as a
TVR), then the TVR SHOULD return a Binding Acknowledgement to the
mobile node, in which the Status field is set to an appropriate value
to indicate the reason for the rejection.

If the TVR does not reject the Binding Update as described above, then
it SHOULD update its existing Binding Cache entry for this mobile
node. The visit address of the mobile node is taken from the Visit
Address field.  The co-located address for this Binding Cache entry is
taken from the Source Address field in the packet header.

The TVR MUST mark this Binding Cache entry as a "Visit Registration"
to indicate that the node is serving as a TVR for this binding.
Binding Cache entries marked as a "Visit Registration" MUST be
excluded from the normal cache replacement policy used for the Binding
Cache (Section 7.6) and MUST NOT be removed from the Binding Cache.
Binding Cache entries mark as a "Visit Registration" MUST be remove if
it receives a Binding Update without a "V" bit.

If the Acknowledge (A) bit is set in the Binding Update (it SHOULD
be), then the TVR MUST return a Binding Acknowledgement to the mobile
node, constructed as follows:




Chern Nam Yap             Expires 10 July 2001                 Page 31
Internet Draft        Itinerant Internet Protocol      10 January 2000

- The Status field MUST be set to a value indicating success (the
value MUST be less than 128). The only currently defined success
Status value is 0, indicating simply that the Binding Update was
accepted.

- The Sequence Number field MUST be copied from the Sequence Number
given in the Binding Update.

- The Lifetime field MUST be set to the remaining lifetime for the
binding as set by the TVR in its "Visit Registration" Binding
Cache entry for the mobile node.

In addition, the TVR MUST follow the procedure defined in Section 9.2
to intercept packets on the mobile node's TVR link addressed to the
mobile node.

9.2 Intercepting Packets for a Mobile Node

While a node is serving as the TVR for mobile node (while the node has
an entry in its Binding Cache for this mobile node that is marked as a
"Visit Registration"), this node MUST attempt to intercept packets on
the mobile node's visit link addressed to the mobile node. It MUST
tunnel [6] all data packet that is sent to the mobile node.

For forwarding each intercepted data packet to the mobile node, the
TVR MUST tunnels [6] the packets to the mobile node using IP in IP
encapsulation. The tunnel entry point node is the TVR, and the tunnel
exit point node is the co-located address as registered with the TVR.
When a TVR encapsulates an intercepted packet for forwarding to the
mobile node, the TVR sets the Source Address in the tunnel IP header
to the TVR own IP address, and sets the Destination Address in the
tunnel IP header to the mobile node's new co-located address.  When
received by the mobile node (using its co-located address), normal
processing of the tunnel header SHOULD result in de-capsulation and
processing of the original packet by the mobile node.













Chern Nam Yap             Expires 10 July 2001                 Page 32
Internet Draft        Itinerant Internet Protocol      10 January 2000

10. Near Correspondent Register Operation

If a mobile node receives a tunnelled packet, it SHOULD perform "short
circuit mechanism".

10.1 Near Correspondent Registration

When a node picks up the Shorted Flag, it MUST validate it by sending
a Binding Update to the mobile node. This node would only know about
the mobile node's home address. The mobile node would acknowledge and
at the same time send a Binding Updates with its latest co-located
address to the NCR. N bit MUST be set when these Binding Updates is
sent. This process is known as the two-way Near Correspondent
Registration.

When the NCR receives the Binding Update, it MUST validate it and
determine the type of Binding Update according to the steps described
in Section 7.1.  This section describes the processing of a valid
Binding Update that requests the receiving node update its co-located
address.

To begin processing the Binding Update, the NCR MUST perform the
following sequence of tests:

The NCR MUST mark this Binding Cache entry as a "Near Registration" to
indicate that the node is serving as a NCR for this binding. Binding
Cache entries mark as a "Near Registration" MAY be excluded from the
normal cache replacement policy used for the Binding Cache (Section
7.6) and MAY be removed from the Binding Cache. This is because there
is always a BHR to fall back on.

If the Acknowledge (A) bit is set in the Binding Update (it SHOULD
be), then the NCR MUST return a Binding Acknowledgement to the mobile
node, constructed as follows:

- The Status field MUST be set to a value indicating success (the
value MUST be less than 128).  The only currently defined success
Status value is 0, indicating simply that the Binding Update was
accepted.

- The Sequence Number field MUST be copied from the Sequence Number
given in the Binding Update.

- The Lifetime field MUST be set to the remaining lifetime for the
binding as set by the NCR in its "Near Registration" Binding Cache
entry for the mobile node.


Chern Nam Yap             Expires 10 July 2001                 Page 33
Internet Draft        Itinerant Internet Protocol      10 January 2000

In addition, the NCR MUST follow the procedure defined in Section 10.2
to intercept packets on the mobile node's HOME link addressed to the
mobile node.

10.2 Intercepting Packets for a Mobile Node

While a node is serving as the NCR for the mobile node, this node MAY
attempt to intercept packets. It MUST tunnel [6] all data packets that
are sent to the mobile node if there are any.

10.3 Tunnelled [6] Intercepted packets to a Mobile Node

For forwarding each intercepted data packet to the mobile node, the
NCR MUST tunnelled [6] the packet to the mobile node using IP in IP
[6] encapsulation. The tunnel entry point node is the NCR, and the
tunnel exit point node is the co-located address as registered with
the NCR
(It is the mobile node NEW link assigned address). When a NCR
encapsulates an intercepted packet for forwarding to the mobile node,
the NCR SHOULD set the Source Address in the tunnel IP header to the
NCR own IP address, and SHOULD set the Destination Address in the
tunnel IP header to the mobile node's co-located address.  When
received by the mobile node (using its co-located address), normal
processing of the tunnel header SHOULD result in de-capsulation and
processing of the original packet by the mobile node.
























Chern Nam Yap             Expires 10 July 2001                 Page 34
Internet Draft        Itinerant Internet Protocol      10 January 2000

11. Mobile Node Operation

11.1 Sending Packets While Away from Home

While a mobile node is away from home, it uses its newly acquired co-
located address. For packets sent by a mobile node while it is at
home, no special IIP processing is required for sending this packet.
If the mobile node uses any address other than its home address as the
source of a packet sent while away from home (from the point of view
of applications, as described above), no special Itinerant Internet
Protocol processing is required for sending that packet. In each case,
the packet is simply addressed and transmitted in the same way as any
normal IP packet.

By using the co-located address as the Source Address in the IP
header, the packet SHOULD be able to safely pass through any router
implementing ingress filtering [1].

11.2 Receiving Packets While Away from Home

While away from home, a mobile node SHOULD receive packets by one of
two methods:

- The mobile aware correspondent node SHOULD first send a Binding
Request to mobile node home address, which SHOULD be intercepted and
the reply with a Binding Update. Hence the correspondent node sends
all its data packets to the mobile node, using its co-located address
as the destination IP address of these packets.

- The non-mobile aware correspondent node SHOULD send the data packets
to the mobile node's home address, which SHOULD be intercepted and
tunnelled [6] to the mobile node.

11.3 Movement Detection

A mobile node uses Subnet Prefix Matching Switching mechanism method
to detect when it has moved from one link to another. The Prefix
Matching Switching mechanism (For example IIP periodically detects
changes in IP address that is being assigned during communication.
Once a movement is done, PPP SHOULD use IPCP [12] function to assign
another new IP address, hence that is used as a hint of movement.)







Chern Nam Yap             Expires 10 July 2001                 Page 35
Internet Draft        Itinerant Internet Protocol      10 January 2000

This method is very reliable as assignment of new IP address on a new
prefix means a confirmation establishment in link layer of a new IP
subnet. The new assigned IP address SHOULD hence be the new co-located
address. Once this is being done, the mobile node SHOULD need to
immediately send Binding Updates to its BHR/TVR/NCR and correspondent
node.

11.4 Sending Binding Updates to the Base Home Register

After a mobile node has changed one of its addresses to a new co-
located address, a mobile node MUST register this co-located address
with its BHR. To do so, the mobile node SHOULD send a Binding Update
packet to its BHR and the packet constructed as follows:

- The Home Registration (H) bit MUST be set in the Binding Update.

- The Acknowledge (A) bit MUST be set in the Binding Update.

- The packet MUST contain a Home Address field that contain its home
address.

- The mobile MUST use the new co-located address as source to send the
Binding Update.

- The value specified in the Lifetime field SHOULD be less than or
equal to the remaining lifetime of the co-located address specified
for the binding.

The Acknowledge (A) bit in the Binding Update requests from the BHR to
return a Binding Acknowledgement in response to this Binding Update.
As described in Section 5.2, the mobile node MUST retransmit this
Binding Update to its BHR until it receives a matching Binding
Acknowledgement. Once reaching a retransmission timeout period of
MAX_TIMEOUT, the mobile node SHOULD continue to periodically
retransmit the Binding Update at this rate until acknowledged.

When sending a Binding Update to its BHR, the mobile node MUST also
create or update the corresponding Binding Update List entry, as
specified in Section 10.6.









Chern Nam Yap             Expires 10 July 2001                 Page 36
Internet Draft        Itinerant Internet Protocol      10 January 2000

11.5 Sending Binding Updates to the Temporary Visit Register

After a mobile node has changed one of its addresses to a new co-
located address, a mobile node MUST register this co-located address
with its TVR. To do so, the mobile node SHOULD send a Binding
Update packet to its OLD link TVR and the packet constructed as
follows:

- The Visit Registration (V) bit MUST be set in the Binding Update.

- The Acknowledge (A) bit MUST be set in the Binding Update.

- The packet MUST contain a Visit Address field that contains its
visit address

- The mobile MUST use the new co-located address as source to send the
Binding Update.

- The value specified in the Lifetime field SHOULD be less than or
equal to the remaining lifetime of the co-located address specified
for the binding.

11.6 Sending Binding Updates to the Near Correspondent Register

After a mobile node has changed one of its addresses to a new co-
located address, a mobile node MUST register this co-located address
with its NCR. To do so, the mobile node SHOULD send a Binding
Update packet to all its NCR and the packet constructed as follows:

- The Near Registration (N) bit MUST be set in the Binding Update.

- The Acknowledge (A) bit MUST be set in the Binding Update.

- The packet MUST contain a Home Address field that contains its home
address

- The mobile MUST use the new co-located address as source to send the
Binding Update.

- The value specified in the Lifetime field SHOULD be less than or
equal to the remaining lifetime of the co-located address specified
for the binding.






Chern Nam Yap             Expires 10 July 2001                 Page 37
Internet Draft        Itinerant Internet Protocol      10 January 2000

11.7 Sending Binding Updates to Correspondent Nodes

A mobile node MUST immediately send a Binding Update to all
correspondent nodes that it is communicating once it has acquired a
new co-located address. The Binding Update requests the correspondent
node to update an entry for the mobile node in the correspondent
node's Binding Cache to record this co-located address for use in
sending packets to the mobile node.  In this case, the value specified
in the lifetime field sent in the Binding Update SHOULD be less than
or equal to the remaining lifetime of the co-located specified for the
binding.

If, instead, the packet source address is set to the mobile node's
home address, the Binding Update SHOULD request the correspondent node
to delete any existing Binding Cache entry that it has for the mobile
node.

When sending any Binding Update, the mobile node MUST record in its
Binding Update List the following fields from the Binding Update:

- The IP address of the node to which the Binding Update was sent.

- The home address for which the Binding Update was sent (the value in
the Home Address field).

- The initial lifetime of the binding, initialised from the Lifetime
field sent in the Binding Update.

- The remaining lifetime of the binding is also initialised from the
Lifetime field sent in the Binding Update. This remaining lifetime
value counts down and MAY also be reduced when the matching Binding
Acknowledgement is received, based on the Lifetime value specified in
that Binding Acknowledgement, as described in Section 10.8.  When this
remaining lifetime reaches zero, the Binding Update List entry MUST be
deleted.

The mobile node MUST retain in its Binding Update List information
about all Binding Updates sent, for which the lifetime of the binding
has not yet expired.  However, when sending a Binding Update, if an
entry already exists in the mobile node's Binding Update List for an
earlier Binding Update sent to that same destination node, the
existing Binding Update List entry SHOULD be updated to reflect the
new Binding Update rather than creating a new Binding Update List
entry.




Chern Nam Yap             Expires 10 July 2001                 Page 38
Internet Draft        Itinerant Internet Protocol      10 January 2000

Binding Updates that is sent to all its correspondent nodes has no
requirement for acknowledgement.  However, if the mobile node wants to
be sure that its new co-located address has been entered into a
correspondent node's Binding Cache, the mobile node MAY request an
acknowledgement by setting the Acknowledge (A) bit in the Binding
Update.  In this case, however, the mobile node SHOULD NOT continues
to retransmit the Binding Update once the retransmission timeout
period has reached MAX_TIMEOUT.

11.8 Retransmit Binding Updates

If, after sending a Binding Update in which the Acknowledge (A) bit is
set, a mobile node fails to receive a valid, matching Binding
Acknowledgement within INITIAL_TIMEOUT seconds, the mobile node SHOULD
retransmit the Binding Update, until a Binding Acknowledgement is
received.  Such a retransmitted Binding Update MUST use a Sequence
Number value greater than that used for the previous transmission of
this Binding Update.  The retransmissions by the mobile node MUST use
an exponential back-off process, in which the timeout period is
doubled upon each retransmission until either the node receives a
Binding Acknowledgement or the timeout period reaches the value
MAX_TIMEOUT.

11.9 Receiving Binding Acknowledgements

Upon receiving a packet carrying a Binding Acknowledgement, a mobile
node MUST validate the packet according to the following tests:

- The packet meets the specific IPSec [2] requirements for Binding
Acknowledgements, defined in Section 4.3.

- The Sequence Number field matches the Sequence Number sent by the
mobile node to this destination address in an outstanding Binding
Update.

Any Binding Acknowledgement not satisfying all of these tests MUST be
silently ignored.











Chern Nam Yap             Expires 10 July 2001                 Page 39
Internet Draft        Itinerant Internet Protocol      10 January 2000

When a mobile node receives a packet carrying a valid Binding
Acknowledgement, the mobile node MUST examine the Status field as
follows:

- If the Status field indicates that the Binding Update was accepted
(the Status field is less than 128), then the mobile node MUST update
the corresponding entry in its Binding Update List to indicate that
the Binding Update has been acknowledged. The mobile node MUST then
stop retransmits the Binding Update. In addition, if the value
specified in the Lifetime field in the Binding Acknowledgement is less
than the Lifetime value sent in the Binding Update being acknowledged,
then the mobile node MUST subtract the difference between these two
Lifetime values from the remaining lifetime for the binding as
maintained in the corresponding Binding Update List entry (with a
minimum value for the Binding Update List entry lifetime of 0).  That
is, if the Lifetime value sent in the Binding Update was <update>, the
Lifetime value received in the Binding Acknowledgement was <ack>, and
the current remaining lifetime of the Binding Update List entry is
<remain>, then the new value for the remaining lifetime of the Binding
Update List entry SHOULD be

                MAX((remain - (update - ack)), 0)

Where Max(X, Y) is the maximum of X and Y. The effect of this step is
to correctly manage the mobile node's view of the binding's remaining
lifetime (as maintained in the corresponding Binding Update List
entry) so that it correctly counts down from the Lifetime value given
in the Binding Acknowledgement, but with the timer countdown beginning
at the time that the Binding Update was sent.

- If the Status field indicates that the Binding Update was rejected
(the Status field is greater than or equal to 128), then the mobile
node MUST delete the corresponding Binding Update List entry (and MUST
also stop retransmit the Binding Update).

11.10 Routing Multicast Packets

A mobile node that is connected to its HOME link functions in the same
way as any other (stationary) node.  Thus, when it is at home, a
mobile node functions identically to other multicast senders and
receivers. This section therefore describes the behaviour of a mobile
node that is not on its HOME link.






Chern Nam Yap             Expires 10 July 2001                 Page 40
Internet Draft        Itinerant Internet Protocol      10 January 2000

In order to receive packets sent to some multicast group, a mobile
node MUST join that multicast group.  A mobile node SHOULD join the
group via a (local) multicast router on the Visit link. The mobile
node SHOULD use its co-located address sharing a subnet prefix with
the multicast router, as the source IP address of its multicast group
membership control messages.

A mobile node MAY join multicast groups via a bi-directional tunnel
[6] to its BHR/TVR. The mobile node tunnels [6] its multicast group
membership control packets to its BHR/TVR, and the BHR/TVR forwards
multicast packets down the tunnel [6] to the mobile node.





































Chern Nam Yap             Expires 10 July 2001                 Page 41
Internet Draft        Itinerant Internet Protocol      10 January 2000

12. Protocol Constants

INITIAL_TIMEOUT   1 second

MAX_TIMEOUT       256 seconds











































Chern Nam Yap             Expires 10 July 2001                 Page 42
Internet Draft        Itinerant Internet Protocol      10 January 2000

13. IANA Considerations

This document defines three new types of UDP packets, which need to
have assigned a port number (Section 4.1).

Moreover each of which must be assigned an Option Type value:

-  The Binding Update packet, described in Section 4.1;

-  The Binding Acknowledgement packet, described in Section 4.2;

-  The Binding Request packet described in Section 4.3.




































Chern Nam Yap             Expires 10 July 2001                 Page 43
Internet Draft        Itinerant Internet Protocol      10 January 2000


Reference

 [1] Paul Ferguson and Daniel Senie.  Network ingress filtering:
     Defeating denial of service attacks which employ IP source
     address spoofing.  RFC 2267, January 1998.

 [2] Stephen Kent and Randall Atkinson.  Security architecture for
     the Internet Protocol.  RFC 2401, November 1998.

 [3] Scott Bradner.  Key words for use in RFCs to indicate
     requirement levels.  RFC 2119, March 1997.

 [4] Stephen Kent and Randall Atkinson.  IP Authentication header.
     RFC 2402, November 1998.

 [5] Stephen Kent and Randall Atkinson.  IP Encapsulating Security
     Payload (ESP).  RFC 2406, November 1998.

 [6] Charles Perkins.  IP encapsulation within IP.  RFC 2003, October
     1996.

 [7] Charles Perkins, editor.  IP mobility support.  RFC 2002,
     October 1996.

 [8] David C. Plummer.  An Ethernet address resolution protocol:
     Or converting network protocol addresses to 48.bit Ethernet
     addresses for transmission on Ethernet hardware.  RFC 826,
     November 1982.

 [9] J. B. Postel.  User Datagram Protocol.  RFC 768, August 1980.

 [10] J. B. Postel, editor.  Transmission Control Protocol.  RFC 793,
      September 1981.

 [11] Thomas Narten, Erik Nordmark, and William Allen Simpson.
      Neighbor Discovery for IP version 6 (IPv6).  RFC 2461, December
      1998.

 [12] Glenn McGregor. The PPP Internet Protocol Control Protocol
      (IPCP). RFC 1332, May 1992

 [13] Charles Perkins, editor.  IP mobility support for IPv6.
      Internet Draft version 12, April 2000.

 [14] Stewart, editor. Stream Control Transmission Protocol.
      Internet Draft version 13, July 2000.

Chern Nam Yap             Expires 10 July 2001                 Page 44
Internet Draft        Itinerant Internet Protocol      10 January 2000

Comments about this document SHOULD be discussed on the
   seamoby@egroups.com mailing list or


Authors' Addresses

   Questions about this document can also be directed to the authors:

     Chern Nam Yap
     Centre for Mobile Communication Research
     Department of Electronic and Electrical Engineering
     University of Sheffield
     F132 Mappin Building
     Mapping Street
     Sheffield S3 3JD

     Phone: +44 114 222 5182
     Web: http://www.mobile1.net
     E-mail: cny@ieee.org


------=_NextPart_000_0130_01C07C85.B77497A0--



From owner-seamoby@diameter.org  Fri Jan 12 11:05:54 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11442
	for <seamoby-archive@odin.ietf.org>; Fri, 12 Jan 2001 11:05:53 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0CF5UL25101
	for seamoby-list; Fri, 12 Jan 2001 07:05:30 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from c007.snv.cp.net (c007-h015.c007.snv.cp.net [209.228.33.222])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f0CF4DW25096
	for <seamoby@diameter.org>; Fri, 12 Jan 2001 07:04:13 -0800
Received: (cpmta 25993 invoked from network); 12 Jan 2001 06:12:11 -0800
Received: from unknown (HELO telocity.com) (64.193.0.129)
  by smtp.telocity.com (209.228.33.222) with SMTP; 12 Jan 2001 06:12:11 -0800
X-Sent: 12 Jan 2001 14:12:11 GMT
Message-ID: <3A5F110C.DE77F1B2@telocity.com>
Date: Fri, 12 Jan 2001 08:13:32 -0600
From: Phil Neumiller <neumiller@telocity.com>
Organization: 3Com
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: seamoby@diameter.org
Subject: [seamoby] Request to Design Team Leaders
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

I have tried to go back through the mail and make sense
of everything that has transpired.  It would be very useful
if each of the design team leaders would RESTATE their current
best understanding of their respective problem statements.

Maybe this has been done already, but I would appreciate if
it were done once more to the SeaMoby list.  This may help
some of us catch up.  I have had some nasty Email problems
on both of my accounts and probably missed some mail.

Hopefully the design team lists are archived.

Thank you,

Phil


From owner-seamoby@diameter.org  Fri Jan 12 11:36:17 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11872
	for <seamoby-archive@odin.ietf.org>; Fri, 12 Jan 2001 11:36:17 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0CFBhg25113
	for seamoby-list; Fri, 12 Jan 2001 07:11:43 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0CFAQW25108
	for <seamoby@diameter.org>; Fri, 12 Jan 2001 07:10:26 -0800
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA17761;
	Fri, 12 Jan 2001 06:18:28 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA04718;
	Fri, 12 Jan 2001 06:18:27 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id GAA22529;
	Fri, 12 Jan 2001 06:18:26 -0800 (PST)
Date: Fri, 12 Jan 2001 06:14:49 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [seamoby] Request to Design Team Leaders
To: Phil Neumiller <neumiller@telocity.com>
Cc: seamoby@diameter.org
In-Reply-To: "Your message with ID" <3A5F110C.DE77F1B2@telocity.com>
Message-ID: <Roam.SIMC.2.0.6.979308889.26750.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

The archives for paging and micro-mobility can be found @
www.diameter.org/seamoby.html. I am assured by Gary that the context sublist
is also archived, but due to some internal e-mail problems on his side, I
haven't been able to contact him.

PatC



From owner-seamoby@diameter.org  Fri Jan 12 12:45:12 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13610
	for <seamoby-archive@odin.ietf.org>; Fri, 12 Jan 2001 12:45:11 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0CGt4u25251
	for seamoby-list; Fri, 12 Jan 2001 08:55:04 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0CGt0W25246
	for <seamoby@diameter.org>; Fri, 12 Jan 2001 08:55:00 -0800
Received: from melkinpaasi.cs.Helsinki.FI (jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.8.8/8.8.8) with ESMTP id SAA14162 for <seamoby@diameter.org>; Fri, 12 Jan 2001 18:02:59 +0200
Date: Fri, 12 Jan 2001 18:02:54 +0200 (EET)
From: Jukka Manner <jmanner@cs.helsinki.fi>
To: <seamoby@diameter.org>
Message-ID: <Pine.LNX.4.30.0101121757400.11672-100000@melkinpaasi.cs.Helsinki.FI>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk


	Hi all,

	I just submitted an Internet Draft that tries to define common
terminology. The draft is a collaborative effort between people from many
different engineering backgrounds and so already presents a first step in
harmonizing the terminology used around IP mobility. Here is URL for the draft
in case someone wants to take a look at it and comment before it is officially
announced.

http://www.cs.helsinki.fi/u/jmanner/draft-brain-seamoby-terms-00.txt


	Best regards,

	Jukka Manner



From owner-seamoby@diameter.org  Fri Jan 12 19:50:32 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27358
	for <seamoby-archive@odin.ietf.org>; Fri, 12 Jan 2001 19:50:31 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0D0I2u25895
	for seamoby-list; Fri, 12 Jan 2001 16:18:02 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mailhub1.shef.ac.uk (mailhub1.shef.ac.uk [143.167.1.9])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0D0HxW25890
	for <seamoby@diameter.org>; Fri, 12 Jan 2001 16:17:59 -0800
Received: from ridingwood.shef.ac.uk ([143.167.59.249])
	by mailhub1.shef.ac.uk with esmtp (Exim 3.16 #1)
	id 14HDa1-0007dk-00; Fri, 12 Jan 2001 23:25:57 +0000
Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48);
    12 Jan 01 23:25:58 +0000
Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 12 Jan 01 23:25:43 +0000
Received: from Mobile1 (143.167.59.146) by ridingwood.shef.ac.uk (Mercury 1.48);
    12 Jan 01 23:25:39 +0000
Message-ID: <005701c07cee$84fcbaf0$923ba78f@Mobile1>
Reply-To: "cnyap" <cny@ieee.org>
From: "cnyap" <cny@dcs.shef.ac.uk>
To: "Jukka Manner" <jmanner@cs.helsinki.fi>, <seamoby@diameter.org>
References: <Pine.LNX.4.30.0101121757400.11672-100000@melkinpaasi.cs.Helsinki.FI>
Subject: [seamoby] Re: 
Date: Fri, 12 Jan 2001 23:22:23 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi

Could you please give more explaination on Intra-AR Handover.
It is not very clear in the draft.

Thanks
Chern Nam Yap
MIEEE, MSc(Res), BSc(Hons)
Research Associate
Center for Mobile Communication Research
Department of Electronic and Electrical Engineering
University of Sheffield
F132 Mappin Building
Mappin Street
Sheffield S1 3JD
United Kingdom
Tel:+44 (0) 114-222-5182
Mobile:+ 44(0) 7712804892
Web: www.mobile1.net
E-mail: cny@ieee.org














----- Original Message -----
From: "Jukka Manner" <jmanner@cs.helsinki.fi>
To: <seamoby@diameter.org>
Sent: Friday, January 12, 2001 4:02 PM


>
> Hi all,
>
> I just submitted an Internet Draft that tries to define common
> terminology. The draft is a collaborative effort between people from many
> different engineering backgrounds and so already presents a first step in
> harmonizing the terminology used around IP mobility. Here is URL for the
draft
> in case someone wants to take a look at it and comment before it is
officially
> announced.
>
> http://www.cs.helsinki.fi/u/jmanner/draft-brain-seamoby-terms-00.txt
>
>
> Best regards,
>
> Jukka Manner
>



From owner-seamoby@diameter.org  Fri Jan 12 20:11:05 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27518
	for <seamoby-archive@odin.ietf.org>; Fri, 12 Jan 2001 20:11:04 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0D0YBw25909
	for seamoby-list; Fri, 12 Jan 2001 16:34:11 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0D0Y8W25904
	for <seamoby@cdma-2000.org>; Fri, 12 Jan 2001 16:34:08 -0800
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14540;
	Fri, 12 Jan 2001 15:42:10 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA07436;
	Fri, 12 Jan 2001 15:42:09 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA12709;
	Fri, 12 Jan 2001 15:42:05 -0800 (PST)
Date: Fri, 12 Jan 2001 15:38:27 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: [seamoby] Seamoby WG meeting minutes for San Diego IETF
To: minutes@ietf.org
Cc: seamoby@cdma-2000.org
Message-ID: <Roam.SIMC.2.0.6.979342707.31271.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-LA_F2158814900R-3A-979342708=:9337NCE.IlHAFeR"
Sender: owner-seamoby@diameter.org
Precedence: bulk

---LA_F2158814900R-3A-979342708=:9337NCE.IlHAFeR
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

Please find the attached minutes for the meeting.

Thanks,

PatC

---LA_F2158814900R-3A-979342708=:9337NCE.IlHAFeR
Content-Type: TEXT/plain; name="seamoby-minutes.txt"; charset=us-ascii
Content-Description: default

49th IETF in San Diego
Seamoby Working Group

Chairs: Pat Calhoun (pcalhoun@eng.sun.com)
	Phil Neumiller (phil_neumiller@3com.com)

minutes by: La Monte Henry Piggy Yarroll (piggy@em.cig.mot.com)


Meeting Summary:

As a result of the meeting, three design groups were formed. James Kempf
(james.kempf@eng.sun.com) will lead the paging team, Dana Blair
(dblair@cisco.com) will lead the micro-mobility team, while Gary Kenward
(gkenward@nortelnetworks.com) will lead the context transfer team).

The design teams are responsible for coming up with a problem statement
for their respective area.


Minutes:

1. Agenda

  Agenda Bashing
  Ground Rules
	- Chairs are very firm about charter.
	- White gloves only
  Milestones
	- Layer 3 paging
	  A point was made that the working group should first handle context
	  transfer, given that this was the most complicated work item.
	  The chair stated that all work will progress in parallel.

	  Another point was made that paging should exist in the Mobile IP WG,
	  but MIP has already agreed that paging is not within its charter.

	- Micro-Mobility
	  A point was made that a succinct definition of WHAT Micro-mobility
	  IS, is lacking from OUR COMMON VOCABULARY.

	  Sampling question:  Do we need to reassess?  Is MobileIP becoming
	  sufficient (see 3 above)?
	  We need a clear problem statement.

	  A point was made that MIP may be sufficient, but there are scenarios
	  that might need more than MIP. We need some scenarios. Is MM mobility
	  within a subnet? Why doesn't MIP solve this? Why aren't the current
	  radio protocols sufficient?

	  The MIP WG co-chair stated that we should explore the possible
	  solutions which MIP is NOT exploring. There is an ID presented
	  that has such a problem description., which will be presented
	  in the meeting.

	  The chair stated that we need a set of requirements.  We need a
	  separate design team for a problem statement and a set of
	  requirements.

	  Ideally, submit candidate protocols around about 22 February.
	  REQUIRED is a document that compares the protocol to the
	  requirements.

	  A comment was made that we should not over-narrow the scope of the
	  WG. Another comment was made that some Mobile IP submissions might
	  be relevant to some of our work items, and that we should take a
	  closer look at what's going on in MIP.

	  An evaluation team will then select a protocol from the submitted
	  candidates. A comment was made that evaluation teams are against
	  the IETF mantra, and the working group should be the one that
	  decides. There was some concern as to whether one single solution
	  could be chosen, which the AD responded that one is sufficient,
	  more would create confusion in the marketplace. There was many
	  discussions on whether one or more problems are appropriate, and
	  the problem description should address that issue.

	  There was another thread that questioned what kind of solutions are
	  appropriate, whether it's routing, link or application. Some 
	  suggested routing.

	- State Transfer

	  There are three options that the WG should evaluate:
	    1. Have the network nodes transfer state
	    2. Let the mobiles upload their state
	    3. Let the mobiles renegotiate with network
	  Comments were made that the first option seems most likely, and
	  would probably best provide seamless mobility.

	  There was some discussion on what state transfer is, and isn't,
	  but a problem statement is required, as per our charter, for
	  the IESG to decide whether the work will be done.


2. Seamoby Reference Model

  Phil Neumiller presented a reference model with a picture of some
  kinds of MIP peer within IP and "Hints" going down to layer 2. 
  There was also another diagram provided by Phil that shows a network 
  doing a vertical handoff. There was much controversy on what the pictures 
  meant, and where some functions resided, but the main focus was to show 
  that multi-technology handoffs should be possible. How it is done is
  something that can only be answered once a problem statement has been
  written.

  There were more discussions on how QoS is affected in a seamoby
  environment, and another diagram showing an actual handoff taking
  place. There was a comment that Mobile IP already solves this problem,
  but Mobile IP doesn't handle mobile routers or subnets.


3. Seamoby Concerns (John Loughney)

  John Loughney presented some concerns, and in his presentations he showed
  a long list of handover types, followed by a list of definitions of the
  various handover types, such as seamless, fast, smooth, etc. There was
  a slide that discussed context transfer, which may include compression state,
  policy, security, etc. There was a question as to what kind of state we
  really want to send, what makes sense? There was a comment that end-to-end
  QoS is obviously out of scope, given that the edge has no control over
  the network (and the endpoint), so there are no QoS guarantees.

  John then presented some of his requirements, which are:
	-- IPv6-friendly
	-- Split micro/macro  (e.g. minimize reauthentication)
	-- Layer 2 independent, but use what we can
	   "Do what you can locally, but go global when necessary."
	-- minimize air signaling
	-- applications should not need to be mobile-aware
	-- Security is important

  His drafts will be announced on the mailing list.


4. SeaMoby Header Compression (Rajeev Koodli)

  Rejeev is presenting his two Internet Drafts:
	draft-koodli-rohc-hc-relocate-00.txt
	draft-koodli-mobileip-smoothv6-00.txt

  The problem is how to move the compression state from an
  old router to a new router. The proposed solution is HCRP,
  where the MN asks the new router to fetch the context from
  the old router.

  There are many compression profile types, so what kind of
  compression info is needed? A possible work item is to define
  a bunch of compression profiles, but a question was raised as
  to what the savings were. The response was that packet loss over
  the air could cause problems for state handoff.


5. Cellular IP

  Andrew Campbell presented Cellular IP, and stated that more information
  on Cellular IP can be found on the web site (both the code and the docs).
  The discussion was not Mobile IP does not scale as well as IP, and that
  something new is required. Many comments were made in regards to this
  presentation, but the fact of the matter is that we need to understand
  the problem before we look into the solutions.

  More questioned how a stateful protocol can be more scalable than a
  stateless protocol, and questions on how L3 paging can be used, etc.
  However, these were all solutions, and not requirements.

  There was a comment on why this presentation was made here, given that
  we aren't at the solutions stage yes, which drew some applause some the
  audience. The response from the chair was fairness.


6. State transfer between Access Routers during Handoff

  Context Transfer++ (draft-oneill-handoff-state-00.txt) was
  presented, and briefly summarized some of the states that need
  to be transferred to expose some of the gory bits. The transferred
  state might have some attachment to surrounding universe of the
  edge router. 

  Some approaches were discussed, such as allowing the mobile to rebuild
  the state on the new router using the appropriate protocols (e.g. RSVP,
  Mobile IP, etc). It was noted that it make take several seconds to
  rebuild the state. Another approach is to assume that the Mobile Node
  can securely upload all of the state to the new router, but the
  speaker stated that there are some trust issues in this model. Another
  model is to allow the routers to exchange the states directly.

  An example of state that could be transferred was multicast information.
  We could not do anything, and let the mobile rejoin, have the mobile 
  send IGMP information to the router, or have the old router send the
  IGMP information to the new router.

  The recommended approach was to document the state, design a solution
  and document it per protocol. First, we should document the requirements
  for generalized context transfer.

  There were questions whether this could be handled at layer 2, and 
  the feeling was no.

  A question was raised why is there a need for seamless handoff in the
  first place, where Charlie Perkins answered "S a m e s H nd  v r".


7. Buffer Mgmt (Charlie Perkins, the Tallest MIP Designer)

  Rate of beacons in MIP is too slow to do voice buffering, but if you
  increase the beacon rate you can make it work.
  Hand over 2-3 buffers and you get pretty-good results.
  Holy Grail:  Do smooth voice hand-over.
  Problem statement (paraphrase): "Mobile node has some context and
  needs to retrieve it later..."


8. Realtime Mobile IPv6

  Dana Blair presented draft-blair-rt-mobileipv6-seamoby-00.txt. The
  goals of the draft are:
	- Address HO for realtime within subnets (micro) and
	  between subnets (macro).
	- Address access, AAA, QoS, IPSec, handoff signaling.
	- Common terminology
  Dana presented some Micro-Mobility objectives, which should become
  requirements:
	- Minimize packets sent/received by mobile
	- Minimize time between access link changes
	- Minimize lots of other stuff...
	  Ditto for Macro-mobility

  There were a few proposed solutions:
	- Combine the whole mess into a single message from the mobile
	- Cache context
	- Re-use existing protocols
	- Avoid a new protocol

  There was a question whether minimizing packets meant round trips,
  and the speaker answered that packets matter too. Another questioned
  why multicasting was missing (as a state to transfer), and the answer
  was that it hadn't come up, and it did complicate the problem. Another
  questioned whether a single packet solution (to transfer state)
  generalized lots of other stuff, but someone stated that some state
  information may not fit in a single packet. Lastly, someone questioned
  the reliability of a single packet handoff.


9. Next steps
  Chair: Who wants to participate in the problem statement?  (Many hands)
  Who wants to do the administrative overhead?
  Context Transfer: Gary Kenward
  MM: Dana Blair
  Paging: James Kempf

  A comment was made that all micro-mobility people should simply post
  their comments to the main list. A follow-on stated that everybody has
  their own terminology, and a team would help tp to unify the terminology.

  Another comment was made that the dates in the milestone are too aggressive.
  The chair responded that this was caused by the latency in fixing the
  charter to address IESG comments, and its approval. This can be changed at
  the next charter review.

---LA_F2158814900R-3A-979342708=:9337NCE.IlHAFeR--


From owner-seamoby@diameter.org  Fri Jan 12 21:18:33 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28120
	for <seamoby-archive@odin.ietf.org>; Fri, 12 Jan 2001 21:18:33 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0D1POi25935
	for seamoby-list; Fri, 12 Jan 2001 17:25:24 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0D1PLW25930
	for <seamoby@diameter.org>; Fri, 12 Jan 2001 17:25:21 -0800
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id QAA26721
	for <seamoby@diameter.org>; Fri, 12 Jan 2001 16:33:21 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA22901; Fri, 12 Jan 2001 16:33:21 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14943.41553.643547.108090@thomasm-u1.cisco.com>
Date: Fri, 12 Jan 2001 16:33:21 -0800 (PST)
To: seamoby@diameter.org
Subject: [seamoby] micro, schmicro
In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE1031DF59E@eseis04nok>
References: <01D91AFB08B6D211BFD00008C7EABAE1031DF59E@eseis04nok>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

john.loughney@nokia.com writes:
 > I think that we should define micromobility as mobility
 > within a subnet and/or domain.  Macromobility then would
 > be mobility between subnets and/or domains.

Not to pick on John, but...

I'm probably the only one, but I find this desire
to find a home for the phrases "micro mobility"
and "macro mobility" to be almost, well...
procrustean. I've yet to see why the use of these
two terms yield any light, nor do they seem to
yield a useful taxonomy. Instead, they seem to be
like dummies that we are hide-bound to find some
appropriate clothes for them to don.

It seems clear that there is a set of variables of
how movement happens (MBB, BBM), whether the MN or
AR or initiates the move, whether or not it
crosses a trust boundary, whether or not it needs
to move subnets, etc, etc. What doesn't seem clear
to me _at all_ is that these, in fact, collapse
into exactly two scenarios. Even if they did
collapse into two, it's even less clear that
"micro" and "macro" are within 90 degrees of what
the scenarios should be named.

It seems to me that instead of getting wrapped
around the axle about how many angels dance on the
head of micro and macro, it would be better to
agree on what all of the variables are, how they
interact, and what these of scenarios we have
to consider are.

	    Mike

  


From owner-seamoby@diameter.org  Fri Jan 12 21:22:36 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28147
	for <seamoby-archive@odin.ietf.org>; Fri, 12 Jan 2001 21:22:35 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0D1YBu25947
	for seamoby-list; Fri, 12 Jan 2001 17:34:11 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0D1Y9W25942
	for <seamoby@diameter.org>; Fri, 12 Jan 2001 17:34:09 -0800
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA05593;
	Fri, 12 Jan 2001 16:42:13 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA15654;
	Fri, 12 Jan 2001 16:42:12 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA14213;
	Fri, 12 Jan 2001 16:42:10 -0800 (PST)
Date: Fri, 12 Jan 2001 16:38:31 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [seamoby] micro, schmicro
To: Michael Thomas <mat@cisco.com>
Cc: seamoby@diameter.org
In-Reply-To: "Your message with ID" <14943.41553.643547.108090@thomasm-u1.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.979346311.23224.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

Michael,

You do have a point, but my experience is that it is really hard to all agree
on a problem, if we cannot even agree on a set of terminology. That said, if
you'd like to provide these "variables" for all to see, we can then call these
two scenarios foo and bar, and then move on.

For those of you that are not in the context list, we had a call earlier this
week, agreed on an architecture, and the basis for a problem statement. A good
portion of the call was to make sure that we were all in agreement, and this
included agreeing on terminology.

my 2 cents,

PatC
> john.loughney@nokia.com writes:
>  > I think that we should define micromobility as mobility
>  > within a subnet and/or domain.  Macromobility then would
>  > be mobility between subnets and/or domains.
> 
> Not to pick on John, but...
> 
> I'm probably the only one, but I find this desire
> to find a home for the phrases "micro mobility"
> and "macro mobility" to be almost, well...
> procrustean. I've yet to see why the use of these
> two terms yield any light, nor do they seem to
> yield a useful taxonomy. Instead, they seem to be
> like dummies that we are hide-bound to find some
> appropriate clothes for them to don.
> 
> It seems clear that there is a set of variables of
> how movement happens (MBB, BBM), whether the MN or
> AR or initiates the move, whether or not it
> crosses a trust boundary, whether or not it needs
> to move subnets, etc, etc. What doesn't seem clear
> to me _at all_ is that these, in fact, collapse
> into exactly two scenarios. Even if they did
> collapse into two, it's even less clear that
> "micro" and "macro" are within 90 degrees of what
> the scenarios should be named.
> 
> It seems to me that instead of getting wrapped
> around the axle about how many angels dance on the
> head of micro and macro, it would be better to
> agree on what all of the variables are, how they
> interact, and what these of scenarios we have
> to consider are.
> 
> 	    Mike
> 
>   




From owner-seamoby@diameter.org  Sat Jan 13 01:51:53 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07888
	for <seamoby-archive@odin.ietf.org>; Sat, 13 Jan 2001 01:51:52 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0D66Is26056
	for seamoby-list; Fri, 12 Jan 2001 22:06:18 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0D651W26051
	for <seamoby@diameter.org>; Fri, 12 Jan 2001 22:05:01 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <CTQSVW57>; Sat, 13 Jan 2001 00:13:06 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078B97@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: Colin Elliott <celliott@zucotto.com>, seamoby-paging@egroups.com,
        James Kempf <James.Kempf@eng.sun.com>, James.Kempf@eng.sun.com,
        ramjee@dnrc.bell-labs.com
Cc: seamoby@diameter.org, Phil_Neumiller@3Com.com, seamoby-paging@egroups.com
Subject: RE: [seamoby-paging] RE: [seamoby] Some thoughts on paging proble
	 m
Date: Sat, 13 Jan 2001 00:13:00 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

 
> Two observations from what you are stating:
> 
> 1. RSSI happens at L1 and L2 and FA and mobile IP stuff happens at L3
> 2. there are scenarios where AP (terminating the wireless L2) 
> and FA could 
> be over a routed cloud.

Let me describe my view of the wireless IP access network.
 
AP (Access Point): stationary wireless device with wired link to AR.
AR (Access Router): stationary wired/wireless router connected to at least
one AP. 
MN (Mobile Node): a mobile device with a wireless link.  The mobile device
may act as a mobile router if the *particular network* permits.

Re-phrasing:  The APs compare Radio Signal Strength results through the ARs
with a real-time RTT (Round-Trip-Time).

Real-time switching cannot happen over an unbounded routed cloud.  We must
consider Round-Trip-Time between ARs.  Round-Trip-Time must be less than the
Real-time response time for the switch to have occurred in Real-Time.  If we
consider a video stream as a test case, then we will typically want less
than at least 10 mSec for a Round-Trip-Time.

I was considered the more common case, as a starting point.

> You seem to be make some assumptions on the tight-coupledness 
> of L2 and L3.
> this is not 
> necessarly bad, but there is merit in leaving them loosely 
> coupled or no
> coupling at all.
> 

Can you please describe some merits?

- Kulwinder.


From owner-seamoby@diameter.org  Sat Jan 13 06:22:16 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16374
	for <seamoby-archive@odin.ietf.org>; Sat, 13 Jan 2001 06:22:16 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0DAFuA26192
	for seamoby-list; Sat, 13 Jan 2001 02:15:56 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0DAFrW26187
	for <seamoby@diameter.org>; Sat, 13 Jan 2001 02:15:54 -0800
Received: from localhost (root@porsta.cs.Helsinki.FI [128.214.48.124]) by porsta.cs.Helsinki.FI (8.8.8/8.8.8) with ESMTP id LAA06594; Sat, 13 Jan 2001 11:23:55 +0200
Date: Sat, 13 Jan 2001 11:23:54 +0200 (EET)
From: Jukka Manner <jmanner@cs.helsinki.fi>
To: cnyap <cny@ieee.org>
cc: <seamoby@diameter.org>
Subject: [seamoby] Answer to a question on the mobility terminology draft
In-Reply-To: <005701c07cee$84fcbaf0$923ba78f@Mobile1>
Message-ID: <Pine.LNX.4.30.0101131118030.20745-100000@melkinkari.cs.Helsinki.FI>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Fri, 12 Jan 2001, cnyap wrote:

> Hi
>
> Could you please give more explaination on Intra-AR Handover.
> It is not very clear in the draft.
>

	As an example, let's consider an AR which has network interfaces to APs
under its control. When a MH switches APs under the same AR, it does an intra-AR
handover. The AN internal routing does thus not change, only the AR needs to
update its internal routing to reflect the new network interface, where the MH
now is located. It also may need to move packets from queues on the old network
interface to new queues. If the AP and AR are one single component and there is
only one AP, then an intra-AR handover never happens.


	Jukka



From owner-seamoby@diameter.org  Sat Jan 13 10:51:49 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18356
	for <seamoby-archive@odin.ietf.org>; Sat, 13 Jan 2001 10:51:49 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0DFXXI26509
	for seamoby-list; Sat, 13 Jan 2001 07:33:33 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mailhub1.shef.ac.uk (mailhub1.shef.ac.uk [143.167.1.9])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0DFXPW26504
	for <seamoby@diameter.org>; Sat, 13 Jan 2001 07:33:25 -0800
Received: from ridingwood.shef.ac.uk ([143.167.59.249])
	by mailhub1.shef.ac.uk with esmtp (Exim 3.16 #1)
	id 14HRru-0002U5-00; Sat, 13 Jan 2001 14:41:22 +0000
Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48);
    13 Jan 01 14:41:22 +0000
Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 13 Jan 01 14:41:16 +0000
Received: from Mobile1 (143.167.59.146) by ridingwood.shef.ac.uk (Mercury 1.48);
    13 Jan 01 14:41:12 +0000
Message-ID: <004b01c07d6e$6bd54f30$923ba78f@Mobile1>
Reply-To: "cnyap" <cny@ieee.org>
From: "cnyap" <cny@dcs.shef.ac.uk>
To: "Jukka Manner" <jmanner@cs.helsinki.fi>
Cc: <seamoby@diameter.org>
References: <Pine.LNX.4.30.0101131118030.20745-100000@melkinkari.cs.Helsinki.FI>
Subject: [seamoby] Re: Answer to a question on the mobility terminology draft
Date: Sat, 13 Jan 2001 14:37:57 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi

Thanks, the explaination is much clearer.

Cheers
Chern Nam Yap
MIEEE, MSc(Res), BSc(Hons)
Research Associate
Center for Mobile Communication Research
Department of Electronic and Electrical Engineering
University of Sheffield
F132 Mappin Building
Mappin Street
Sheffield S1 3JD
United Kingdom
Tel:+44 (0) 114-222-5182
Mobile:+ 44(0) 7712804892
Web: www.mobile1.net
E-mail: cny@ieee.org





----- Original Message -----
From: "Jukka Manner" <jmanner@cs.Helsinki.FI>
To: "cnyap" <cny@ieee.org>
Cc: <seamoby@diameter.org>
Sent: Saturday, January 13, 2001 9:23 AM
Subject: Answer to a question on the mobility terminology draft


> On Fri, 12 Jan 2001, cnyap wrote:
>
> > Hi
> >
> > Could you please give more explaination on Intra-AR Handover.
> > It is not very clear in the draft.
> >
>
> As an example, let's consider an AR which has network interfaces to APs
> under its control. When a MH switches APs under the same AR, it does an
intra-AR
> handover. The AN internal routing does thus not change, only the AR needs
to
> update its internal routing to reflect the new network interface, where
the MH
> now is located. It also may need to move packets from queues on the old
network
> interface to new queues. If the AP and AR are one single component and
there is
> only one AP, then an intra-AR handover never happens.
>
>
> Jukka
>



From owner-seamoby@diameter.org  Mon Jan 15 12:35:32 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11502
	for <seamoby-archive@odin.ietf.org>; Mon, 15 Jan 2001 12:35:26 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0FFxOW01656
	for seamoby-list; Mon, 15 Jan 2001 07:59:24 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0FFwQW01651
	for <seamoby@diameter.org>; Mon, 15 Jan 2001 07:58:26 -0800
Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com;
          Mon, 15 Jan 2001 10:05:20 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNB45PC>; Mon, 15 Jan 2001 10:05:22 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8AFD@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'seamoby'" <seamoby@diameter.org>,
        seamoby_context@standards.nortelnetworks.com
Cc: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>
Subject: [seamoby] today's conference calls
Date: Mon, 15 Jan 2001 10:05:18 -0500
Sensitivity: Company-Confidential
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: text/plain; charset="iso-8859-1"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

My apologies for cross posting this, however, I received a note saying that
the information
did not make it out on Friday. It does appear in the
Seamoby_Context@standards.nortelnetworks.com
email list. However, just to make sure:

The second SeaMoby Context Transfer design team conference
call will take place on Monday, January 15, 2001 at 11am EST.

The phone number for the context transfer conference call is:

972-684-9903

This a number for a North American Bridge.

When your call is answered, you will be asked for a passcode, which is:
651256#
(you must press the "#" sign at the end of the number).

The tentative agenda is:

	11:00 - 11:15		Introductions
	11:15 - 11:20		Agenda Bashing
	11:20 - 		Review and Discussion of Action Items:

		11:20 - 11:40		Reference Architecture
Jukka Manner
		11:40 - 12:00		Definition of Context		Alan
O'Neill
		12:00 - 12:20		Description of Alternatives
Pat Calhoun
		12:20 - 12:40		Definition of Context Transfer
Hamid Syed

	12:40 - 13:00		Discussion of co-dependencies with other
IETF WG activities
	13:00 - 13:30		Discussion on problem statement
	13:30 - 1345		next steps

See you there,
Gary



From owner-seamoby@diameter.org  Mon Jan 15 15:46:35 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15454
	for <seamoby-archive@odin.ietf.org>; Mon, 15 Jan 2001 15:46:34 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0FKcJI02253
	for seamoby-list; Mon, 15 Jan 2001 12:38:19 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0FKcHW02248
	for <seamoby@cdma-2000.org>; Mon, 15 Jan 2001 12:38:17 -0800
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26994
	for <seamoby@cdma-2000.org>; Mon, 15 Jan 2001 11:46:31 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA11908
	for <seamoby@cdma-2000.org>; Mon, 15 Jan 2001 11:46:30 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id LAA13935
	for <seamoby@cdma-2000.org>; Mon, 15 Jan 2001 11:46:28 -0800 (PST)
Date: Mon, 15 Jan 2001 11:42:47 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: [seamoby] IPR and SeaMoby
To: seamoby@cdma-2000.org
In-Reply-To: "Your message with ID" <882569D5.0069E14C.00@hqoutbound.ops.3com.com>
Message-ID: <Roam.SIMC.2.0.6.979587767.2178.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

All,

I was just informed that there are some patents certain areas that SeaMoby has
interest in.  I would ask that everyone PLEASE read (all of) section 10
entitled "10.  INTELLECTUAL PROPERTY RIGHTS" of RFC 2026. There are certain
obligations in the IETF regarding patented work.

Thanks,

PatC



From owner-seamoby@diameter.org  Mon Jan 15 15:57:15 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15611
	for <seamoby-archive@odin.ietf.org>; Mon, 15 Jan 2001 15:57:14 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0FKTqQ02230
	for seamoby-list; Mon, 15 Jan 2001 12:29:52 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0FKTnW02225
	for <seamoby@diameter.org>; Mon, 15 Jan 2001 12:29:50 -0800
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f0FI7A116653;
	Mon, 15 Jan 2001 10:07:14 -0800 (PST)
Received: from hqoutbound.ops.3com.com (pc-48-104.corp.3com.com [139.87.48.104] (may be forged))
	by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f0FI8Dl15790;
	Mon, 15 Jan 2001 10:08:13 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 882569D5.0063C5C8 ; Mon, 15 Jan 2001 10:09:46 -0800
X-Lotus-FromDomain: 3COM
From: Phil_Neumiller@3Com.com
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
cc: seamoby@diameter.org
Message-ID: <882569D5.0063C2CF.00@hqoutbound.ops.3com.com>
Date: Mon, 15 Jan 2001 12:14:58 -0600
Subject: [seamoby] Re: Minutes for context conference call
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-seamoby@diameter.org
Precedence: bulk








>I appologize if I've mangled any names.
>
>PatC

If you continue to mangle names we'll need to call you PatC++  :-)





From owner-seamoby@diameter.org  Mon Jan 15 23:58:09 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA22502
	for <seamoby-archive@odin.ietf.org>; Mon, 15 Jan 2001 23:58:08 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0G2nXD02740
	for seamoby-list; Mon, 15 Jan 2001 18:49:33 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f0G2nVW02735
	for <seamoby@cdma-2000.org>; Mon, 15 Jan 2001 18:49:31 -0800
Received: (cpmta 23797 invoked from network); 15 Jan 2001 17:57:45 -0800
Received: from dsl-64-193-0-129.telocity.com (HELO telocity.com) (64.193.0.129)
  by smtp.telocity.com (209.228.33.206) with SMTP; 15 Jan 2001 17:57:45 -0800
X-Sent: 16 Jan 2001 01:57:45 GMT
Message-ID: <3A63AB09.47437AB1@telocity.com>
Date: Mon, 15 Jan 2001 19:59:37 -0600
From: Phil Neumiller <neumiller@telocity.com>
Organization: 3Com
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
CC: seamoby@cdma-2000.org
Subject: Re: [seamoby] IPR and SeaMoby
References: <Roam.SIMC.2.0.6.979587767.2178.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat Calhoun wrote:
> 
> All,
> 
> I was just informed that there are some patents certain areas that SeaMoby has
> interest in.  I would ask that everyone PLEASE read (all of) section 10
> entitled "10.  INTELLECTUAL PROPERTY RIGHTS" of RFC 2026. There are certain
> obligations in the IETF regarding patented work.
> 
> Thanks,
> 
> PatC


I wonder what we should do in the event that we are purposefully
working around patents?  Should we site said patents and clue in
the owner or work silently with the hope that the new work will
indeed allow us to work around known patents?  What if these 
patents are owned by a variety of companies that the contibutor 
is not employed with? 2026 does not seem to address these.

If you know of a patent, that could apply to your work, even if
held by a company that is not your employer are you obligated to
bring that to the IETF's attention even though it may expose you
to increased competition from a competitor?


From owner-seamoby@diameter.org  Tue Jan 16 00:19:50 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA22647
	for <seamoby-archive@odin.ietf.org>; Tue, 16 Jan 2001 00:19:49 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0G30dj02757
	for seamoby-list; Mon, 15 Jan 2001 19:00:39 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0G30aW02752
	for <seamoby@cdma-2000.org>; Mon, 15 Jan 2001 19:00:36 -0800
Received: (from sob@localhost)
	by newdev.harvard.edu (8.9.3/8.9.3) id VAA03221;
	Mon, 15 Jan 2001 21:08:43 -0500 (EST)
Date: Mon, 15 Jan 2001 21:08:43 -0500 (EST)
From: Scott Bradner <sob@harvard.edu>
Message-Id: <200101160208.VAA03221@newdev.harvard.edu>
To: neumiller@telocity.com, Pat.Calhoun@eng.sun.com
Subject: Re: [seamoby] IPR and SeaMoby
Cc: seamoby@cdma-2000.org
Sender: owner-seamoby@diameter.org
Precedence: bulk

> If you know of a patent, that could apply to your work, even if
> held by a company that is not your employer are you obligated to
> bring that to the IETF's attention even though it may expose you
> to increased competition from a competitor?

you are required to bring any IPR that you know of in your own
company to the attention of the working group or you have to
not take part in any discussion that might impact the technology
that the IPR relates to

you are not required to tell the WG about IPR from outside
your company unless you would benefit from the IPR in some way

bottom line - you have to disclose if you or your company will
benefit from the IPR

Scott


From owner-seamoby@diameter.org  Tue Jan 16 05:22:29 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07674
	for <seamoby-archive@odin.ietf.org>; Tue, 16 Jan 2001 05:22:28 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0GA28O03060
	for seamoby-list; Tue, 16 Jan 2001 02:02:08 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from melanieb.vtt.fi (melanieb.vtt.fi [130.188.1.12])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0GA21W03055
	for <seamoby@diameter.org>; Tue, 16 Jan 2001 02:02:01 -0800
Received: from elemail.ele.vtt.fi (localhost [127.0.0.1])
	by melanieb.vtt.fi (8.9.3/8.9.3) with ESMTP id LAA19651
	for <seamoby@diameter.org>; Tue, 16 Jan 2001 11:09:52 +0200 (EET)
Received: from tko103.vttele (tko103 [130.188.92.203])
	by elemail.ele.vtt.fi (8.9.1a/8.9.1) with ESMTP id LAA01395
	for <seamoby@diameter.org>; Tue, 16 Jan 2001 11:09:47 +0200 (EET)
Date: Tue, 16 Jan 2001 11:05:52 +0200
From: Zach Shelby <zach.shelby@vtt.fi>
X-Mailer: The Bat! (v1.46) UNREG / CD5BF9353B3B7091
Reply-To: Zach Shelby <zach.shelby@vtt.fi>
Organization: VTT Electronics, Finland
X-Priority: 3 (Normal)
Message-ID: <149607601675.20010116110552@vtt.fi>
To: seamoby@diameter.org
Subject: [seamoby] RE: Terminology draft
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Sender: owner-seamoby@diameter.org
Precedence: bulk
X-MIME-Autoconverted: from 8bit to quoted-printable by charizard.diameter.org id f0GA28O03060
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA07674

After reviewing draft-brain-seamoby-terms-00.txt I find it to be an
excellent compilation of very reasonable terminology and encourage all
to get comments back to the authors on this.  Is it possible for this
draft (or one similar) to go to RFC for seamoby?

Comment. Add a section on synonyms, including all the alternative
terms floating around our different backgrounds, with the appropriate
equivalent term of the draft. BS = AP is a good start.

Another. Section 2.2.1 (scope of handover) Add a "layer 2 handover"
example situation to the appendix. I'm still not clear how this is a
handover. If the same interface has multiple channels which the user
can use, isn't that micro-diversity? Or should it could be called
"layer 2 reconfiguration", or not be called at all.

Regards,
Zach

----------------------------------------------------------------------
   Zach Shelby - Researcher         Zach.Shelby@vtt.fi
   VTT Elektronics                  Phone   +358 8 551 2164 (Office)
   Kaitoväylä 1, PL 1100            Fax     +358 8 551 2320
   90571 Oulu, Finland              Mobile  +358 40 7796297 
----------------------------------------------------------------------
                    http://paula.oulu.fi/~zdshelby
       Home:   Yliopistokatu 14-707  90570 Oulu, Finland




From owner-seamoby@diameter.org  Tue Jan 16 07:34:37 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09018
	for <seamoby-archive@odin.ietf.org>; Tue, 16 Jan 2001 07:34:36 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0GBhGb03119
	for seamoby-list; Tue, 16 Jan 2001 03:43:16 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0GBh3W03114
	for <seamoby@diameter.org>; Tue, 16 Jan 2001 03:43:04 -0800
Received: from esvir08nok.nokia.com (esvir08nokt.ntc.nokia.com [172.21.143.40])
	by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0GAq7212521
	for <seamoby@diameter.org>; Tue, 16 Jan 2001 12:52:07 +0200 (EET)
Received: from esebh01nok.ntc.nokia.com (unverified) by esvir08nok.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tac158f281425124115650@esvir08nok.nokia.com>;
 Tue, 16 Jan 2001 12:51:06 +0200
Received: by esebh01nok with Internet Mail Service (5.5.2652.78)
	id <C0KD1GCZ>; Tue, 16 Jan 2001 12:50:41 +0200
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DF5FC@eseis04nok>
From: john.loughney@nokia.com
To: mat@cisco.com, seamoby@diameter.org
Subject: RE: [seamoby] micro, schmicro
Date: Tue, 16 Jan 2001 12:50:38 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Micheal,

> I'm probably the only one, but I find this desire
> to find a home for the phrases "micro mobility"
> and "macro mobility" to be almost, well...
> procrustean. I've yet to see why the use of these
> two terms yield any light, nor do they seem to
> yield a useful taxonomy. Instead, they seem to be
> like dummies that we are hide-bound to find some
> appropriate clothes for them to don.

Agreed.  I think we may need to re-write what we
are doing here, as the micro/macro debate constantly sets
one side of the debate into a tizzy ...

> It seems to me that instead of getting wrapped
> around the axle about how many angels dance on the
> head of micro and macro, it would be better to
> agree on what all of the variables are, how they
> interact, and what these of scenarios we have
> to consider are.

I'd even like to have some agreement if it is needed
or not ... I may just be playing the devil's advocate
part here, but I guess I need a summary here.

Is the idea here something like I expressed at the 
SeaMoby meeting:

"Do what you can locally before going globally" ?

br,
John


From owner-seamoby@diameter.org  Tue Jan 16 11:15:35 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15084
	for <seamoby-archive@odin.ietf.org>; Tue, 16 Jan 2001 11:15:35 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0GFL6W03656
	for seamoby-list; Tue, 16 Jan 2001 07:21:06 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from c007.snv.cp.net (c007-h013.c007.snv.cp.net [209.228.33.220])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f0GFL4W03651
	for <seamoby@diameter.org>; Tue, 16 Jan 2001 07:21:04 -0800
Received: (cpmta 28171 invoked from network); 16 Jan 2001 06:29:15 -0800
Received: from dsl-64-193-0-129.telocity.com (HELO telocity.com) (64.193.0.129)
  by smtp.telocity.com (209.228.33.220) with SMTP; 16 Jan 2001 06:29:15 -0800
X-Sent: 16 Jan 2001 14:29:15 GMT
Message-ID: <3A645B2F.C487ADC7@telocity.com>
Date: Tue, 16 Jan 2001 08:31:11 -0600
From: Phil Neumiller <neumiller@telocity.com>
Organization: 3Com
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: john.loughney@nokia.com
CC: mat@cisco.com, seamoby@diameter.org
Subject: Re: [seamoby] micro, schmicro
References: <01D91AFB08B6D211BFD00008C7EABAE1031DF5FC@eseis04nok>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


> 
> "Do what you can locally before going globally" ?
> 
> br,
> John

Right on John!

Think globally, act locally...  Charity begins at home....
The end-to-end argument...  All apply John.  I for one
would love to see us dump the macro/micro distinction
since I think the original basis for this distinction
i.e. (no COA change) is a flawed distinction.  The real
IMPORTANT distinction is that of edge devices/routers
versus core routers and how they relate to mobility, NOT
what subnet you are on!

=pdn


From owner-seamoby@diameter.org  Tue Jan 16 13:01:47 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17741
	for <seamoby-archive@odin.ietf.org>; Tue, 16 Jan 2001 13:01:46 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0GGl8I03768
	for seamoby-list; Tue, 16 Jan 2001 08:47:08 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0GGl6W03763
	for <seamoby@diameter.org>; Tue, 16 Jan 2001 08:47:06 -0800
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12049;
	Tue, 16 Jan 2001 07:55:19 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA23451;
	Tue, 16 Jan 2001 07:55:08 -0800 (PST)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA05198;
	Tue, 16 Jan 2001 07:55:04 -0800 (PST)
Message-Id: <200101161555.HAA05198@nasnfs.eng.sun.com>
Date: Tue, 16 Jan 2001 07:55:35 -0800 (PST)
From: James Kempf <James.Kempf@eng.sun.com>
Reply-To: James Kempf <James.Kempf@eng.sun.com>
Subject: Re: [seamoby] micro, schmicro
To: john.loughney@nokia.com, neumiller@telocity.com
Cc: mat@cisco.com, seamoby@diameter.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 4WOpp7nfwftJMIIq1/20Qg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk


>> 
>> "Do what you can locally before going globally" ?
>> 
>> br,
>> John
>
>Right on John!
>
>Think globally, act locally...  Charity begins at home....
>The end-to-end argument...  All apply John.  I for one
>would love to see us dump the macro/micro distinction
>since I think the original basis for this distinction
>i.e. (no COA change) is a flawed distinction.  The real
>IMPORTANT distinction is that of edge devices/routers
>versus core routers and how they relate to mobility, NOT
>what subnet you are on!
>

Um, actually what subnet you are on has an intimate relationship to
what edge router you are using or what core router. The whole point
of having a router is to bridge two subnets, in subnet based routing.

		jak



From owner-seamoby@diameter.org  Tue Jan 16 15:00:54 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20573
	for <seamoby-archive@odin.ietf.org>; Tue, 16 Jan 2001 15:00:53 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0GIPc304011
	for seamoby-list; Tue, 16 Jan 2001 10:25:38 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0GIOKW04006
	for <seamoby@diameter.org>; Tue, 16 Jan 2001 10:24:20 -0800
Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19)
	id <CKB8VSTK>; Tue, 16 Jan 2001 12:31:32 -0500
Message-ID: <A1170612471BD21185B90008C7FA0A0D01ABAAE2@idcpa4.pa.interdigital.com>
From: "Chitrapu, Prabhakar R" <Prabhakar.Chitrapu@interdigital.com>
To: "'Phil Neumiller'" <neumiller@telocity.com>, john.loughney@nokia.com
Cc: mat@cisco.com, seamoby@diameter.org
Subject: RE: [seamoby] micro, schmicro
Date: Tue, 16 Jan 2001 12:31:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-seamoby@diameter.org
Precedence: bulk

I agree that 'micro/macro' are relative terms and can be mis-understood. 

Terms such as 'Edge vs. Core devices/routers' are good.  

However, I have a question: Do issues that SeaMoby wants to address HAVE to
belong to an EDGE domain/subnet/access-network ? Can they not be applied to
ANY subnet or a LOCAL-domain, even though it may not be at the edge ? If
that is indeed the case, then terms  such as 'intra-domain vs. inter-domain'
devices/routers might be useful. 

Prabhakar Chitrapu.

----------------------------------------------------------------------------
----------------
Prabhakar Chitrapu, Ph.D.					Tel:
610-878-5730	
Manager, Algorithm Development				Fax: 610-878-7841

InterDigital Communications Corp.				Email:
Prabhakar.Chitrapu@InterDigital.com
781 Third Avenue, King of Prussia, PA 19406-1409.
http://www.interdigital.com



> -----Original Message-----
> From:	Phil Neumiller [SMTP:neumiller@telocity.com]
> Sent:	Tuesday, January 16, 2001 9:31 AM
> To:	john.loughney@nokia.com
> Cc:	mat@cisco.com; seamoby@diameter.org
> Subject:	Re: [seamoby] micro, schmicro
> 
> 
> > 
> > "Do what you can locally before going globally" ?
> > 
> > br,
> > John
> 
> Right on John!
> 
> Think globally, act locally...  Charity begins at home....
> The end-to-end argument...  All apply John.  I for one
> would love to see us dump the macro/micro distinction
> since I think the original basis for this distinction
> i.e. (no COA change) is a flawed distinction.  The real
> IMPORTANT distinction is that of edge devices/routers
> versus core routers and how they relate to mobility, NOT
> what subnet you are on!
> 
> =pdn


From owner-seamoby@diameter.org  Tue Jan 16 15:34:28 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21170
	for <seamoby-archive@odin.ietf.org>; Tue, 16 Jan 2001 15:34:28 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0GIWu504036
	for seamoby-list; Tue, 16 Jan 2001 10:32:56 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0GIWsW04031
	for <Seamoby@diameter.org>; Tue, 16 Jan 2001 10:32:54 -0800
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f0GHdv114915
	for <Seamoby@diameter.org>; Tue, 16 Jan 2001 09:40:01 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104])
	by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f0GHew009420
	for <Seamoby@diameter.org>; Tue, 16 Jan 2001 09:41:02 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 882569D6.00614B17 ; Tue, 16 Jan 2001 09:42:42 -0800
X-Lotus-FromDomain: 3COM
From: Phil_Neumiller@3Com.com
To: Seamoby@diameter.org
Message-ID: <882569D6.0061466D.00@hqoutbound.ops.3com.com>
Date: Tue, 16 Jan 2001 11:48:12 -0600
Subject: Re: [seamoby] micro, schmicro
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-seamoby@diameter.org
Precedence: bulk






Um, actually what subnet you are on has an intimate relationship to
what edge router you are using or what core router. The whole point
of having a router is to bridge two subnets, in subnet based routing.

James,

I understand this.  However, it may be the case that useable routes exist
between
an edge router pair that are unknown to the mobility agents being used.  If this
is
the case the path between the mobile and the new ER is shorter when the mobility
agents are bypassed.  This will not always be the case, but the worse case is
that
you have to route back through the mobility agents right?  Ideally wireless
networks
that handover to each other frequently will become mesh networked at the edge of
the big I overtime.  That is we follow the simple principle of allowing the
physical
network to adapt overtime to the logical traffic patterns.

-Phil







From owner-seamoby@diameter.org  Tue Jan 16 16:54:14 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22261
	for <seamoby-archive@odin.ietf.org>; Tue, 16 Jan 2001 16:54:13 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0GLGOt04271
	for seamoby-list; Tue, 16 Jan 2001 13:16:24 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0GLGMW04266
	for <seamoby@diameter.org>; Tue, 16 Jan 2001 13:16:22 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 16 Jan 2001 15:19:10 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <DCDS9NCC>; Tue, 16 Jan 2001 15:19:14 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8B13@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>,
        Colin Elliott <celliott@zucotto.com>, seamoby-paging@egroups.com,
        James Kempf <James.Kempf@eng.sun.com>, James.Kempf@eng.sun.com,
        ramjee@dnrc.bell-labs.com
Cc: seamoby@diameter.org, Phil_Neumiller@3Com.com, seamoby-paging@egroups.com
Subject: RE: [seamoby-paging] RE: [seamoby] Some thoughts on paging proble m
Date: Tue, 16 Jan 2001 15:19:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C07FF9.92CDA9B0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C07FF9.92CDA9B0
Content-Type: text/plain;
	charset="iso-8859-1"

Kulwinder:

  Sorry for getting to this so late.

I agree on your observations concerning bounding the domain. I believe
the issue is not so much bounding the routing domain (although this is a
good thing to do, it is not the focus of SeaMoby), rather we must bound
the domain for handoffs. This is as applicable to context transfer as it
is for micromobility. The extreme case for context transfer is to replicate
context in every AP in the access network, which does not seem to be
a practical approach.

The statement you make concerning RSSI and combining is, I believe, 
out of scope. For two reasons: one, as already has been discussed, RSSI
may not be available, or may not be the best handover indicator for 
all wireless links; second, RSSI and RSSI comparison is an L2 function,
as it is specific to the L1 technology. To elaborate briefly on the latter,
the metric used to estimate RSSI, and it's treatment (e.g. quantization,
thresholds, value mapping) will depend upon the modulation technique,
the propagation environment, etc.

Again, we must abstract out the mechanisms for selecting new APs and
triggering the handoff.

Gary

> -----Original Message-----
> From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
> Sent: Saturday, January 13, 2001 12:13 AM
> To: Colin Elliott; seamoby-paging@egroups.com; James Kempf;
> James.Kempf@eng.sun.com; ramjee@dnrc.bell-labs.com
> Cc: seamoby@diameter.org; Phil_Neumiller@3Com.com;
> seamoby-paging@egroups.com
> Subject: RE: [seamoby-paging] RE: [seamoby] Some thoughts on paging
> proble m
> 
> 
>  
> > Two observations from what you are stating:
> > 
> > 1. RSSI happens at L1 and L2 and FA and mobile IP stuff 
> happens at L3
> > 2. there are scenarios where AP (terminating the wireless L2) 
> > and FA could 
> > be over a routed cloud.
> 
> Let me describe my view of the wireless IP access network.
>  
> AP (Access Point): stationary wireless device with wired link to AR.
> AR (Access Router): stationary wired/wireless router 
> connected to at least
> one AP. 
> MN (Mobile Node): a mobile device with a wireless link.  The 
> mobile device
> may act as a mobile router if the *particular network* permits.
> 
> Re-phrasing:  The APs compare Radio Signal Strength results 
> through the ARs
> with a real-time RTT (Round-Trip-Time).
> 
> Real-time switching cannot happen over an unbounded routed 
> cloud.  We must
> consider Round-Trip-Time between ARs.  Round-Trip-Time must 
> be less than the
> Real-time response time for the switch to have occurred in 
> Real-Time.  If we
> consider a video stream as a test case, then we will 
> typically want less
> than at least 10 mSec for a Round-Trip-Time.
> 
> I was considered the more common case, as a starting point.
> 
> > You seem to be make some assumptions on the tight-coupledness 
> > of L2 and L3.
> > this is not 
> > necessarly bad, but there is merit in leaving them loosely 
> > coupled or no
> > coupling at all.
> > 
> 
> Can you please describe some merits?
> 
> - Kulwinder.
> 

------_=_NextPart_001_01C07FF9.92CDA9B0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby-paging] RE: [seamoby] Some thoughts on paging problem</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Kulwinder:</FONT>
</P>

<P><FONT SIZE=2>&nbsp; Sorry for getting to this so late.</FONT>
</P>

<P><FONT SIZE=2>I agree on your observations concerning bounding the domain. I believe</FONT>
<BR><FONT SIZE=2>the issue is not so much bounding the routing domain (although this is a</FONT>
<BR><FONT SIZE=2>good thing to do, it is not the focus of SeaMoby), rather we must bound</FONT>
<BR><FONT SIZE=2>the domain for handoffs. This is as applicable to context transfer as it</FONT>
<BR><FONT SIZE=2>is for micromobility. The extreme case for context transfer is to replicate</FONT>
<BR><FONT SIZE=2>context in every AP in the access network, which does not seem to be</FONT>
<BR><FONT SIZE=2>a practical approach.</FONT>
</P>

<P><FONT SIZE=2>The statement you make concerning RSSI and combining is, I believe, </FONT>
<BR><FONT SIZE=2>out of scope. For two reasons: one, as already has been discussed, RSSI</FONT>
<BR><FONT SIZE=2>may not be available, or may not be the best handover indicator for </FONT>
<BR><FONT SIZE=2>all wireless links; second, RSSI and RSSI comparison is an L2 function,</FONT>
<BR><FONT SIZE=2>as it is specific to the L1 technology. To elaborate briefly on the latter,</FONT>
<BR><FONT SIZE=2>the metric used to estimate RSSI, and it's treatment (e.g. quantization,</FONT>
<BR><FONT SIZE=2>thresholds, value mapping) will depend upon the modulation technique,</FONT>
<BR><FONT SIZE=2>the propagation environment, etc.</FONT>
</P>

<P><FONT SIZE=2>Again, we must abstract out the mechanisms for selecting new APs and</FONT>
<BR><FONT SIZE=2>triggering the handoff.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Kulwinder Atwal [<A HREF="mailto:kulwinder.atwal@zucotto.com">mailto:kulwinder.atwal@zucotto.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Saturday, January 13, 2001 12:13 AM</FONT>
<BR><FONT SIZE=2>&gt; To: Colin Elliott; seamoby-paging@egroups.com; James Kempf;</FONT>
<BR><FONT SIZE=2>&gt; James.Kempf@eng.sun.com; ramjee@dnrc.bell-labs.com</FONT>
<BR><FONT SIZE=2>&gt; Cc: seamoby@diameter.org; Phil_Neumiller@3Com.com;</FONT>
<BR><FONT SIZE=2>&gt; seamoby-paging@egroups.com</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [seamoby-paging] RE: [seamoby] Some thoughts on paging</FONT>
<BR><FONT SIZE=2>&gt; proble m</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Two observations from what you are stating:</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; 1. RSSI happens at L1 and L2 and FA and mobile IP stuff </FONT>
<BR><FONT SIZE=2>&gt; happens at L3</FONT>
<BR><FONT SIZE=2>&gt; &gt; 2. there are scenarios where AP (terminating the wireless L2) </FONT>
<BR><FONT SIZE=2>&gt; &gt; and FA could </FONT>
<BR><FONT SIZE=2>&gt; &gt; be over a routed cloud.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Let me describe my view of the wireless IP access network.</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; AP (Access Point): stationary wireless device with wired link to AR.</FONT>
<BR><FONT SIZE=2>&gt; AR (Access Router): stationary wired/wireless router </FONT>
<BR><FONT SIZE=2>&gt; connected to at least</FONT>
<BR><FONT SIZE=2>&gt; one AP. </FONT>
<BR><FONT SIZE=2>&gt; MN (Mobile Node): a mobile device with a wireless link.&nbsp; The </FONT>
<BR><FONT SIZE=2>&gt; mobile device</FONT>
<BR><FONT SIZE=2>&gt; may act as a mobile router if the *particular network* permits.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Re-phrasing:&nbsp; The APs compare Radio Signal Strength results </FONT>
<BR><FONT SIZE=2>&gt; through the ARs</FONT>
<BR><FONT SIZE=2>&gt; with a real-time RTT (Round-Trip-Time).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Real-time switching cannot happen over an unbounded routed </FONT>
<BR><FONT SIZE=2>&gt; cloud.&nbsp; We must</FONT>
<BR><FONT SIZE=2>&gt; consider Round-Trip-Time between ARs.&nbsp; Round-Trip-Time must </FONT>
<BR><FONT SIZE=2>&gt; be less than the</FONT>
<BR><FONT SIZE=2>&gt; Real-time response time for the switch to have occurred in </FONT>
<BR><FONT SIZE=2>&gt; Real-Time.&nbsp; If we</FONT>
<BR><FONT SIZE=2>&gt; consider a video stream as a test case, then we will </FONT>
<BR><FONT SIZE=2>&gt; typically want less</FONT>
<BR><FONT SIZE=2>&gt; than at least 10 mSec for a Round-Trip-Time.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I was considered the more common case, as a starting point.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; You seem to be make some assumptions on the tight-coupledness </FONT>
<BR><FONT SIZE=2>&gt; &gt; of L2 and L3.</FONT>
<BR><FONT SIZE=2>&gt; &gt; this is not </FONT>
<BR><FONT SIZE=2>&gt; &gt; necessarly bad, but there is merit in leaving them loosely </FONT>
<BR><FONT SIZE=2>&gt; &gt; coupled or no</FONT>
<BR><FONT SIZE=2>&gt; &gt; coupling at all.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Can you please describe some merits?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; - Kulwinder.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C07FF9.92CDA9B0--


From owner-seamoby@diameter.org  Tue Jan 16 17:06:41 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22472
	for <seamoby-archive@odin.ietf.org>; Tue, 16 Jan 2001 17:06:40 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0GKu5204207
	for seamoby-list; Tue, 16 Jan 2001 12:56:05 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0GKu3W04202
	for <seamoby@diameter.org>; Tue, 16 Jan 2001 12:56:03 -0800
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f0GK34125674;
	Tue, 16 Jan 2001 12:03:04 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104])
	by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f0GK45008980;
	Tue, 16 Jan 2001 12:04:05 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 882569D6.006E65AC ; Tue, 16 Jan 2001 12:05:49 -0800
X-Lotus-FromDomain: 3COM
From: Phil_Neumiller@3Com.com
To: Hamid Syed <hmsyed@nortelnetworks.com>
cc: seamoby_context@standards.nortelnetworks.com, seamoby@diameter.org,
        seamoby-mm@cdma-2000.org
Message-ID: <882569D6.006E5CD2.00@hqoutbound.ops.3com.com>
Date: Tue, 16 Jan 2001 14:07:02 -0600
Subject: [seamoby] A CNP perspective on context transfer.
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-seamoby@diameter.org
Precedence: bulk




The contract bidding analogy is very applicable to context transfer.  Consider
the following.

A CONTRACT between an AP/AR pair may be established by a process of mutual
selection based on a two way transfer of context.  Handover candidates
(contractors)
evaluate hand over requests made by handover sources.  The candidates then
submit bids on those parts of contracts for which they are suited.  The bids
contain
the parts of the contract that can be handled by both parties.  The handover
source
can then take the best bid from its perspective and assign the handover in a
locally
optimal manner.  This scales to the globe.

I believe the transport mechanism we put in place for context transfer should
support this pattern.  The semantics of payload are interpreted by the local
mobility manager (micro-mobility) not the transport mechanism itself.

Thanks,

Phil




From owner-seamoby@diameter.org  Tue Jan 16 18:21:29 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23235
	for <seamoby-archive@odin.ietf.org>; Tue, 16 Jan 2001 18:21:28 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0GMLKp04398
	for seamoby-list; Tue, 16 Jan 2001 14:21:20 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0GMLHW04393
	for <seamoby@diameter.org>; Tue, 16 Jan 2001 14:21:17 -0800
Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com;
          Tue, 16 Jan 2001 16:25:30 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <DCDS9PTQ>; Tue, 16 Jan 2001 16:25:33 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8B1A@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Zach Shelby'" <zach.shelby@vtt.fi>, seamoby@diameter.org
Subject: RE: [seamoby] RE: Terminology draft
Date: Tue, 16 Jan 2001 16:25:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C08002.D86B3B50"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C08002.D86B3B50
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

It would be a mistake, to attempt to map the reference architecture =
onto
existing architectures by defining synonyms. There are simply too many
issues
that would be opened up. For example, a BS is a box, while an AP does =
not
necessarily
have to be (the AR and the AP could be implemented in one box).

One of the reasons the original discussions around the architecture =
avoided
going beyond the edge of the routing fabric was to avoid the black =
abyss of
subnetwork architectures.

It would be my preference, to define a logical reference architecture,
rather=20
then a physical one. However, I suspect that this would not happen.

Gary

> -----Original Message-----
> From: Zach Shelby [mailto:zach.shelby@vtt.fi]
> Sent: Tuesday, January 16, 2001 4:06 AM
> To: seamoby@diameter.org
> Subject: [seamoby] RE: Terminology draft
>=20
>=20
> After reviewing draft-brain-seamoby-terms-00.txt I find it to be an
> excellent compilation of very reasonable terminology and encourage =
all
> to get comments back to the authors on this.  Is it possible for this
> draft (or one similar) to go to RFC for seamoby?
>=20
> Comment. Add a section on synonyms, including all the alternative
> terms floating around our different backgrounds, with the appropriate
> equivalent term of the draft. BS =3D AP is a good start.
>=20
> Another. Section 2.2.1 (scope of handover) Add a "layer 2 handover"
> example situation to the appendix. I'm still not clear how this is a
> handover. If the same interface has multiple channels which the user
> can use, isn't that micro-diversity? Or should it could be called
> "layer 2 reconfiguration", or not be called at all.
>=20
> Regards,
> Zach
>=20
> =
----------------------------------------------------------------------
>    Zach Shelby - Researcher         Zach.Shelby@vtt.fi
>    VTT Elektronics                  Phone   +358 8 551 2164 (Office)
>    Kaitov=E4yl=E4 1, PL 1100            Fax     +358 8 551 2320
>    90571 Oulu, Finland              Mobile  +358 40 7796297=20
> =
----------------------------------------------------------------------
>                     http://paula.oulu.fi/~zdshelby
>        Home:   Yliopistokatu 14-707  90570 Oulu, Finland
>=20
>=20
>=20

------_=_NextPart_001_01C08002.D86B3B50
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: [seamoby] RE: Terminology draft</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>It would be a mistake, to attempt to map the =
reference architecture onto</FONT>
<BR><FONT SIZE=3D2>existing architectures by defining synonyms. There =
are simply too many issues</FONT>
<BR><FONT SIZE=3D2>that would be opened up. For example, a BS is a box, =
while an AP does not necessarily</FONT>
<BR><FONT SIZE=3D2>have to be (the AR and the AP could be implemented =
in one box).</FONT>
</P>

<P><FONT SIZE=3D2>One of the reasons the original discussions around =
the architecture avoided</FONT>
<BR><FONT SIZE=3D2>going beyond the edge of the routing fabric was to =
avoid the black abyss of</FONT>
<BR><FONT SIZE=3D2>subnetwork architectures.</FONT>
</P>

<P><FONT SIZE=3D2>It would be my preference, to define a logical =
reference architecture, rather </FONT>
<BR><FONT SIZE=3D2>then a physical one. However, I suspect that this =
would not happen.</FONT>
</P>

<P><FONT SIZE=3D2>Gary</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Zach Shelby [<A =
HREF=3D"mailto:zach.shelby@vtt.fi">mailto:zach.shelby@vtt.fi</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, January 16, 2001 4:06 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: seamoby@diameter.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [seamoby] RE: Terminology draft</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; After reviewing =
draft-brain-seamoby-terms-00.txt I find it to be an</FONT>
<BR><FONT SIZE=3D2>&gt; excellent compilation of very reasonable =
terminology and encourage all</FONT>
<BR><FONT SIZE=3D2>&gt; to get comments back to the authors on =
this.&nbsp; Is it possible for this</FONT>
<BR><FONT SIZE=3D2>&gt; draft (or one similar) to go to RFC for =
seamoby?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Comment. Add a section on synonyms, including =
all the alternative</FONT>
<BR><FONT SIZE=3D2>&gt; terms floating around our different =
backgrounds, with the appropriate</FONT>
<BR><FONT SIZE=3D2>&gt; equivalent term of the draft. BS =3D AP is a =
good start.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Another. Section 2.2.1 (scope of handover) Add =
a &quot;layer 2 handover&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; example situation to the appendix. I'm still =
not clear how this is a</FONT>
<BR><FONT SIZE=3D2>&gt; handover. If the same interface has multiple =
channels which the user</FONT>
<BR><FONT SIZE=3D2>&gt; can use, isn't that micro-diversity? Or should =
it could be called</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;layer 2 reconfiguration&quot;, or not be =
called at all.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; Zach</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
----------------------------------------------------------------------</=
FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Zach Shelby - =
Researcher&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Zach.Shelby@vtt.fi</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; VTT =
Elektronics&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone&nbsp;&nbsp; +358 8 551 =
2164 (Office)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Kaitov=E4yl=E4 1, PL =
1100&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Fax&nbsp;&nbsp;&nbsp;&nbsp; +358 8 551 2320</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; 90571 Oulu, =
Finland&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; Mobile&nbsp; +358 40 7796297 </FONT>
<BR><FONT SIZE=3D2>&gt; =
----------------------------------------------------------------------</=
FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"http://paula.oulu.fi/~zdshelby" =
TARGET=3D"_blank">http://paula.oulu.fi/~zdshelby</A></FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Home:&nbsp;&nbsp; Yliopistokatu 14-707&nbsp; 90570 Oulu, Finland</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C08002.D86B3B50--


From owner-seamoby@diameter.org  Tue Jan 16 18:37:08 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23354
	for <seamoby-archive@odin.ietf.org>; Tue, 16 Jan 2001 18:37:07 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0GMRU404439
	for seamoby-list; Tue, 16 Jan 2001 14:27:30 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0GMRRW04432
	for <seamoby@diameter.org>; Tue, 16 Jan 2001 14:27:28 -0800
Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com;
          Tue, 16 Jan 2001 16:34:15 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <DCDS9PZ2>; Tue, 16 Jan 2001 16:32:00 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8B1B@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Jukka Manner'" <jmanner@cs.helsinki.fi>, cnyap <cny@ieee.org>
Cc: seamoby <seamoby@diameter.org>,
        seamoby_context@standards.nortelnetworks.com
Subject: RE: [seamoby] Answer to a question on the mobility terminology dr aft
Date: Tue, 16 Jan 2001 16:31:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C08003.C09B6300"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C08003.C09B6300
Content-Type: text/plain;
	charset="iso-8859-1"

I think that this distinction between intra-AR and inter-AR handover
is a useful one, as it will help us distinguish when CT is to happen and
when it
is not to happen (at least at the IP layer).

This, in my view, is the only reason to identify the AP in the reference
architecture. Unfortunately, having it there opens up the can of worms
related to AP to AP handovers. While I think this is an interesting area
to explore, it seems to me that this will take us into the area described
by some as "L2 mobility" or "soft handover".

Gary

> -----Original Message-----
> From: Jukka Manner [mailto:jmanner@cs.helsinki.fi]
> Sent: Saturday, January 13, 2001 4:24 AM
> To: cnyap
> Cc: seamoby
> Subject: [seamoby] Answer to a question on the mobility terminology
> draft
> 
> 
> On Fri, 12 Jan 2001, cnyap wrote:
> 
> > Hi
> >
> > Could you please give more explaination on Intra-AR Handover.
> > It is not very clear in the draft.
> >
> 
> 	As an example, let's consider an AR which has network 
> interfaces to APs
> under its control. When a MH switches APs under the same AR, 
> it does an intra-AR
> handover. The AN internal routing does thus not change, only 
> the AR needs to
> update its internal routing to reflect the new network 
> interface, where the MH
> now is located. It also may need to move packets from queues 
> on the old network
> interface to new queues. If the AP and AR are one single 
> component and there is
> only one AP, then an intra-AR handover never happens.
> 
> 
> 	Jukka
> 
> 

------_=_NextPart_001_01C08003.C09B6300
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] Answer to a question on the mobility terminology draft</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I think that this distinction between intra-AR and inter-AR handover</FONT>
<BR><FONT SIZE=2>is a useful one, as it will help us distinguish when CT is to happen and when it</FONT>
<BR><FONT SIZE=2>is not to happen (at least at the IP layer).</FONT>
</P>

<P><FONT SIZE=2>This, in my view, is the only reason to identify the AP in the reference</FONT>
<BR><FONT SIZE=2>architecture. Unfortunately, having it there opens up the can of worms</FONT>
<BR><FONT SIZE=2>related to AP to AP handovers. While I think this is an interesting area</FONT>
<BR><FONT SIZE=2>to explore, it seems to me that this will take us into the area described</FONT>
<BR><FONT SIZE=2>by some as &quot;L2 mobility&quot; or &quot;soft handover&quot;.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Jukka Manner [<A HREF="mailto:jmanner@cs.helsinki.fi">mailto:jmanner@cs.helsinki.fi</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Saturday, January 13, 2001 4:24 AM</FONT>
<BR><FONT SIZE=2>&gt; To: cnyap</FONT>
<BR><FONT SIZE=2>&gt; Cc: seamoby</FONT>
<BR><FONT SIZE=2>&gt; Subject: [seamoby] Answer to a question on the mobility terminology</FONT>
<BR><FONT SIZE=2>&gt; draft</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; On Fri, 12 Jan 2001, cnyap wrote:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Hi</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Could you please give more explaination on Intra-AR Handover.</FONT>
<BR><FONT SIZE=2>&gt; &gt; It is not very clear in the draft.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; As an example, let's consider an AR which has network </FONT>
<BR><FONT SIZE=2>&gt; interfaces to APs</FONT>
<BR><FONT SIZE=2>&gt; under its control. When a MH switches APs under the same AR, </FONT>
<BR><FONT SIZE=2>&gt; it does an intra-AR</FONT>
<BR><FONT SIZE=2>&gt; handover. The AN internal routing does thus not change, only </FONT>
<BR><FONT SIZE=2>&gt; the AR needs to</FONT>
<BR><FONT SIZE=2>&gt; update its internal routing to reflect the new network </FONT>
<BR><FONT SIZE=2>&gt; interface, where the MH</FONT>
<BR><FONT SIZE=2>&gt; now is located. It also may need to move packets from queues </FONT>
<BR><FONT SIZE=2>&gt; on the old network</FONT>
<BR><FONT SIZE=2>&gt; interface to new queues. If the AP and AR are one single </FONT>
<BR><FONT SIZE=2>&gt; component and there is</FONT>
<BR><FONT SIZE=2>&gt; only one AP, then an intra-AR handover never happens.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Jukka</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C08003.C09B6300--


From owner-seamoby@diameter.org  Tue Jan 16 18:46:45 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23463
	for <seamoby-archive@odin.ietf.org>; Tue, 16 Jan 2001 18:46:44 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0GMPxr04420
	for seamoby-list; Tue, 16 Jan 2001 14:25:59 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0GMPuW04415
	for <seamoby@diameter.org>; Tue, 16 Jan 2001 14:25:56 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <CTQSVY8P>; Tue, 16 Jan 2001 16:34:12 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078BA4@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        Colin Elliott
	 <celliott@herc.zucotto.com>,
        seamoby-paging@egroups.com, James Kempf
	 <James.Kempf@eng.sun.com>,
        James.Kempf@eng.sun.com, ramjee@dnrc.bell-labs.com
Cc: seamoby@diameter.org, Phil_Neumiller@3Com.com, seamoby-paging@egroups.com
Subject: RE: [seamoby-paging] RE: [seamoby] Some thoughts on paging proble
	 m
Date: Tue, 16 Jan 2001 16:34:12 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C08004.11868946"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C08004.11868946
Content-Type: text/plain;
	charset="iso-8859-1"

I agree, it was an old email of mine that someone reponded to.
In writing a quick response, I forgot to clarify that it is an L2 issue.
 
- Kulwinder.
 

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Tuesday, January 16, 2001 3:19 PM
To: 'Kulwinder Atwal'; Colin Elliott; seamoby-paging@egroups.com; James
Kempf; James.Kempf@eng.sun.com; ramjee@dnrc.bell-labs.com
Cc: seamoby@diameter.org; Phil_Neumiller@3com.com;
seamoby-paging@egroups.com
Subject: RE: [seamoby-paging] RE: [seamoby] Some thoughts on paging proble m


Again, we must abstract out the mechanisms for selecting new APs and 
triggering the handoff. 

Gary 

 


------_=_NextPart_001_01C08004.11868946
Content-Type: text/html;
	charset="iso-8859-1"

<!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-paging] RE: [seamoby] Some thoughts on paging problem</TITLE>

<META content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=986022821-16012001><FONT face=Arial color=#0000ff size=2>I 
agree, it was an old email of mine that someone reponded to.</FONT></SPAN></DIV>
<DIV><SPAN class=986022821-16012001><FONT face=Arial color=#0000ff size=2>In 
writing a quick response, I forgot to clarify that it is an L2 
issue.</FONT></SPAN></DIV>
<DIV><SPAN class=986022821-16012001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=986022821-16012001><FONT face=Arial color=#0000ff size=2>- 
Kulwinder.</FONT></SPAN></DIV>
<DIV><SPAN class=986022821-16012001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&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:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Tuesday, January 16, 2001 
  3:19 PM<BR><B>To:</B> 'Kulwinder Atwal'; Colin Elliott; 
  seamoby-paging@egroups.com; James Kempf; James.Kempf@eng.sun.com; 
  ramjee@dnrc.bell-labs.com<BR><B>Cc:</B> seamoby@diameter.org; 
  Phil_Neumiller@3com.com; seamoby-paging@egroups.com<BR><B>Subject:</B> RE: 
  [seamoby-paging] RE: [seamoby] Some thoughts on paging proble 
  m<BR></FONT></DIV>
  <P><FONT size=2>Again, we must abstract out the mechanisms for selecting new 
  APs and</FONT> <BR><FONT size=2>triggering the handoff.</FONT> </P>
  <P><FONT size=2>Gary</FONT> </P>
  <P><FONT size=2></FONT>&nbsp;</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C08004.11868946--


From owner-seamoby@diameter.org  Tue Jan 16 20:16:17 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24636
	for <seamoby-archive@odin.ietf.org>; Tue, 16 Jan 2001 20:16:15 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0H0r3c04798
	for seamoby-list; Tue, 16 Jan 2001 16:53:03 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0H0r1W04793
	for <seamoby@diameter.org>; Tue, 16 Jan 2001 16:53:01 -0800
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f0H009128116;
	Tue, 16 Jan 2001 16:00:09 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104])
	by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f0H01D024511;
	Tue, 16 Jan 2001 16:01:14 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 882569D7.000045C6 ; Tue, 16 Jan 2001 16:02:58 -0800
X-Lotus-FromDomain: 3COM
From: Phil_Neumiller@3Com.com
To: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
cc: seamoby@diameter.org
Message-ID: <882569D7.000044A5.00@hqoutbound.ops.3com.com>
Date: Tue, 16 Jan 2001 18:08:00 -0600
Subject: RE: [seamoby] micro, schmicro
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-seamoby@diameter.org
Precedence: bulk




I think I disagree.  Why would the FAs necessarily find these routes?
You could have situations like the following:

 FA1                    FA2
  |                      |
(net 1)---------------(net 2)
  |                      |
(net 3)---------------(net 4)
  |                      |
(AP 1)                (AP 2)
  |
 MN  --> handing over to ^

Here net 1 is a subnet of FA1, and net 3 is a subnet of
net 1.  The OSPF or RIP path between AP 2 and FA 1, may
be different that that between AP 1 and AP 2. which may
have a mesh link between net 3 and net 4 that is unknown
to FA1 and FA2 right?





Kulwinder Atwal <kulwinder.atwal@zucotto.com> on 01/16/2001 05:46:42 PM

Sent by:  Kulwinder Atwal <kulwinder.atwal@zucotto.com>


To:   Phil Neumiller/MW/US/3Com, Seamoby@diameter.org
cc:
Subject:  RE: [seamoby] micro, schmicro



>
>
> Um, actually what subnet you are on has an intimate relationship to
> what edge router you are using or what core router. The whole point
> of having a router is to bridge two subnets, in subnet based routing.
>
> James,
>
> I understand this.  However, it may be the case that useable
> routes exist
> between
> an edge router pair that are unknown to the mobility agents
> being used.

If the routes are IP routes then the IP mobility agents will be
aware of them, and will find the shortest path.  Otherwise, there is an
error in the implementation.

If the routes are L2 routes then this is an L2 issue.

Unless you are getting at something else.







From owner-seamoby@diameter.org  Tue Jan 16 20:18:54 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24686
	for <seamoby-archive@odin.ietf.org>; Tue, 16 Jan 2001 20:18:54 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0H0cTJ04741
	for seamoby-list; Tue, 16 Jan 2001 16:38:29 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0H0cQW04736
	for <Seamoby@diameter.org>; Tue, 16 Jan 2001 16:38:26 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <CTQSVZA7>; Tue, 16 Jan 2001 18:46:44 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078BA5@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Phil_Neumiller@3com.com'" <Phil_Neumiller@3Com.com>,
        Seamoby@diameter.org
Subject: RE: [seamoby] micro, schmicro
Date: Tue, 16 Jan 2001 18:46:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

> 
> 
> Um, actually what subnet you are on has an intimate relationship to
> what edge router you are using or what core router. The whole point
> of having a router is to bridge two subnets, in subnet based routing.
> 
> James,
> 
> I understand this.  However, it may be the case that useable 
> routes exist
> between
> an edge router pair that are unknown to the mobility agents 
> being used.

If the routes are IP routes then the IP mobility agents will be 
aware of them, and will find the shortest path.  Otherwise, there is an
error in the implementation.

If the routes are L2 routes then this is an L2 issue.

Unless you are getting at something else.

- Kulwinder.

>  If this
> is
> the case the path between the mobile and the new ER is 
> shorter when the mobility
> agents are bypassed.  This will not always be the case, but 
> the worse case is
> that
> you have to route back through the mobility agents right?  
> Ideally wireless
> networks
> that handover to each other frequently will become mesh 
> networked at the edge of
> the big I overtime.  That is we follow the simple principle 
> of allowing the
> physical
> network to adapt overtime to the logical traffic patterns.
> 
> -Phil
> 
> 
> 
> 
> 


From owner-seamoby@diameter.org  Tue Jan 16 22:28:43 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26964
	for <seamoby-archive@odin.ietf.org>; Tue, 16 Jan 2001 22:28:43 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0H23xP04996
	for seamoby-list; Tue, 16 Jan 2001 18:03:59 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0H23vW04991
	for <seamoby@diameter.org>; Tue, 16 Jan 2001 18:03:57 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <CTQSVZCF>; Tue, 16 Jan 2001 20:12:15 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078BA7@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Phil_Neumiller@3com.com'" <Phil_Neumiller@3Com.com>,
        Kulwinder Atwal
	 <kulwinder.atwal@zucotto.com>
Cc: seamoby@diameter.org
Subject: RE: [seamoby] micro, schmicro
Date: Tue, 16 Jan 2001 20:12:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk



> -----Original Message-----
> From: Phil_Neumiller@3com.com [mailto:Phil_Neumiller@3com.com]
> Sent: Tuesday, January 16, 2001 7:08 PM
> To: Kulwinder Atwal
> Cc: seamoby@diameter.org
> Subject: RE: [seamoby] micro, schmicro
> 
> 
> 
> 
> 
> I think I disagree.  Why would the FAs necessarily find these routes?
> You could have situations like the following:
> 
>  FA1                    FA2
>   |                      |
> (net 1)---------------(net 2)
>   |                      |
> (net 3)---------------(net 4)
>   |                      |
> (AP 1)                (AP 2)
>   |
>  MN  --> handing over to ^
> 
> Here net 1 is a subnet of FA1, and net 3 is a subnet of
> net 1.  The OSPF or RIP path between AP 2 and FA 1, may
> be different that that between AP 1 and AP 2. which may
> have a mesh link between net 3 and net 4 that is unknown
> to FA1 and FA2 right?
> 

Making your diagram technology neutral:
 
  Big I			Big I
   |                      |
 (CR 3)------CRL1----- (CR 2)
   |                      |
 (OAR)-------ARL1-----  (NAR)
   |                      |
 (OAP)                  (NAP)
   |
  MN  --> handing over to ^> 
 

CR = Core Router

AR = Access Router 

OAR = Old Access Router

NAR = New Access Router

I think your model in encouraging bad real-time network design.  The ARs
should have the functionality to resolve MN moves through one link.  If ARs
agree on one link for passing all MN handover related messages in advance,
this will cut down on the amount of messaging needed for a handover as well.


Either staticly, or dynamically the Access Routers (OAR/NAR) need to agree
on one single path for MN moves in advance of the move.  This path may even
be set once by the Network Administor during network setup.

Further, placing the functionality required for the move that many layers
away from the MN will most likely not result in the real-time behaviour we
are looking for.

This is why I believe the better solution is to place the primary
functionality for the move in the ARs nearest the MN.   

Unlike the general Internet, Real-Time network design must consider
deterministic behaviour as a primary design objective.  

If the Network Designer wishes Real-Time behaviour to be a primary design
goal, then deterministic behaviour must be a primary design objective. 

If we want Real-Time hand-overs then at least:

 - we must place Real-time bounds on "Routed Clouds"
 - move decision making closer to the MN
 - limit handover messaging to one pre-determined path

Also, since the problem space encompasses mobile wireless we must provide
positive confirmation of every message between the MN and an AR.

- Kulwinder.

> 
> 
> Kulwinder Atwal <kulwinder.atwal@zucotto.com> on 01/16/2001 
> 05:46:42 PM
> 
> Sent by:  Kulwinder Atwal <kulwinder.atwal@zucotto.com>
> 
> 
> To:   Phil Neumiller/MW/US/3Com, Seamoby@diameter.org
> cc:
> Subject:  RE: [seamoby] micro, schmicro
> 
> 
> 
> >
> >
> > Um, actually what subnet you are on has an intimate relationship to
> > what edge router you are using or what core router. The whole point
> > of having a router is to bridge two subnets, in subnet 
> based routing.
> >
> > James,
> >
> > I understand this.  However, it may be the case that useable
> > routes exist
> > between
> > an edge router pair that are unknown to the mobility agents
> > being used.
> 
> If the routes are IP routes then the IP mobility agents will be
> aware of them, and will find the shortest path.  Otherwise, 
> there is an
> error in the implementation.
> 
> If the routes are L2 routes then this is an L2 issue.
> 
> Unless you are getting at something else.
> 
> 
> 
> 
> 


From owner-seamoby@diameter.org  Tue Jan 16 22:39:42 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27971
	for <seamoby-archive@odin.ietf.org>; Tue, 16 Jan 2001 22:39:42 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0H2kEp05104
	for seamoby-list; Tue, 16 Jan 2001 18:46:14 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0H2kCW05099
	for <seamoby@diameter.org>; Tue, 16 Jan 2001 18:46:12 -0800
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id RAA13999;
	Tue, 16 Jan 2001 17:54:24 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA23944; Tue, 16 Jan 2001 17:54:24 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14948.64335.938626.154728@thomasm-u1.cisco.com>
Date: Tue, 16 Jan 2001 17:54:23 -0800 (PST)
To: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
Cc: "'Phil_Neumiller@3com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
Subject: RE: [seamoby] micro, schmicro
In-Reply-To: <FC0292EA4D13D34EA2E5FC728D70A8E3078BA7@NEPTUNE.zucotto.com>
References: <FC0292EA4D13D34EA2E5FC728D70A8E3078BA7@NEPTUNE.zucotto.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


I think you are misunderstanding Phil's point
which I took to mean that the placement of the
foreign agent is not necessarily the same as the
placement of the AR. While I wonder whether that's
an especially wise idea from the standpoint of
needing to have a security relationship with both
the AR (aka NAS) and the FA (for BU's, say), I
think I probably disagree with your premise too.
I don't think that we can or should make any
assumption that the AR's will always know a priori
about one another. I think it's useful in many
cases to allow such topology knowledge to be used
for network based moves, but this is not
sufficient: it's a local optimization. The more
general case where the old AR doesn't know squat
about the new AR is also a perfectly valid case
that needs to be accounted for.

	   Mike


Kulwinder Atwal writes:
 > Making your diagram technology neutral:
 >  
 >   Big I			Big I
 >    |                      |
 >  (CR 3)------CRL1----- (CR 2)
 >    |                      |
 >  (OAR)-------ARL1-----  (NAR)
 >    |                      |
 >  (OAP)                  (NAP)
 >    |
 >   MN  --> handing over to ^> 
 >  
 > 
 > CR = Core Router
 > 
 > AR = Access Router 
 > 
 > OAR = Old Access Router
 > 
 > NAR = New Access Router
 > 
 > I think your model in encouraging bad real-time network design.  The ARs
 > should have the functionality to resolve MN moves through one link.  If ARs
 > agree on one link for passing all MN handover related messages in advance,
 > this will cut down on the amount of messaging needed for a handover as well.
 > 
 > 
 > Either staticly, or dynamically the Access Routers (OAR/NAR) need to agree
 > on one single path for MN moves in advance of the move.  This path may even
 > be set once by the Network Administor during network setup.
 > 
 > Further, placing the functionality required for the move that many layers
 > away from the MN will most likely not result in the real-time behaviour we
 > are looking for.
 > 
 > This is why I believe the better solution is to place the primary
 > functionality for the move in the ARs nearest the MN.   
 > 
 > Unlike the general Internet, Real-Time network design must consider
 > deterministic behaviour as a primary design objective.  
 > 
 > If the Network Designer wishes Real-Time behaviour to be a primary design
 > goal, then deterministic behaviour must be a primary design objective. 
 > 
 > If we want Real-Time hand-overs then at least:
 > 
 >  - we must place Real-time bounds on "Routed Clouds"
 >  - move decision making closer to the MN
 >  - limit handover messaging to one pre-determined path
 > 
 > Also, since the problem space encompasses mobile wireless we must provide
 > positive confirmation of every message between the MN and an AR.


From owner-seamoby@diameter.org  Tue Jan 16 23:37:47 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00041
	for <seamoby-archive@odin.ietf.org>; Tue, 16 Jan 2001 23:37:46 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0H4Hh005219
	for seamoby-list; Tue, 16 Jan 2001 20:17:43 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0H4GQW05214
	for <seamoby@diameter.org>; Tue, 16 Jan 2001 20:16:26 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <CTQSVZD3>; Tue, 16 Jan 2001 22:24:44 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078BA8@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Michael Thomas'" <mat@cisco.com>
Cc: "'Phil_Neumiller@3com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
Subject: RE: [seamoby] micro, schmicro
Date: Tue, 16 Jan 2001 22:24:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

> 
> I think you are misunderstanding Phil's point
> which I took to mean that the placement of the
> foreign agent is not necessarily the same as the
> placement of the AR. While I wonder whether that's
> an especially wise idea from the standpoint of
> needing to have a security relationship with both
> the AR (aka NAS) and the FA (for BU's, say), I
> think I probably disagree with your premise too.
> I don't think that we can or should make any
> assumption that the AR's will always know a priori
> about one another. I think it's useful in many
> cases to allow such topology knowledge to be used
> for network based moves, but this is not
> sufficient: it's a local optimization. The more
> general case where the old AR doesn't know squat
> about the new AR is also a perfectly valid case
> that needs to be accounted for.
> 
> 	   Mike

Yes, I think we can do better.

At least we must say that the OAR and the NAR must communicate 
messages affecting the handover either through a single agreed upon 
path.  

Or, use transactions in Seamoby such that a positive confirmation is
required 
 from both for every mode change.

I think Phil highlights some of the problems in current protocols that need
to be resolved by a transaction-based Seamoby protocol.

NB: I think calling it a Foriegn Agent is a little Xenophobic.  If I am at
work every day I am not in a "Foriegn" place.  I think as someone has
suggested "Mobility Agent" may be more technically accurate.

- Kulwinder.


From owner-seamoby@diameter.org  Wed Jan 17 06:25:13 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15481
	for <seamoby-archive@odin.ietf.org>; Wed, 17 Jan 2001 06:25:12 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0H9t9b05578
	for seamoby-list; Wed, 17 Jan 2001 01:55:09 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0H9t6W05573
	for <Seamoby@diameter.org>; Wed, 17 Jan 2001 01:55:07 -0800
Received: from esvir08nok.nokia.com (esvir08nokt.ntc.nokia.com [172.21.143.40])
	by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0H94J209214
	for <Seamoby@diameter.org>; Wed, 17 Jan 2001 11:04:19 +0200 (EET)
Received: from esebh02nok.ntc.nokia.com (unverified) by esvir08nok.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tac158f28785128d515e1@esvir08nok.nokia.com> for <Seamoby@diameter.org>;
 Wed, 17 Jan 2001 11:03:24 +0200
Received: by esebh02nok with Internet Mail Service (5.5.2652.78)
	id <C0KGRQFX>; Wed, 17 Jan 2001 11:03:24 +0200
Message-ID: <6D1A8E7871B9D211B3B00008C7490AA50336F6E1@treis03nok>
From: jaakko.sundquist@nokia.com
To: Seamoby@diameter.org
Subject: RE: [seamoby] micro, schmicro
Date: Wed, 17 Jan 2001 11:03:23 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi all,

I don't know, if this helps at all, but I thought I might share some of my
(not too distant) earlier experiences in mobility work on H.323 systems.
First of all, I have never seen a good definition for micro and macro
mobility. Yet people use these as if they were clearly and similarly
understood by everyone. If you ask me, micro mobility in the context of IP
networks is something that happens behind an access point or a base station,
i.e. no change of the CoA is involved and thus there isn't much (anything?)
that needs to be done in the IP layer. However, as I said, I'm sure there
are other definitions for micro mobility as well.
What we did in the H.323 Mobility work was not to use these terms, but
instead refer to the scope of the mobility in terms that were already
defined for H.323. Thus we ended up talking about intra-zone, inter-zone,
intra-domain and inter-domain mobility. In a similar manner, I would imagine
that terms, such as "intra/inter-link mobility", "intra/inter-subnet
mobility", "intra/inter domain mobility" or something similar could be used
with regards to Mobile IP and Seamoby. An alternative for this would, of
course, be to define unambigiously the terms "micro mobility" and "macro
mobility", but since these are already in use and mean various different
things depending on the context, I would imagine that the use of them would
lead to misunderstandings.

Just some thoughts of a previous lurker on the list...

------------------------------------------------
Jaakko Sundquist           * 
+358 50 3598281            * Audere est Facere!
jaakko.sundquist@nokia.com * 
------------------------------------------------ 

> Um, actually what subnet you are on has an intimate relationship to
> what edge router you are using or what core router. The whole point
> of having a router is to bridge two subnets, in subnet based routing.
> 
> James,
> 
> I understand this.  However, it may be the case that useable 
> routes exist
> between
> an edge router pair that are unknown to the mobility agents 
> being used.  If this
> is
> the case the path between the mobile and the new ER is 
> shorter when the mobility
> agents are bypassed.  This will not always be the case, but 
> the worse case is
> that
> you have to route back through the mobility agents right?  
> Ideally wireless
> networks
> that handover to each other frequently will become mesh 
> networked at the edge of
> the big I overtime.  That is we follow the simple principle 
> of allowing the
> physical
> network to adapt overtime to the logical traffic patterns.
> 
> -Phil
> 
> 
> 
> 
> 


From owner-seamoby@diameter.org  Wed Jan 17 08:33:22 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17091
	for <seamoby-archive@odin.ietf.org>; Wed, 17 Jan 2001 08:33:21 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0HCFvF05922
	for seamoby-list; Wed, 17 Jan 2001 04:15:57 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0HCFqW05916
	for <seamoby@diameter.org>; Wed, 17 Jan 2001 04:15:52 -0800
Received: from melkinpaasi.cs.Helsinki.FI (jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.8.8/8.8.8) with ESMTP id NAA22134 for <seamoby@diameter.org>; Wed, 17 Jan 2001 13:24:00 +0200
Date: Wed, 17 Jan 2001 13:23:57 +0200 (EET)
From: Jukka Manner <jmanner@cs.helsinki.fi>
To: <seamoby@diameter.org>
Subject: [seamoby] Terminology draft changed its name
Message-ID: <Pine.LNX.4.30.0101171315020.6714-100000@melkinpaasi.cs.Helsinki.FI>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk


        Hi,

        I previously posted a message about a new draft we have been writing.
The draft is about definitions of common mobility-related terminology. My email
lacked a subject, btw...

        The draft is now known as "draft-manner-seamoby-terms-00.txt" (was
"draft-brain-seamoby-terms-00.txt")

	The draft is now available from the IETF central repository. It is a
proposal for the first steps towards common terminology, we don't want to try to
push any new definitions, but rather would like to raise discussions. We look
forward to comments from all Seamoby experts.


	Jukka Manner


---------- Forwarded message ----------
Date: Tue, 16 Jan 2001 06:40:41 -0500
From: Internet-Drafts@ietf.org
To: IETF-Announce:  ;
Subject: I-D ACTION:draft-manner-seamoby-terms-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Mobility Related Terminology
	Author(s)	: J. Manner et al.
	Filename	: draft-manner-seamoby-terms-00.txt
	Pages		: 17
	Date		: 15-Jan-01

There is a need for common definitions of terminology in the work to
be done around IP mobility. This memo defines terms for mobility
related terminology. It is intended as a living document for use by
the Seamoby working group, and especially for use in Seamoby drafts
and in WG discussions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-manner-seamoby-terms-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-manner-seamoby-terms-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-manner-seamoby-terms-00.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.



From owner-seamoby@diameter.org  Wed Jan 17 09:57:09 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19346
	for <seamoby-archive@odin.ietf.org>; Wed, 17 Jan 2001 09:57:09 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0HE1PQ06087
	for seamoby-list; Wed, 17 Jan 2001 06:01:25 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (flipper.cisco.com [171.69.25.141])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0HE1NW06081
	for <seamoby@diameter.org>; Wed, 17 Jan 2001 06:01:23 -0800
Received: from dblair-pc (dhcp-atlanta-220-42.cisco.com [161.44.220.42])
	by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id FAA15904;
	Wed, 17 Jan 2001 05:05:54 -0800 (PST)
Message-Id: <4.1.20010117080157.0409f4e0@flipper.cisco.com>
X-Sender: dblair@flipper.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 17 Jan 2001 08:04:48 -0500
To: Phil_Neumiller@3Com.com, Hamid Syed <hmsyed@nortelnetworks.com>
From: "Dana L. Blair" <dblair@cisco.com>
Subject: Re: [seamoby] A CNP perspective on context transfer.
Cc: seamoby_context@standards.nortelnetworks.com, seamoby@diameter.org,
        seamoby-mm@cdma-2000.org
In-Reply-To: <882569D6.006E5CD2.00@hqoutbound.ops.3com.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-seamoby@diameter.org
Precedence: bulk

At 02:07 PM 1/16/01 -0600, Phil_Neumiller@3Com.com wrote:
>
>
>
>The contract bidding analogy is very applicable to context transfer.  Consider
>the following.
>
>A CONTRACT between an AP/AR pair may be established by a process of mutual
>selection based on a two way transfer of context.  Handover candidates
>(contractors)
>evaluate hand over requests made by handover sources.  The candidates then
>submit bids on those parts of contracts for which they are suited.  The bids
>contain
>the parts of the contract that can be handled by both parties.  The handover
>source
>can then take the best bid from its perspective and assign the handover in a
>locally
>optimal manner.  This scales to the globe.
>
>I believe the transport mechanism we put in place for context transfer should
>support this pattern.  The semantics of payload are interpreted by the local
>mobility manager (micro-mobility) not the transport mechanism itself.

This is an interesting discussion for the context transfer design team.  I tend to
agree that there should be something like this as part of the context transfer mechanism,
and a mobility solution (micro, macro, ...) could use this to allow the Mobile Node to
make the "best" handoff decision.

thanks,
Dana


>
>Thanks,
>
>Phil
>
>



From owner-seamoby@diameter.org  Wed Jan 17 09:58:37 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19424
	for <seamoby-archive@odin.ietf.org>; Wed, 17 Jan 2001 09:58:36 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0HELWJ06170
	for seamoby-list; Wed, 17 Jan 2001 06:21:32 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from c007.snv.cp.net (c007-h008.c007.snv.cp.net [209.228.33.214])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f0HELVW06165
	for <seamoby@diameter.org>; Wed, 17 Jan 2001 06:21:31 -0800
Received: (cpmta 21156 invoked from network); 17 Jan 2001 05:29:47 -0800
Received: from dsl-64-193-0-129.telocity.com (HELO telocity.com) (64.193.0.129)
  by smtp.telocity.com (209.228.33.214) with SMTP; 17 Jan 2001 05:29:47 -0800
X-Sent: 17 Jan 2001 13:29:47 GMT
Message-ID: <3A659EBA.17882CD0@telocity.com>
Date: Wed, 17 Jan 2001 07:31:38 -0600
From: Phil Neumiller <neumiller@telocity.com>
Organization: 3Com
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: seamoby@diameter.org
Subject: Re: [seamoby] micro, schmicro
References: <FC0292EA4D13D34EA2E5FC728D70A8E3078BA8@NEPTUNE.zucotto.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Michael Thomas wrote:
> 
> I think you are misunderstanding Phil's point
> which I took to mean that the placement of the
> foreign agent is not necessarily the same as the
> placement of the AR.

Yes this is my point.

> While I wonder whether that's
> an especially wise idea from the standpoint of
> needing to have a security relationship with both
> the AR (aka NAS) and the FA (for BU's, say), I
> think I probably disagree with your premise too.
> I don't think that we can or should make any
> assumption that the AR's will always know a priori
> about one another. I think it's useful in many
> cases to allow such topology knowledge to be used
> for network based moves, but this is not
> sufficient: it's a local optimization. The more
> general case where the old AR doesn't know squat
> about the new AR is also a perfectly valid case
> that needs to be accounted for.
> 
I wasn't sure if anyone would understand my arcane
drawing but I believe the jist of my argument has
been better stated by Michael above.  

Kulwinder,

Whether we like it our not, I think one of SeaMoby's
requirements will be to indeed cooperate with MIPv4
and MIPv6 since they "pretty much" exist.  So I am not 
afraid of using terms like FA when talking about SeaMoby
requirements since these things are part of reality
currently and thus make up fixed parts of our problem
space.

Thanks,

Phil


From owner-seamoby@diameter.org  Wed Jan 17 10:21:59 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19877
	for <seamoby-archive@odin.ietf.org>; Wed, 17 Jan 2001 10:21:58 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0HEoYF06297
	for seamoby-list; Wed, 17 Jan 2001 06:50:34 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0HEoWW06292
	for <Seamoby@diameter.org>; Wed, 17 Jan 2001 06:50:32 -0800
Received: from esvir06nok.ntc.nokia.com (esvir06nokt.ntc.nokia.com [172.21.143.38])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0HDwoC15910
	for <Seamoby@diameter.org>; Wed, 17 Jan 2001 15:58:50 +0200 (EET)
Received: from esebh12nok.ntc.nokia.com (unverified) by esvir06nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tac158f2611b5129e39030@esvir06nok.ntc.nokia.com>;
 Wed, 17 Jan 2001 15:58:50 +0200
Received: by esebh12nok with Internet Mail Service (5.5.2652.78)
	id <C0K8FMST>; Wed, 17 Jan 2001 15:57:58 +0200
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DF62C@eseis04nok>
From: john.loughney@nokia.com
To: neumiller@telocity.com, jaakko.sundquist@nokia.com
Cc: Seamoby@diameter.org
Subject: RE: [seamoby] micro, schmicro
Date: Wed, 17 Jan 2001 15:57:53 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Phil,

> Also, I believe edge mobility is active ALL the time, and 
> core mobility (mobile IP) is active WHEN subnet boundaries 
> change.  Also, I believe that edge mobility must compensate 
> for the latency of adjustments in core routing updates made 
> by mobile IP.

As I understand the problem space, I don't think SeaMoby will
be tackling routing issues - after all we are in the
TRANSPORT AREA.  Anyhow, if you feel that routing issues
are something that we must solve, then I imagine that we
will need to re-charter and be in the Routing Area.

I hope to avoid getting into the routing area myself,
as I think it will unduly complicate matters.

br,
John


From owner-seamoby@diameter.org  Wed Jan 17 10:39:25 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20338
	for <seamoby-archive@odin.ietf.org>; Wed, 17 Jan 2001 10:39:24 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0HETUr06221
	for seamoby-list; Wed, 17 Jan 2001 06:29:30 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f0HETSW06216
	for <Seamoby@diameter.org>; Wed, 17 Jan 2001 06:29:28 -0800
Received: (cpmta 25964 invoked from network); 17 Jan 2001 05:37:42 -0800
Received: from dsl-64-193-0-129.telocity.com (HELO telocity.com) (64.193.0.129)
  by smtp.telocity.com (209.228.33.206) with SMTP; 17 Jan 2001 05:37:42 -0800
X-Sent: 17 Jan 2001 13:37:42 GMT
Message-ID: <3A65A095.73EB1B7B@telocity.com>
Date: Wed, 17 Jan 2001 07:39:33 -0600
From: Phil Neumiller <neumiller@telocity.com>
Organization: 3Com
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: jaakko.sundquist@nokia.com
CC: Seamoby@diameter.org
Subject: Re: [seamoby] micro, schmicro
References: <6D1A8E7871B9D211B3B00008C7490AA50336F6E1@treis03nok>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

jaakko.sundquist@nokia.com wrote:
> 
> Hi all,
> 
> I don't know, if this helps at all, but I thought I might share some of my
> (not too distant) earlier experiences in mobility work on H.323 systems.
> First of all, I have never seen a good definition for micro and macro
> mobility. Yet people use these as if they were clearly and similarly
> understood by everyone. If you ask me, micro mobility in the context of IP
> networks is something that happens behind an access point or a base station,
> i.e. no change of the CoA is involved and thus there isn't much (anything?)
> that needs to be done in the IP layer. However, as I said, I'm sure there
> are other definitions for micro mobility as well.

You are correct.  This seems to be the running definition or what I have
called the "classic" definition of micro-mobility.  Now I have
questioned
whether this distinction is a useful one.  My feeling is that edge
versus
core mobility is a far more important distinction than a change in
subnet.

Also, I believe edge mobility is active ALL the time, and core mobility 
(mobile IP) is active WHEN subnet boundaries change.  Also, I believe
that edge mobility must compensate for the latency of adjustments in
core
routing updates made by mobile IP.

So, as I have stated in every design team message list, I hope we can 
convince the list to abandon this terminology and recognize the real 
problem which is edge versus core.  Complex behavior enabling seamless
mobility will be best implemented in edge devices of the global
Internet.
This is the ONLY way that it will scale globally.  As Tom Petty said,
"No, I won't back down.." on this one.

> What we did in the H.323 Mobility work was not to use these terms, but
> instead refer to the scope of the mobility in terms that were already
> defined for H.323. Thus we ended up talking about intra-zone, inter-zone,
> intra-domain and inter-domain mobility. In a similar manner, I would imagine
> that terms, such as "intra/inter-link mobility", "intra/inter-subnet
> mobility", "intra/inter domain mobility" or something similar could be used
> with regards to Mobile IP and Seamoby. An alternative for this would, of
> course, be to define unambigiously the terms "micro mobility" and "macro
> mobility", but since these are already in use and mean various different
> things depending on the context, I would imagine that the use of them would
> lead to misunderstandings.
> 
Here I would prefer we use the terminology of edge versus core mobility.
Can somebody shoot me down so I can get off this mantra??? :-)

TNX,

Phil (N9FCW, PSK/QPSK mbox = 10.140.700 MHz)


From owner-seamoby@diameter.org  Wed Jan 17 10:41:17 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20381
	for <seamoby-archive@odin.ietf.org>; Wed, 17 Jan 2001 10:41:16 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0HEjww06265
	for seamoby-list; Wed, 17 Jan 2001 06:45:58 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (flipper.cisco.com [171.69.25.141])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0HEjuW06259
	for <Seamoby@diameter.org>; Wed, 17 Jan 2001 06:45:56 -0800
Received: from dblair-pc (dhcp-atlanta-220-42.cisco.com [161.44.220.42])
	by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id FAA16851;
	Wed, 17 Jan 2001 05:53:52 -0800 (PST)
Message-Id: <4.1.20010117084455.040a81c0@flipper.cisco.com>
X-Sender: dblair@flipper.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 17 Jan 2001 08:54:15 -0500
To: Phil Neumiller <neumiller@telocity.com>, jaakko.sundquist@nokia.com
From: "Dana L. Blair" <dblair@cisco.com>
Subject: Re: [seamoby] micro, schmicro
Cc: Seamoby@diameter.org, seamoby-mm@cdma-2000.org
In-Reply-To: <3A65A095.73EB1B7B@telocity.com>
References: <6D1A8E7871B9D211B3B00008C7490AA50336F6E1@treis03nok>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Let's take this discussion back to the micro-mobility alias, since it is a mobility
discussion.

At 07:39 AM 1/17/01 -0600, Phil Neumiller wrote:
>jaakko.sundquist@nokia.com wrote:
>> 
>> Hi all,
>> 
>> I don't know, if this helps at all, but I thought I might share some of my
>> (not too distant) earlier experiences in mobility work on H.323 systems.
>> First of all, I have never seen a good definition for micro and macro
>> mobility. Yet people use these as if they were clearly and similarly
>> understood by everyone. If you ask me, micro mobility in the context of IP
>> networks is something that happens behind an access point or a base station,
>> i.e. no change of the CoA is involved and thus there isn't much (anything?)
>> that needs to be done in the IP layer. However, as I said, I'm sure there
>> are other definitions for micro mobility as well.
>
>You are correct.  This seems to be the running definition or what I have
>called the "classic" definition of micro-mobility.  Now I have
>questioned
>whether this distinction is a useful one.  My feeling is that edge
>versus
>core mobility is a far more important distinction than a change in
>subnet.

Edge and Core are too abstract terms to discuss detailed mobility solutions.
Cellular folks use the term Core to reference an MSC, HLR, other other systems.
IP folks use the term Core to referece a high speed backbone IP network.
Since we are within the IP context let's use specific IP terms.  That is
why I defined micro-mobility in terms of IP addressing an Access Links.

>
>Also, I believe edge mobility is active ALL the time, and core mobility 
>(mobile IP) is active WHEN subnet boundaries change.  Also, I believe

I think you need to define subnet more specifically.  For example, an ethernet
is an IP subnet which is part of a larger IP subnet for a department which
is part of a company IP subnet which is part of an ISP IP subnet which is
part of the internet.  Which subnet boundary are you referencing ?

I tried to avoid the subnet ambiguity by saying there are some boundaries where
the routable IP address assigned to the MN must change.  Then there are others
where it does not change.  micromobility applies to those cases where the
address does not change.

>that edge mobility must compensate for the latency of adjustments in
>core
>routing updates made by mobile IP.
>
>So, as I have stated in every design team message list, I hope we can 
>convince the list to abandon this terminology and recognize the real 
>problem which is edge versus core.  Complex behavior enabling seamless
>mobility will be best implemented in edge devices of the global
>Internet.
>This is the ONLY way that it will scale globally.  As Tom Petty said,
>"No, I won't back down.." on this one.

I don't think we disagree.  This design team is focussing on mobility solutions
that can be implemented at the edge of an IP network where the IP address
does not change.

Let's discuss on the call today.

thanks,
Dana

>
>> What we did in the H.323 Mobility work was not to use these terms, but
>> instead refer to the scope of the mobility in terms that were already
>> defined for H.323. Thus we ended up talking about intra-zone, inter-zone,
>> intra-domain and inter-domain mobility. In a similar manner, I would imagine
>> that terms, such as "intra/inter-link mobility", "intra/inter-subnet
>> mobility", "intra/inter domain mobility" or something similar could be used
>> with regards to Mobile IP and Seamoby. An alternative for this would, of
>> course, be to define unambigiously the terms "micro mobility" and "macro
>> mobility", but since these are already in use and mean various different
>> things depending on the context, I would imagine that the use of them would
>> lead to misunderstandings.
>> 
>Here I would prefer we use the terminology of edge versus core mobility.
>Can somebody shoot me down so I can get off this mantra??? :-)
>
>TNX,
>
>Phil (N9FCW, PSK/QPSK mbox = 10.140.700 MHz)



From owner-seamoby@diameter.org  Wed Jan 17 11:57:31 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21773
	for <seamoby-archive@odin.ietf.org>; Wed, 17 Jan 2001 11:57:30 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0HG72406407
	for seamoby-list; Wed, 17 Jan 2001 08:07:02 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0HG6uW06402
	for <seamoby@diameter.org>; Wed, 17 Jan 2001 08:07:00 -0800
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Wed, 17 Jan 2001 10:12:07 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <DCDS95Z4>; Wed, 17 Jan 2001 10:09:35 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8B24@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>,
        "'Phil_Neumiller@3com.com'" <Phil_Neumiller@3Com.com>
Cc: seamoby@diameter.org
Subject: RE: [seamoby] micro, schmicro
Date: Wed, 17 Jan 2001 10:09:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C08097.7D96B660"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C08097.7D96B660
Content-Type: text/plain;
	charset="iso-8859-1"

"encouraging bad real time design"? 

A valid point Kulwinder, but I have two observations:

 1. The imposition of topology restrictions over a wide area greatly
     changes the philosophy of the internet.

  2. In the limit, applying real time design rules yields ATM/ISDN/
      Telco type networks.

Somewhere is the balance, to be sure, for every interceding router
adds one "unit" of incremental delay (internet rule-of-thumb). One
answer is to put all handoff management at the link layer. This leads
to link layer subnets that are bigger then many autonomous systems.

Another answer is to distribute the mobility functionality to all routers,
and hope for route optimization.

The wrong answer, I think we all agree, is a mobility agent somewhere
at the far edge of the domain.

Gary

> -----Original Message-----
> From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
> Sent: Tuesday, January 16, 2001 8:12 PM
> To: 'Phil_Neumiller@3com.com'; Kulwinder Atwal
> Cc: seamoby@diameter.org
> Subject: RE: [seamoby] micro, schmicro
> 
> 
> 
> 
> > -----Original Message-----
> > From: Phil_Neumiller@3com.com [mailto:Phil_Neumiller@3com.com]
> > Sent: Tuesday, January 16, 2001 7:08 PM
> > To: Kulwinder Atwal
> > Cc: seamoby@diameter.org
> > Subject: RE: [seamoby] micro, schmicro
> > 
> > 
> > 
> > 
> > 
> > I think I disagree.  Why would the FAs necessarily find 
> these routes?
> > You could have situations like the following:
> > 
> >  FA1                    FA2
> >   |                      |
> > (net 1)---------------(net 2)
> >   |                      |
> > (net 3)---------------(net 4)
> >   |                      |
> > (AP 1)                (AP 2)
> >   |
> >  MN  --> handing over to ^
> > 
> > Here net 1 is a subnet of FA1, and net 3 is a subnet of
> > net 1.  The OSPF or RIP path between AP 2 and FA 1, may
> > be different that that between AP 1 and AP 2. which may
> > have a mesh link between net 3 and net 4 that is unknown
> > to FA1 and FA2 right?
> > 
> 
> Making your diagram technology neutral:
>  
>   Big I			Big I
>    |                      |
>  (CR 3)------CRL1----- (CR 2)
>    |                      |
>  (OAR)-------ARL1-----  (NAR)
>    |                      |
>  (OAP)                  (NAP)
>    |
>   MN  --> handing over to ^> 
>  
> 
> CR = Core Router
> 
> AR = Access Router 
> 
> OAR = Old Access Router
> 
> NAR = New Access Router
> 
> I think your model in encouraging bad real-time network 
> design.  The ARs
> should have the functionality to resolve MN moves through one 
> link.  If ARs
> agree on one link for passing all MN handover related 
> messages in advance,
> this will cut down on the amount of messaging needed for a 
> handover as well.
> 
> 
> Either staticly, or dynamically the Access Routers (OAR/NAR) 
> need to agree
> on one single path for MN moves in advance of the move.  This 
> path may even
> be set once by the Network Administor during network setup.
> 
> Further, placing the functionality required for the move that 
> many layers
> away from the MN will most likely not result in the real-time 
> behaviour we
> are looking for.
> 
> This is why I believe the better solution is to place the primary
> functionality for the move in the ARs nearest the MN.   
> 
> Unlike the general Internet, Real-Time network design must consider
> deterministic behaviour as a primary design objective.  
> 
> If the Network Designer wishes Real-Time behaviour to be a 
> primary design
> goal, then deterministic behaviour must be a primary design 
> objective. 
> 
> If we want Real-Time hand-overs then at least:
> 
>  - we must place Real-time bounds on "Routed Clouds"
>  - move decision making closer to the MN
>  - limit handover messaging to one pre-determined path
> 
> Also, since the problem space encompasses mobile wireless we 
> must provide
> positive confirmation of every message between the MN and an AR.
> 
> - Kulwinder.
> 
> > 
> > 
> > Kulwinder Atwal <kulwinder.atwal@zucotto.com> on 01/16/2001 
> > 05:46:42 PM
> > 
> > Sent by:  Kulwinder Atwal <kulwinder.atwal@zucotto.com>
> > 
> > 
> > To:   Phil Neumiller/MW/US/3Com, Seamoby@diameter.org
> > cc:
> > Subject:  RE: [seamoby] micro, schmicro
> > 
> > 
> > 
> > >
> > >
> > > Um, actually what subnet you are on has an intimate 
> relationship to
> > > what edge router you are using or what core router. The 
> whole point
> > > of having a router is to bridge two subnets, in subnet 
> > based routing.
> > >
> > > James,
> > >
> > > I understand this.  However, it may be the case that useable
> > > routes exist
> > > between
> > > an edge router pair that are unknown to the mobility agents
> > > being used.
> > 
> > If the routes are IP routes then the IP mobility agents will be
> > aware of them, and will find the shortest path.  Otherwise, 
> > there is an
> > error in the implementation.
> > 
> > If the routes are L2 routes then this is an L2 issue.
> > 
> > Unless you are getting at something else.
> > 
> > 
> > 
> > 
> > 
> 

------_=_NextPart_001_01C08097.7D96B660
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: [seamoby] micro, schmicro</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&quot;encouraging bad real time design&quot;? </FONT>
</P>

<P><FONT SIZE=3D2>A valid point Kulwinder, but I have two =
observations:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;1. The imposition of topology restrictions over =
a wide area greatly</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; changes the philosophy of =
the internet.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; 2. In the limit, applying real time design =
rules yields ATM/ISDN/</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Telco type =
networks.</FONT>
</P>

<P><FONT SIZE=3D2>Somewhere is the balance, to be sure, for every =
interceding router</FONT>
<BR><FONT SIZE=3D2>adds one &quot;unit&quot; of incremental delay =
(internet rule-of-thumb). One</FONT>
<BR><FONT SIZE=3D2>answer is to put all handoff management at the link =
layer. This leads</FONT>
<BR><FONT SIZE=3D2>to link layer subnets that are bigger then many =
autonomous systems.</FONT>
</P>

<P><FONT SIZE=3D2>Another answer is to distribute the mobility =
functionality to all routers,</FONT>
<BR><FONT SIZE=3D2>and hope for route optimization.</FONT>
</P>

<P><FONT SIZE=3D2>The wrong answer, I think we all agree, is a mobility =
agent somewhere</FONT>
<BR><FONT SIZE=3D2>at the far edge of the domain.</FONT>
</P>

<P><FONT SIZE=3D2>Gary</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Kulwinder Atwal [<A =
HREF=3D"mailto:kulwinder.atwal@zucotto.com">mailto:kulwinder.atwal@zucot=
to.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, January 16, 2001 8:12 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'Phil_Neumiller@3com.com'; Kulwinder =
Atwal</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: seamoby@diameter.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [seamoby] micro, schmicro</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Phil_Neumiller@3com.com [<A =
HREF=3D"mailto:Phil_Neumiller@3com.com">mailto:Phil_Neumiller@3com.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Tuesday, January 16, 2001 7:08 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: Kulwinder Atwal</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: seamoby@diameter.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: RE: [seamoby] micro, =
schmicro</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I think I disagree.&nbsp; Why would the =
FAs necessarily find </FONT>
<BR><FONT SIZE=3D2>&gt; these routes?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; You could have situations like the =
following:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; =
FA1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FA2</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (net 1)---------------(net 2)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (net 3)---------------(net 4)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (AP =
1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; (AP 2)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; MN&nbsp; --&gt; handing over to =
^</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Here net 1 is a subnet of FA1, and net 3 =
is a subnet of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; net 1.&nbsp; The OSPF or RIP path between =
AP 2 and FA 1, may</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; be different that that between AP 1 and AP =
2. which may</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; have a mesh link between net 3 and net 4 =
that is unknown</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to FA1 and FA2 right?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Making your diagram technology neutral:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; Big =
I&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Big I</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; (CR 3)------CRL1----- (CR 2)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; (OAR)-------ARL1-----&nbsp; (NAR)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; =
(OAP)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (NAP)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; MN&nbsp; --&gt; handing over to =
^&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; CR =3D Core Router</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; AR =3D Access Router </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; OAR =3D Old Access Router</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; NAR =3D New Access Router</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think your model in encouraging bad real-time =
network </FONT>
<BR><FONT SIZE=3D2>&gt; design.&nbsp; The ARs</FONT>
<BR><FONT SIZE=3D2>&gt; should have the functionality to resolve MN =
moves through one </FONT>
<BR><FONT SIZE=3D2>&gt; link.&nbsp; If ARs</FONT>
<BR><FONT SIZE=3D2>&gt; agree on one link for passing all MN handover =
related </FONT>
<BR><FONT SIZE=3D2>&gt; messages in advance,</FONT>
<BR><FONT SIZE=3D2>&gt; this will cut down on the amount of messaging =
needed for a </FONT>
<BR><FONT SIZE=3D2>&gt; handover as well.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Either staticly, or dynamically the Access =
Routers (OAR/NAR) </FONT>
<BR><FONT SIZE=3D2>&gt; need to agree</FONT>
<BR><FONT SIZE=3D2>&gt; on one single path for MN moves in advance of =
the move.&nbsp; This </FONT>
<BR><FONT SIZE=3D2>&gt; path may even</FONT>
<BR><FONT SIZE=3D2>&gt; be set once by the Network Administor during =
network setup.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Further, placing the functionality required for =
the move that </FONT>
<BR><FONT SIZE=3D2>&gt; many layers</FONT>
<BR><FONT SIZE=3D2>&gt; away from the MN will most likely not result in =
the real-time </FONT>
<BR><FONT SIZE=3D2>&gt; behaviour we</FONT>
<BR><FONT SIZE=3D2>&gt; are looking for.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This is why I believe the better solution is to =
place the primary</FONT>
<BR><FONT SIZE=3D2>&gt; functionality for the move in the ARs nearest =
the MN.&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Unlike the general Internet, Real-Time network =
design must consider</FONT>
<BR><FONT SIZE=3D2>&gt; deterministic behaviour as a primary design =
objective.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If the Network Designer wishes Real-Time =
behaviour to be a </FONT>
<BR><FONT SIZE=3D2>&gt; primary design</FONT>
<BR><FONT SIZE=3D2>&gt; goal, then deterministic behaviour must be a =
primary design </FONT>
<BR><FONT SIZE=3D2>&gt; objective. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If we want Real-Time hand-overs then at =
least:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; - we must place Real-time bounds on =
&quot;Routed Clouds&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; - move decision making closer to the =
MN</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; - limit handover messaging to one =
pre-determined path</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Also, since the problem space encompasses =
mobile wireless we </FONT>
<BR><FONT SIZE=3D2>&gt; must provide</FONT>
<BR><FONT SIZE=3D2>&gt; positive confirmation of every message between =
the MN and an AR.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; - Kulwinder.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Kulwinder Atwal =
&lt;kulwinder.atwal@zucotto.com&gt; on 01/16/2001 </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 05:46:42 PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent by:&nbsp; Kulwinder Atwal =
&lt;kulwinder.atwal@zucotto.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To:&nbsp;&nbsp; Phil Neumiller/MW/US/3Com, =
Seamoby@diameter.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; cc:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject:&nbsp; RE: [seamoby] micro, =
schmicro</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Um, actually what subnet you are on =
has an intimate </FONT>
<BR><FONT SIZE=3D2>&gt; relationship to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; what edge router you are using or =
what core router. The </FONT>
<BR><FONT SIZE=3D2>&gt; whole point</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; of having a router is to bridge two =
subnets, in subnet </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; based routing.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; James,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I understand this.&nbsp; However, it =
may be the case that useable</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; routes exist</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; between</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; an edge router pair that are unknown =
to the mobility agents</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; being used.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; If the routes are IP routes then the IP =
mobility agents will be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; aware of them, and will find the shortest =
path.&nbsp; Otherwise, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; there is an</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; error in the implementation.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; If the routes are L2 routes then this is =
an L2 issue.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Unless you are getting at something =
else.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C08097.7D96B660--


From owner-seamoby@diameter.org  Wed Jan 17 12:12:21 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22258
	for <seamoby-archive@odin.ietf.org>; Wed, 17 Jan 2001 12:12:20 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0HGAvx06418
	for seamoby-list; Wed, 17 Jan 2001 08:10:57 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0HGAtW06413
	for <seamoby@diameter.org>; Wed, 17 Jan 2001 08:10:55 -0800
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Wed, 17 Jan 2001 10:17:44 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <DCDS950Z>; Wed, 17 Jan 2001 10:14:00 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8B25@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Michael Thomas'" <mat@cisco.com>,
        Kulwinder Atwal <kulwinder.atwal@zucotto.com>
Cc: "'Phil_Neumiller@3com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
Subject: RE: [seamoby] micro, schmicro
Date: Wed, 17 Jan 2001 10:13:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C08098.18696AC0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C08098.18696AC0
Content-Type: text/plain;
	charset="iso-8859-1"

I agree with Michael.

And I would like to add an observation: it has been
suggested by someone that the FA belongs at the AP.
This would imply many things, not the least of which is
changes to the definition of what an FA does - assuming
the purpose of the FA being at the AP is to support
SeaMoby.

The alternative, which is what this discussion implicitly
includes, is a third mobility agent at the AP. This has
been somewhat hidden by referring to the SeaMoby
functions indirectly as AP functions.

Now we have at least 4 mobility agents: the HA, FA, AP
and at least one mobility functional entity within the link
layer.

Gary

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Tuesday, January 16, 2001 8:54 PM
> To: Kulwinder Atwal
> Cc: 'Phil_Neumiller@3com.com'; seamoby@diameter.org
> Subject: RE: [seamoby] micro, schmicro
> 
> 
> 
> I think you are misunderstanding Phil's point
> which I took to mean that the placement of the
> foreign agent is not necessarily the same as the
> placement of the AR. While I wonder whether that's
> an especially wise idea from the standpoint of
> needing to have a security relationship with both
> the AR (aka NAS) and the FA (for BU's, say), I
> think I probably disagree with your premise too.
> I don't think that we can or should make any
> assumption that the AR's will always know a priori
> about one another. I think it's useful in many
> cases to allow such topology knowledge to be used
> for network based moves, but this is not
> sufficient: it's a local optimization. The more
> general case where the old AR doesn't know squat
> about the new AR is also a perfectly valid case
> that needs to be accounted for.
> 
> 	   Mike
> 
> 
> Kulwinder Atwal writes:
>  > Making your diagram technology neutral:
>  >  
>  >   Big I			Big I
>  >    |                      |
>  >  (CR 3)------CRL1----- (CR 2)
>  >    |                      |
>  >  (OAR)-------ARL1-----  (NAR)
>  >    |                      |
>  >  (OAP)                  (NAP)
>  >    |
>  >   MN  --> handing over to ^> 
>  >  
>  > 
>  > CR = Core Router
>  > 
>  > AR = Access Router 
>  > 
>  > OAR = Old Access Router
>  > 
>  > NAR = New Access Router
>  > 
>  > I think your model in encouraging bad real-time network 
> design.  The ARs
>  > should have the functionality to resolve MN moves through 
> one link.  If ARs
>  > agree on one link for passing all MN handover related 
> messages in advance,
>  > this will cut down on the amount of messaging needed for a 
> handover as well.
>  > 
>  > 
>  > Either staticly, or dynamically the Access Routers 
> (OAR/NAR) need to agree
>  > on one single path for MN moves in advance of the move.  
> This path may even
>  > be set once by the Network Administor during network setup.
>  > 
>  > Further, placing the functionality required for the move 
> that many layers
>  > away from the MN will most likely not result in the 
> real-time behaviour we
>  > are looking for.
>  > 
>  > This is why I believe the better solution is to place the primary
>  > functionality for the move in the ARs nearest the MN.   
>  > 
>  > Unlike the general Internet, Real-Time network design must consider
>  > deterministic behaviour as a primary design objective.  
>  > 
>  > If the Network Designer wishes Real-Time behaviour to be a 
> primary design
>  > goal, then deterministic behaviour must be a primary 
> design objective. 
>  > 
>  > If we want Real-Time hand-overs then at least:
>  > 
>  >  - we must place Real-time bounds on "Routed Clouds"
>  >  - move decision making closer to the MN
>  >  - limit handover messaging to one pre-determined path
>  > 
>  > Also, since the problem space encompasses mobile wireless 
> we must provide
>  > positive confirmation of every message between the MN and an AR.
> 

------_=_NextPart_001_01C08098.18696AC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: [seamoby] micro, schmicro</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I agree with Michael.</FONT>
</P>

<P><FONT SIZE=3D2>And I would like to add an observation: it has =
been</FONT>
<BR><FONT SIZE=3D2>suggested by someone that the FA belongs at the =
AP.</FONT>
<BR><FONT SIZE=3D2>This would imply many things, not the least of which =
is</FONT>
<BR><FONT SIZE=3D2>changes to the definition of what an FA does - =
assuming</FONT>
<BR><FONT SIZE=3D2>the purpose of the FA being at the AP is to =
support</FONT>
<BR><FONT SIZE=3D2>SeaMoby.</FONT>
</P>

<P><FONT SIZE=3D2>The alternative, which is what this discussion =
implicitly</FONT>
<BR><FONT SIZE=3D2>includes, is a third mobility agent at the AP. This =
has</FONT>
<BR><FONT SIZE=3D2>been somewhat hidden by referring to the =
SeaMoby</FONT>
<BR><FONT SIZE=3D2>functions indirectly as AP functions.</FONT>
</P>

<P><FONT SIZE=3D2>Now we have at least 4 mobility agents: the HA, FA, =
AP</FONT>
<BR><FONT SIZE=3D2>and at least one mobility functional entity within =
the link</FONT>
<BR><FONT SIZE=3D2>layer.</FONT>
</P>

<P><FONT SIZE=3D2>Gary</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Michael Thomas [<A =
HREF=3D"mailto:mat@cisco.com">mailto:mat@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, January 16, 2001 8:54 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Kulwinder Atwal</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'Phil_Neumiller@3com.com'; =
seamoby@diameter.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [seamoby] micro, schmicro</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think you are misunderstanding Phil's =
point</FONT>
<BR><FONT SIZE=3D2>&gt; which I took to mean that the placement of =
the</FONT>
<BR><FONT SIZE=3D2>&gt; foreign agent is not necessarily the same as =
the</FONT>
<BR><FONT SIZE=3D2>&gt; placement of the AR. While I wonder whether =
that's</FONT>
<BR><FONT SIZE=3D2>&gt; an especially wise idea from the standpoint =
of</FONT>
<BR><FONT SIZE=3D2>&gt; needing to have a security relationship with =
both</FONT>
<BR><FONT SIZE=3D2>&gt; the AR (aka NAS) and the FA (for BU's, say), =
I</FONT>
<BR><FONT SIZE=3D2>&gt; think I probably disagree with your premise =
too.</FONT>
<BR><FONT SIZE=3D2>&gt; I don't think that we can or should make =
any</FONT>
<BR><FONT SIZE=3D2>&gt; assumption that the AR's will always know a =
priori</FONT>
<BR><FONT SIZE=3D2>&gt; about one another. I think it's useful in =
many</FONT>
<BR><FONT SIZE=3D2>&gt; cases to allow such topology knowledge to be =
used</FONT>
<BR><FONT SIZE=3D2>&gt; for network based moves, but this is not</FONT>
<BR><FONT SIZE=3D2>&gt; sufficient: it's a local optimization. The =
more</FONT>
<BR><FONT SIZE=3D2>&gt; general case where the old AR doesn't know =
squat</FONT>
<BR><FONT SIZE=3D2>&gt; about the new AR is also a perfectly valid =
case</FONT>
<BR><FONT SIZE=3D2>&gt; that needs to be accounted for.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; =
Mike</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Kulwinder Atwal writes:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; Making your diagram technology =
neutral:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp; Big I&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Big I</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp; (CR 3)------CRL1----- (CR =
2)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp; (OAR)-------ARL1-----&nbsp; =
(NAR)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp; =
(OAP)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (NAP)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp; MN&nbsp; --&gt; handing =
over to ^&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; CR =3D Core Router</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; AR =3D Access Router </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; OAR =3D Old Access Router</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; NAR =3D New Access Router</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; I think your model in encouraging =
bad real-time network </FONT>
<BR><FONT SIZE=3D2>&gt; design.&nbsp; The ARs</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; should have the functionality to =
resolve MN moves through </FONT>
<BR><FONT SIZE=3D2>&gt; one link.&nbsp; If ARs</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; agree on one link for passing all MN =
handover related </FONT>
<BR><FONT SIZE=3D2>&gt; messages in advance,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; this will cut down on the amount of =
messaging needed for a </FONT>
<BR><FONT SIZE=3D2>&gt; handover as well.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; Either staticly, or dynamically the =
Access Routers </FONT>
<BR><FONT SIZE=3D2>&gt; (OAR/NAR) need to agree</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; on one single path for MN moves in =
advance of the move.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; This path may even</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; be set once by the Network =
Administor during network setup.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; Further, placing the functionality =
required for the move </FONT>
<BR><FONT SIZE=3D2>&gt; that many layers</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; away from the MN will most likely =
not result in the </FONT>
<BR><FONT SIZE=3D2>&gt; real-time behaviour we</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; are looking for.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; This is why I believe the better =
solution is to place the primary</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; functionality for the move in the =
ARs nearest the MN.&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; Unlike the general Internet, =
Real-Time network design must consider</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; deterministic behaviour as a primary =
design objective.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; If the Network Designer wishes =
Real-Time behaviour to be a </FONT>
<BR><FONT SIZE=3D2>&gt; primary design</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; goal, then deterministic behaviour =
must be a primary </FONT>
<BR><FONT SIZE=3D2>&gt; design objective. </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; If we want Real-Time hand-overs then =
at least:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp; - we must place Real-time =
bounds on &quot;Routed Clouds&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp; - move decision making closer =
to the MN</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp; - limit handover messaging to =
one pre-determined path</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; Also, since the problem space =
encompasses mobile wireless </FONT>
<BR><FONT SIZE=3D2>&gt; we must provide</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; positive confirmation of every =
message between the MN and an AR.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C08098.18696AC0--


From owner-seamoby@diameter.org  Wed Jan 17 12:22:10 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22377
	for <seamoby-archive@odin.ietf.org>; Wed, 17 Jan 2001 12:22:09 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0HGqBu06454
	for seamoby-list; Wed, 17 Jan 2001 08:52:11 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0HGq8W06449
	for <seamoby@diameter.org>; Wed, 17 Jan 2001 08:52:08 -0800
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f0HFxI107015;
	Wed, 17 Jan 2001 07:59:18 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104])
	by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f0HG0M010206;
	Wed, 17 Jan 2001 08:00:22 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 882569D7.00581476 ; Wed, 17 Jan 2001 08:02:04 -0800
X-Lotus-FromDomain: 3COM
From: Phil_Neumiller@3Com.com
To: "Gary Kenward" <gkenward@nortelnetworks.com>
cc: seamoby@diameter.org
Message-ID: <882569D7.00581175.00@hqoutbound.ops.3com.com>
Date: Wed, 17 Jan 2001 10:07:35 -0600
Subject: RE: [seamoby] micro, schmicro
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=hZj01xcHIocyCQI3R4lrnOAwdPuS5cJwVgppDKLSqHs3Ap8aAw5Y6NzY"
Content-Disposition: inline
Sender: owner-seamoby@diameter.org
Precedence: bulk

--0__=hZj01xcHIocyCQI3R4lrnOAwdPuS5cJwVgppDKLSqHs3Ap8aAw5Y6NzY
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline







Sent by:  "Gary Kenward" <gkenward@nortelnetworks.com>


And I would like to add an observation: it has been
suggested by someone that the FA belongs at the AP.

pdn>This has been "formerly" suggested by the MIPv4 fast
pdn>handoff team in the form of drafts.

This would imply many things, not the least of which is
changes to the definition of what an FA does - assuming
the purpose of the FA being at the AP is to support
SeaMoby.

pdn>No, this was not the purpose.  Several of "us" on
pdn>the list believe there are many problems with an
pdn>FA chicken in every AP pot.

The alternative, which is what this discussion implicitly
includes, is a third mobility agent at the AP. This has
been somewhat hidden by referring to the SeaMoby
functions indirectly as AP functions.

pdn>Yeeas!  However, a peer-to-peer model is even NICER,
pdn>where a MN can be a Mobility agent (if it wants to
pdn>(IIWT), an AP can be an MA IIWT, an AR can be and MA
pdn>IIWT, etc.  This would be the most flexible.  Each MA
pdn>reflecting its own self interest while happily exchanging
pdn>context with a friendly neighborhood of MAs.  Can you
pdn>say moblity utopia?

Now we have at least 4 mobility agents: the HA, FA, AP
and at least one mobility functional entity within the link
layer.

pdn>You Nortel guys just can't shake the hierarchy can you...
pdn>(:-)) <<< - Real big sh*t eatin grin (sorry Gary).
pdn>Now we have a plethora of MAs all speaking CNP to each
pdn>other in Phil's utopian mobility enabled globe.

pdn>Try being flippant once and a while, it releases the
pdn>creative juices.  May be try being flipper since this
pdn>is SeaMoby.

Bye,

-pdn


--0__=hZj01xcHIocyCQI3R4lrnOAwdPuS5cJwVgppDKLSqHs3Ap8aAw5Y6NzY
Content-type: text/html; 
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U
PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1Mi4zNSI+DQo8VElUTEU+UkU6IFtz
ZWFtb2J5XSBtaWNybywgc2NobWljcm88L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+DQoNCjxQPjxG
T05UIFNJWkU9Mj5JIGFncmVlIHdpdGggTWljaGFlbC48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05U
IFNJWkU9Mj5BbmQgSSB3b3VsZCBsaWtlIHRvIGFkZCBhbiBvYnNlcnZhdGlvbjogaXQgaGFzIGJl
ZW48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnN1Z2dlc3RlZCBieSBzb21lb25lIHRoYXQgdGhl
IEZBIGJlbG9uZ3MgYXQgdGhlIEFQLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+VGhpcyB3b3Vs
ZCBpbXBseSBtYW55IHRoaW5ncywgbm90IHRoZSBsZWFzdCBvZiB3aGljaCBpczwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTI+Y2hhbmdlcyB0byB0aGUgZGVmaW5pdGlvbiBvZiB3aGF0IGFuIEZBIGRv
ZXMgLSBhc3N1bWluZzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhlIHB1cnBvc2Ugb2YgdGhl
IEZBIGJlaW5nIGF0IHRoZSBBUCBpcyB0byBzdXBwb3J0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj5TZWFNb2J5LjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPlRoZSBhbHRlcm5hdGl2
ZSwgd2hpY2ggaXMgd2hhdCB0aGlzIGRpc2N1c3Npb24gaW1wbGljaXRseTwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTI+aW5jbHVkZXMsIGlzIGEgdGhpcmQgbW9iaWxpdHkgYWdlbnQgYXQgdGhlIEFQ
LiBUaGlzIGhhczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+YmVlbiBzb21ld2hhdCBoaWRkZW4g
YnkgcmVmZXJyaW5nIHRvIHRoZSBTZWFNb2J5PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5mdW5j
dGlvbnMgaW5kaXJlY3RseSBhcyBBUCBmdW5jdGlvbnMuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9O
VCBTSVpFPTI+Tm93IHdlIGhhdmUgYXQgbGVhc3QgNCBtb2JpbGl0eSBhZ2VudHM6IHRoZSBIQSwg
RkEsIEFQPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5hbmQgYXQgbGVhc3Qgb25lIG1vYmlsaXR5
IGZ1bmN0aW9uYWwgZW50aXR5IHdpdGhpbiB0aGUgbGluazwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTI+bGF5ZXIuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+R2FyeTwvRk9OVD4NCjwv
UD4NCg0KPFA+PEZPTlQgU0laRT0yPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgRnJvbTogTWljaGFlbCBUaG9tYXMgWzxBIEhSRUY9
Im1haWx0bzptYXRAY2lzY28uY29tIj5tYWlsdG86bWF0QGNpc2NvLmNvbTwvQT5dPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTYsIDIwMDEgODo1
NCBQTTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBUbzogS3Vsd2luZGVyIEF0d2FsPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IENjOiAnUGhpbF9OZXVtaWxsZXJAM2NvbS5jb20n
OyBzZWFtb2J5QGRpYW1ldGVyLm9yZzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBTdWJq
ZWN0OiBSRTogW3NlYW1vYnldIG1pY3JvLCBzY2htaWNybzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBJIHRoaW5rIHlvdSBh
cmUgbWlzdW5kZXJzdGFuZGluZyBQaGlsJ3MgcG9pbnQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
PiZndDsgd2hpY2ggSSB0b29rIHRvIG1lYW4gdGhhdCB0aGUgcGxhY2VtZW50IG9mIHRoZTwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBmb3JlaWduIGFnZW50IGlzIG5vdCBuZWNlc3Nhcmls
eSB0aGUgc2FtZSBhcyB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgcGxhY2VtZW50
IG9mIHRoZSBBUi4gV2hpbGUgSSB3b25kZXIgd2hldGhlciB0aGF0J3M8L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yPiZndDsgYW4gZXNwZWNpYWxseSB3aXNlIGlkZWEgZnJvbSB0aGUgc3RhbmRwb2lu
dCBvZjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBuZWVkaW5nIHRvIGhhdmUgYSBzZWN1
cml0eSByZWxhdGlvbnNoaXAgd2l0aCBib3RoPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7
IHRoZSBBUiAoYWthIE5BUykgYW5kIHRoZSBGQSAoZm9yIEJVJ3MsIHNheSksIEk8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yPiZndDsgdGhpbmsgSSBwcm9iYWJseSBkaXNhZ3JlZSB3aXRoIHlvdXIg
cHJlbWlzZSB0b28uPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IEkgZG9uJ3QgdGhpbmsg
dGhhdCB3ZSBjYW4gb3Igc2hvdWxkIG1ha2UgYW55PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m
Z3Q7IGFzc3VtcHRpb24gdGhhdCB0aGUgQVIncyB3aWxsIGFsd2F5cyBrbm93IGEgcHJpb3JpPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGFib3V0IG9uZSBhbm90aGVyLiBJIHRoaW5rIGl0
J3MgdXNlZnVsIGluIG1hbnk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgY2FzZXMgdG8g
YWxsb3cgc3VjaCB0b3BvbG9neSBrbm93bGVkZ2UgdG8gYmUgdXNlZDwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTI+Jmd0OyBmb3IgbmV0d29yayBiYXNlZCBtb3ZlcywgYnV0IHRoaXMgaXMgbm90PC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHN1ZmZpY2llbnQ6IGl0J3MgYSBsb2NhbCBvcHRp
bWl6YXRpb24uIFRoZSBtb3JlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGdlbmVyYWwg
Y2FzZSB3aGVyZSB0aGUgb2xkIEFSIGRvZXNuJ3Qga25vdyBzcXVhdDwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTI+Jmd0OyBhYm91dCB0aGUgbmV3IEFSIGlzIGFsc28gYSBwZXJmZWN0bHkgdmFsaWQg
Y2FzZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyB0aGF0IG5lZWRzIHRvIGJlIGFjY291
bnRlZCBmb3IuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7
IE1pa2U8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBLdWx3aW5kZXIgQXR3YWwg
d3JpdGVzOjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyAmZ3Q7IE1ha2luZyB5
b3VyIGRpYWdyYW0gdGVjaG5vbG9neSBuZXV0cmFsOjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+
Jmd0OyZuYnNwOyAmZ3Q7Jm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNw
OyAmZ3Q7Jm5ic3A7Jm5ic3A7IEJpZyBJJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgQmlnIEk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsg
Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yPiZndDsmbmJzcDsgJmd0OyZuYnNwOyAoQ1IgMyktLS0tLS1DUkwxLS0tLS0gKENSIDIp
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsmbmJz
cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyB8PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7ICZn
dDsmbmJzcDsgKE9BUiktLS0tLS0tQVJMMS0tLS0tJm5ic3A7IChOQVIpPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyB8PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7ICZndDsmbmJzcDsgKE9BUCkm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKE5BUCk8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsgTU4mbmJz
cDsgLS0mZ3Q7IGhhbmRpbmcgb3ZlciB0byBeJmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
PiZndDsmbmJzcDsgJmd0OyZuYnNwOyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJz
cDsgJmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsgJmd0OyBDUiA9IENv
cmUgUm91dGVyPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7ICZndDsgPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7ICZndDsgQVIgPSBBY2Nlc3MgUm91dGVyIDwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyAmZ3Q7IDwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTI+Jmd0OyZuYnNwOyAmZ3Q7IE9BUiA9IE9sZCBBY2Nlc3MgUm91dGVyPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7ICZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj4mZ3Q7Jm5ic3A7ICZndDsgTkFSID0gTmV3IEFjY2VzcyBSb3V0ZXI8L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yPiZndDsmbmJzcDsgJmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsm
bmJzcDsgJmd0OyBJIHRoaW5rIHlvdXIgbW9kZWwgaW4gZW5jb3VyYWdpbmcgYmFkIHJlYWwtdGlt
ZSBuZXR3b3JrIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBkZXNpZ24uJm5ic3A7IFRo
ZSBBUnM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsgJmd0OyBzaG91bGQgaGF2
ZSB0aGUgZnVuY3Rpb25hbGl0eSB0byByZXNvbHZlIE1OIG1vdmVzIHRocm91Z2ggPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IG9uZSBsaW5rLiZuYnNwOyBJZiBBUnM8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yPiZndDsmbmJzcDsgJmd0OyBhZ3JlZSBvbiBvbmUgbGluayBmb3IgcGFzc2lu
ZyBhbGwgTU4gaGFuZG92ZXIgcmVsYXRlZCA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg
bWVzc2FnZXMgaW4gYWR2YW5jZSw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsg
Jmd0OyB0aGlzIHdpbGwgY3V0IGRvd24gb24gdGhlIGFtb3VudCBvZiBtZXNzYWdpbmcgbmVlZGVk
IGZvciBhIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBoYW5kb3ZlciBhcyB3ZWxsLjwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyAmZ3Q7IDwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTI+Jmd0OyZuYnNwOyAmZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZu
YnNwOyAmZ3Q7IEVpdGhlciBzdGF0aWNseSwgb3IgZHluYW1pY2FsbHkgdGhlIEFjY2VzcyBSb3V0
ZXJzIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAoT0FSL05BUikgbmVlZCB0byBhZ3Jl
ZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyAmZ3Q7IG9uIG9uZSBzaW5nbGUg
cGF0aCBmb3IgTU4gbW92ZXMgaW4gYWR2YW5jZSBvZiB0aGUgbW92ZS4mbmJzcDsgPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFRoaXMgcGF0aCBtYXkgZXZlbjwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTI+Jmd0OyZuYnNwOyAmZ3Q7IGJlIHNldCBvbmNlIGJ5IHRoZSBOZXR3b3JrIEFkbWlu
aXN0b3IgZHVyaW5nIG5ldHdvcmsgc2V0dXAuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7
Jm5ic3A7ICZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7ICZndDsgRnVy
dGhlciwgcGxhY2luZyB0aGUgZnVuY3Rpb25hbGl0eSByZXF1aXJlZCBmb3IgdGhlIG1vdmUgPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHRoYXQgbWFueSBsYXllcnM8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yPiZndDsmbmJzcDsgJmd0OyBhd2F5IGZyb20gdGhlIE1OIHdpbGwgbW9zdCBs
aWtlbHkgbm90IHJlc3VsdCBpbiB0aGUgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHJl
YWwtdGltZSBiZWhhdmlvdXIgd2U8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsg
Jmd0OyBhcmUgbG9va2luZyBmb3IuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7
ICZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7ICZndDsgVGhpcyBpcyB3
aHkgSSBiZWxpZXZlIHRoZSBiZXR0ZXIgc29sdXRpb24gaXMgdG8gcGxhY2UgdGhlIHByaW1hcnk8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsgJmd0OyBmdW5jdGlvbmFsaXR5IGZv
ciB0aGUgbW92ZSBpbiB0aGUgQVJzIG5lYXJlc3QgdGhlIE1OLiZuYnNwOyZuYnNwOyA8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsgJmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yPiZndDsmbmJzcDsgJmd0OyBVbmxpa2UgdGhlIGdlbmVyYWwgSW50ZXJuZXQsIFJlYWwtVGlt
ZSBuZXR3b3JrIGRlc2lnbiBtdXN0IGNvbnNpZGVyPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m
Z3Q7Jm5ic3A7ICZndDsgZGV0ZXJtaW5pc3RpYyBiZWhhdmlvdXIgYXMgYSBwcmltYXJ5IGRlc2ln
biBvYmplY3RpdmUuJm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyAm
Z3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyAmZ3Q7IElmIHRoZSBOZXR3
b3JrIERlc2lnbmVyIHdpc2hlcyBSZWFsLVRpbWUgYmVoYXZpb3VyIHRvIGJlIGEgPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHByaW1hcnkgZGVzaWduPC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9Mj4mZ3Q7Jm5ic3A7ICZndDsgZ29hbCwgdGhlbiBkZXRlcm1pbmlzdGljIGJlaGF2aW91ciBt
dXN0IGJlIGEgcHJpbWFyeSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgZGVzaWduIG9i
amVjdGl2ZS4gPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7ICZndDsgPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7ICZndDsgSWYgd2Ugd2FudCBSZWFsLVRpbWUg
aGFuZC1vdmVycyB0aGVuIGF0IGxlYXN0OjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZu
YnNwOyAmZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyAmZ3Q7Jm5ic3A7
IC0gd2UgbXVzdCBwbGFjZSBSZWFsLXRpbWUgYm91bmRzIG9uICZxdW90O1JvdXRlZCBDbG91ZHMm
cXVvdDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsgJmd0OyZuYnNwOyAtIG1v
dmUgZGVjaXNpb24gbWFraW5nIGNsb3NlciB0byB0aGUgTU48L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yPiZndDsmbmJzcDsgJmd0OyZuYnNwOyAtIGxpbWl0IGhhbmRvdmVyIG1lc3NhZ2luZyB0byBv
bmUgcHJlLWRldGVybWluZWQgcGF0aDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNw
OyAmZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyAmZ3Q7IEFsc28sIHNp
bmNlIHRoZSBwcm9ibGVtIHNwYWNlIGVuY29tcGFzc2VzIG1vYmlsZSB3aXJlbGVzcyA8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgd2UgbXVzdCBwcm92aWRlPC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9Mj4mZ3Q7Jm5ic3A7ICZndDsgcG9zaXRpdmUgY29uZmlybWF0aW9uIG9mIGV2ZXJ5IG1l
c3NhZ2UgYmV0d2VlbiB0aGUgTU4gYW5kIGFuIEFSLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+
Jmd0OyA8L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4NCg==

--0__=hZj01xcHIocyCQI3R4lrnOAwdPuS5cJwVgppDKLSqHs3Ap8aAw5Y6NzY--



From owner-seamoby@diameter.org  Wed Jan 17 13:24:03 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23530
	for <seamoby-archive@odin.ietf.org>; Wed, 17 Jan 2001 13:24:03 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0HH6Go06478
	for seamoby-list; Wed, 17 Jan 2001 09:06:16 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0HH6EW06473
	for <Seamoby@diameter.org>; Wed, 17 Jan 2001 09:06:14 -0800
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA19419
	for <Seamoby@diameter.org>; Wed, 17 Jan 2001 08:14:29 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f0HGEQo32023
	for <Seamoby@diameter.org>; Wed, 17 Jan 2001 08:14:26 -0800
X-Virus-Scanned:  Wed, 17 Jan 2001 08:14:26 -0800 Nokia Silicon Valley Email Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdw9IvDW; Wed, 17 Jan 2001 08:14:15 PST
Message-ID: <3A65C4DA.DBF7BC18@iprg.nokia.com>
Date: Wed, 17 Jan 2001 08:14:18 -0800
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Seamoby@diameter.org
Subject: Re: [seamoby] micro, schmicro
References: <6D1A8E7871B9D211B3B00008C7490AA50336F6E1@treis03nok> <4.1.20010117084455.040a81c0@flipper.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hello,

This note is a response to Dana (mainly) and to Phil.  I've
deleted individual names from the To: list, since I reckon
you'd get it from the main list...

>>  ==  Phil
>   ==  Dana

> At 07:39 AM 1/17/01 -0600, Phil Neumiller wrote:
>> whether this distinction is a useful one.  My feeling is that edge
>> versus core mobility is a far more important distinction than a change in
>> subnet.

The mobile node itself shouldn't have to know anything more
than whether a node is an access router (what I'd like to call
a default router) or some other serving agent.  I specifically
didn't say "mobility agent", because I agree that [seamoby]
should stay out of the routing area.  On the other hand, I
reckon that edge and core routers implementing a [seamboby-mm]
protocol will have to know more than the mobile node knows.

> Edge and Core are too abstract terms to discuss detailed mobility solutions.

Not necessarily!  Edge is pretty clear.  Core could be "not edge".
That would be pretty clear.  Plus, I didn't see anyone making confusion
about it yet on this mailing list.  The term "micromobility", on the
other hand, almost guarantees confusion.

If there were a hum to find a term to replace "micromobility",
I'd certainly join the noise.

> I think you need to define subnet more specifically.  For example, an ethernet
> is an IP subnet which is part of a larger IP subnet for a department which
> is part of a company IP subnet which is part of an ISP IP subnet which is
> part of the internet.  Which subnet boundary are you referencing ?

I've never seen this pointed out as a subnet ambiguity before!

The term "network" _MAY_ be considered ambiguous.  The term "subnet",
while technically subject to the ambiguity that you allude to, seems
never to have the problem in practice.  That would be especially true
in this case, since almost everyone seems to understand that "subnet"
refers to the part of the network where all the nodes are served by
the same default router.  In this case, it would/should probably be
"by the same access router".

> I tried to avoid the subnet ambiguity by saying there are some boundaries where
> the routable IP address assigned to the MN must change.  Then there are others
> where it does not change.  micromobility applies to those cases where the
> address does not change.

If the IP address doesn't change, then you'll end up installing
tunnels and host routes.  In the first place, that's a routing
problem.  In the second place, you'll very likely end up rediscovering
all the work done in [mobileip] for regional and hierarchical
mobility.  Alternatively, you could end up with something
with scalability problems, security problems, or very limited
applicability.  While scalability problems would not be
as important as usual, they will still translate into an
effective loss of capacity at the access routers.

While going through this process, it would be possible to make
a valuable contribution by studying and solving the QoS problems.


>> So, as I have stated in every design team message list, I hope we can
>> convince the list to abandon this terminology and recognize the real
>> problem which is edge versus core.  Complex behavior enabling seamless
>> mobility will be best implemented in edge devices of the global
>> Internet.
>> This is the ONLY way that it will scale globally.  As Tom Petty said,
>> "No, I won't back down.." on this one.

Stand up, Phil, and thanks.  Even if I'm the only other one,
I do appreciate that someone else is saying that the terminology
is bad/harmful.

> I don't think we disagree.  This design team is focussing on mobility solutions
> that can be implemented at the edge of an IP network where the IP address
> does not change.
> 
> Let's discuss on the call today.

I can't make the call, unfortunately, but I'll be interested to find
out how you can do that without messing with the route tables.

I left the main [seamoby] mailing list as the recipient
instead of restricting it to [seamoby-mm], since the issues
seem to be pretty fundamental -- but if others disagree I'll
happily restrict future messages.

Regards,
Charlie P.


From owner-seamoby@diameter.org  Wed Jan 17 14:21:03 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24574
	for <seamoby-archive@odin.ietf.org>; Wed, 17 Jan 2001 14:21:02 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0HHeZg06571
	for seamoby-list; Wed, 17 Jan 2001 09:40:35 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (flipper.cisco.com [171.69.25.141])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0HHeXW06566
	for <Seamoby@diameter.org>; Wed, 17 Jan 2001 09:40:33 -0800
Received: from dblair-pc (dhcp-atlanta-220-42.cisco.com [161.44.220.42])
	by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id IAA22507;
	Wed, 17 Jan 2001 08:48:47 -0800 (PST)
Message-Id: <4.1.20010117112239.04133c50@flipper.cisco.com>
X-Sender: dblair@flipper.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 17 Jan 2001 11:44:01 -0500
To: "Charles E. Perkins" <charliep@iprg.nokia.com>, Seamoby@diameter.org
From: "Dana L. Blair" <dblair@cisco.com>
Subject: Re: [seamoby] micro, schmicro
In-Reply-To: <3A65C4DA.DBF7BC18@iprg.nokia.com>
References: <6D1A8E7871B9D211B3B00008C7490AA50336F6E1@treis03nok>
 <4.1.20010117084455.040a81c0@flipper.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-seamoby@diameter.org
Precedence: bulk

At 08:14 AM 1/17/01 -0800, Charles E. Perkins wrote:
>
>Hello,
>
>This note is a response to Dana (mainly) and to Phil.  I've
>deleted individual names from the To: list, since I reckon
>you'd get it from the main list...
>
>>>  ==  Phil
>>   ==  Dana
>
>> At 07:39 AM 1/17/01 -0600, Phil Neumiller wrote:
>>> whether this distinction is a useful one.  My feeling is that edge
>>> versus core mobility is a far more important distinction than a change in
>>> subnet.
>
>The mobile node itself shouldn't have to know anything more
>than whether a node is an access router (what I'd like to call
>a default router) or some other serving agent.  I specifically
>didn't say "mobility agent", because I agree that [seamoby]
>should stay out of the routing area.  On the other hand, I
>reckon that edge and core routers implementing a [seamboby-mm]
>protocol will have to know more than the mobile node knows.
>
>> Edge and Core are too abstract terms to discuss detailed mobility solutions.
>
>Not necessarily!  Edge is pretty clear.  Core could be "not edge".
>That would be pretty clear.  Plus, I didn't see anyone making confusion
>about it yet on this mailing list.  The term "micromobility", on the
>other hand, almost guarantees confusion.
>
>If there were a hum to find a term to replace "micromobility",
>I'd certainly join the noise.
>
>> I think you need to define subnet more specifically.  For example, an 
>ethernet
>> is an IP subnet which is part of a larger IP subnet for a department which
>> is part of a company IP subnet which is part of an ISP IP subnet which is
>> part of the internet.  Which subnet boundary are you referencing ?
>
>I've never seen this pointed out as a subnet ambiguity before!
>
>The term "network" _MAY_ be considered ambiguous.  The term "subnet",
>while technically subject to the ambiguity that you allude to, seems
>never to have the problem in practice.  That would be especially true

I am glad you agree with the "technical" ambiguity of subnet.

>in this case, since almost everyone seems to understand that "subnet"
>refers to the part of the network where all the nodes are served by
>the same default router.  In this case, it would/should probably be
>"by the same access router".

Seems the subnet has several definitions:
1.  Yours above.
2.  All protocols below IP as defined in draft-ietf-pilc-link-design-04.txt.
3.  An IP network (subnetwork) that is part of a larger IP network
	designated by the prefix or netmask.  (what I was referencing).

>
>> I tried to avoid the subnet ambiguity by saying there are some boundaries 
>where
>> the routable IP address assigned to the MN must change.  Then there are 
>others
>> where it does not change.  micromobility applies to those cases where the
>> address does not change.
>
>If the IP address doesn't change, then you'll end up installing
>tunnels and host routes.  In the first place, that's a routing
>problem.  In the second place, you'll very likely end up rediscovering

Hopefully tunnels OR host routes and not both.  I agree that it is a routing
problem.

>all the work done in [mobileip] for regional and hierarchical
>mobility.  Alternatively, you could end up with something

You may be correct.  However, since all protocols except the
Mobile IP protocol have been out of scope for the Mobile IP
working group, then SEAMOBY is looking into it.  Why didn't you
object formally to the micromobility Design team creation if you
think it has no purpose or was in the wrong place ?  

>with scalability problems, security problems, or very limited
>applicability.  While scalability problems would not be
>as important as usual, they will still translate into an
>effective loss of capacity at the access routers.

That may be true.  But we might also come up with a good solution
too.

>
>While going through this process, it would be possible to make
>a valuable contribution by studying and solving the QoS problems.

I think consensus of our Design Team is that the QoS attributes of
potential new access links should be part of the handoff decision
process.

>
>
>>> So, as I have stated in every design team message list, I hope we can
>>> convince the list to abandon this terminology and recognize the real
>>> problem which is edge versus core.  Complex behavior enabling seamless
>>> mobility will be best implemented in edge devices of the global
>>> Internet.
>>> This is the ONLY way that it will scale globally.  As Tom Petty said,
>>> "No, I won't back down.." on this one.
>
>Stand up, Phil, and thanks.  Even if I'm the only other one,
>I do appreciate that someone else is saying that the terminology
>is bad/harmful.
>
>> I don't think we disagree.  This design team is focussing on mobility 
>solutions
>> that can be implemented at the edge of an IP network where the IP address
>> does not change.
>> 
>> Let's discuss on the call today.
>
>I can't make the call, unfortunately, but I'll be interested to find
>out how you can do that without messing with the route tables.

Who said we weren't going to change the routing tables ?  We are
just now defining the problem statement.  We will begin exploring
solutions which will probably fall into the following categories:
1.  Host Route Summarization/Desummarization
2.  Layer 2 tunneling
3.  Layer 3 tunnelling
4.  Multicasting

Hopefully, we can arrive at one solution.   Luca Salgarelli brought up the following idea
our conference call today and I agree with it. 

paraphrase from Luca:
 Mobility solutions that require tunnelling may impose unnecessary complexity where
mobility is only required within in a limited scope. 

My comment on Luca's comment:
An example of limited scope might be a single administrative domain with multiple
IP subnets and multiple access technologies.
Tunnel termination and QoS over tunnels may be more complex that 1 or 4 but that
remains to be worked out in the micromobility solution discussion.

thanks,
Dana

>
>I left the main [seamoby] mailing list as the recipient
>instead of restricting it to [seamoby-mm], since the issues
>seem to be pretty fundamental -- but if others disagree I'll
>happily restrict future messages.

Please restrict feature messages to micromobility  We can debate this on the
micromobility alias.  I have said these things before on that
alias.

thanks,
Dana

>
>Regards,
>Charlie P.



From owner-seamoby@diameter.org  Wed Jan 17 15:18:51 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25520
	for <seamoby-archive@odin.ietf.org>; Wed, 17 Jan 2001 15:18:50 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0HJWc406799
	for seamoby-list; Wed, 17 Jan 2001 11:32:38 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0HJWYW06788
	for <Seamoby@diameter.org>; Wed, 17 Jan 2001 11:32:34 -0800
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Wed, 17 Jan 2001 13:36:14 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <DCDS0DAB>; Wed, 17 Jan 2001 13:36:15 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8B26@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Phil Neumiller'" <neumiller@telocity.com>, jaakko.sundquist@nokia.com
Cc: Seamoby@diameter.org
Subject: RE: [seamoby] micro, schmicro
Date: Wed, 17 Jan 2001 13:36:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C080B4.5D3C37B0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C080B4.5D3C37B0
Content-Type: text/plain;
	charset="iso-8859-1"

Actually, I like the idea. Phil's proposal certainly encapsulates
more of what I envision Seamoby to be about then  any of the
other definitions.

Sorry Phil, please continue the mantra.

Gary

> -----Original Message-----
> From: Phil Neumiller [mailto:neumiller@telocity.com]
> Sent: Wednesday, January 17, 2001 8:40 AM
> To: jaakko.sundquist@nokia.com
> Cc: Seamoby@diameter.org
> Subject: Re: [seamoby] micro, schmicro
> 
> 
> jaakko.sundquist@nokia.com wrote:
> > 
> > Hi all,
> > 
> > I don't know, if this helps at all, but I thought I might 
> share some of my
> > (not too distant) earlier experiences in mobility work on 
> H.323 systems.
> > First of all, I have never seen a good definition for micro 
> and macro
> > mobility. Yet people use these as if they were clearly and similarly
> > understood by everyone. If you ask me, micro mobility in 
> the context of IP
> > networks is something that happens behind an access point 
> or a base station,
> > i.e. no change of the CoA is involved and thus there isn't 
> much (anything?)
> > that needs to be done in the IP layer. However, as I said, 
> I'm sure there
> > are other definitions for micro mobility as well.
> 
> You are correct.  This seems to be the running definition or 
> what I have
> called the "classic" definition of micro-mobility.  Now I have
> questioned
> whether this distinction is a useful one.  My feeling is that edge
> versus
> core mobility is a far more important distinction than a change in
> subnet.
> 
> Also, I believe edge mobility is active ALL the time, and 
> core mobility 
> (mobile IP) is active WHEN subnet boundaries change.  Also, I believe
> that edge mobility must compensate for the latency of adjustments in
> core
> routing updates made by mobile IP.
> 
> So, as I have stated in every design team message list, I hope we can 
> convince the list to abandon this terminology and recognize the real 
> problem which is edge versus core.  Complex behavior enabling seamless
> mobility will be best implemented in edge devices of the global
> Internet.
> This is the ONLY way that it will scale globally.  As Tom Petty said,
> "No, I won't back down.." on this one.
> 
> > What we did in the H.323 Mobility work was not to use these 
> terms, but
> > instead refer to the scope of the mobility in terms that 
> were already
> > defined for H.323. Thus we ended up talking about 
> intra-zone, inter-zone,
> > intra-domain and inter-domain mobility. In a similar 
> manner, I would imagine
> > that terms, such as "intra/inter-link mobility", "intra/inter-subnet
> > mobility", "intra/inter domain mobility" or something 
> similar could be used
> > with regards to Mobile IP and Seamoby. An alternative for 
> this would, of
> > course, be to define unambigiously the terms "micro 
> mobility" and "macro
> > mobility", but since these are already in use and mean 
> various different
> > things depending on the context, I would imagine that the 
> use of them would
> > lead to misunderstandings.
> > 
> Here I would prefer we use the terminology of edge versus 
> core mobility.
> Can somebody shoot me down so I can get off this mantra??? :-)
> 
> TNX,
> 
> Phil (N9FCW, PSK/QPSK mbox = 10.140.700 MHz)
> 

------_=_NextPart_001_01C080B4.5D3C37B0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] micro, schmicro</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Actually, I like the idea. Phil's proposal certainly encapsulates</FONT>
<BR><FONT SIZE=2>more of what I envision Seamoby to be about then&nbsp; any of the</FONT>
<BR><FONT SIZE=2>other definitions.</FONT>
</P>

<P><FONT SIZE=2>Sorry Phil, please continue the mantra.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Phil Neumiller [<A HREF="mailto:neumiller@telocity.com">mailto:neumiller@telocity.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, January 17, 2001 8:40 AM</FONT>
<BR><FONT SIZE=2>&gt; To: jaakko.sundquist@nokia.com</FONT>
<BR><FONT SIZE=2>&gt; Cc: Seamoby@diameter.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: [seamoby] micro, schmicro</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; jaakko.sundquist@nokia.com wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Hi all,</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; I don't know, if this helps at all, but I thought I might </FONT>
<BR><FONT SIZE=2>&gt; share some of my</FONT>
<BR><FONT SIZE=2>&gt; &gt; (not too distant) earlier experiences in mobility work on </FONT>
<BR><FONT SIZE=2>&gt; H.323 systems.</FONT>
<BR><FONT SIZE=2>&gt; &gt; First of all, I have never seen a good definition for micro </FONT>
<BR><FONT SIZE=2>&gt; and macro</FONT>
<BR><FONT SIZE=2>&gt; &gt; mobility. Yet people use these as if they were clearly and similarly</FONT>
<BR><FONT SIZE=2>&gt; &gt; understood by everyone. If you ask me, micro mobility in </FONT>
<BR><FONT SIZE=2>&gt; the context of IP</FONT>
<BR><FONT SIZE=2>&gt; &gt; networks is something that happens behind an access point </FONT>
<BR><FONT SIZE=2>&gt; or a base station,</FONT>
<BR><FONT SIZE=2>&gt; &gt; i.e. no change of the CoA is involved and thus there isn't </FONT>
<BR><FONT SIZE=2>&gt; much (anything?)</FONT>
<BR><FONT SIZE=2>&gt; &gt; that needs to be done in the IP layer. However, as I said, </FONT>
<BR><FONT SIZE=2>&gt; I'm sure there</FONT>
<BR><FONT SIZE=2>&gt; &gt; are other definitions for micro mobility as well.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; You are correct.&nbsp; This seems to be the running definition or </FONT>
<BR><FONT SIZE=2>&gt; what I have</FONT>
<BR><FONT SIZE=2>&gt; called the &quot;classic&quot; definition of micro-mobility.&nbsp; Now I have</FONT>
<BR><FONT SIZE=2>&gt; questioned</FONT>
<BR><FONT SIZE=2>&gt; whether this distinction is a useful one.&nbsp; My feeling is that edge</FONT>
<BR><FONT SIZE=2>&gt; versus</FONT>
<BR><FONT SIZE=2>&gt; core mobility is a far more important distinction than a change in</FONT>
<BR><FONT SIZE=2>&gt; subnet.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Also, I believe edge mobility is active ALL the time, and </FONT>
<BR><FONT SIZE=2>&gt; core mobility </FONT>
<BR><FONT SIZE=2>&gt; (mobile IP) is active WHEN subnet boundaries change.&nbsp; Also, I believe</FONT>
<BR><FONT SIZE=2>&gt; that edge mobility must compensate for the latency of adjustments in</FONT>
<BR><FONT SIZE=2>&gt; core</FONT>
<BR><FONT SIZE=2>&gt; routing updates made by mobile IP.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; So, as I have stated in every design team message list, I hope we can </FONT>
<BR><FONT SIZE=2>&gt; convince the list to abandon this terminology and recognize the real </FONT>
<BR><FONT SIZE=2>&gt; problem which is edge versus core.&nbsp; Complex behavior enabling seamless</FONT>
<BR><FONT SIZE=2>&gt; mobility will be best implemented in edge devices of the global</FONT>
<BR><FONT SIZE=2>&gt; Internet.</FONT>
<BR><FONT SIZE=2>&gt; This is the ONLY way that it will scale globally.&nbsp; As Tom Petty said,</FONT>
<BR><FONT SIZE=2>&gt; &quot;No, I won't back down..&quot; on this one.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; What we did in the H.323 Mobility work was not to use these </FONT>
<BR><FONT SIZE=2>&gt; terms, but</FONT>
<BR><FONT SIZE=2>&gt; &gt; instead refer to the scope of the mobility in terms that </FONT>
<BR><FONT SIZE=2>&gt; were already</FONT>
<BR><FONT SIZE=2>&gt; &gt; defined for H.323. Thus we ended up talking about </FONT>
<BR><FONT SIZE=2>&gt; intra-zone, inter-zone,</FONT>
<BR><FONT SIZE=2>&gt; &gt; intra-domain and inter-domain mobility. In a similar </FONT>
<BR><FONT SIZE=2>&gt; manner, I would imagine</FONT>
<BR><FONT SIZE=2>&gt; &gt; that terms, such as &quot;intra/inter-link mobility&quot;, &quot;intra/inter-subnet</FONT>
<BR><FONT SIZE=2>&gt; &gt; mobility&quot;, &quot;intra/inter domain mobility&quot; or something </FONT>
<BR><FONT SIZE=2>&gt; similar could be used</FONT>
<BR><FONT SIZE=2>&gt; &gt; with regards to Mobile IP and Seamoby. An alternative for </FONT>
<BR><FONT SIZE=2>&gt; this would, of</FONT>
<BR><FONT SIZE=2>&gt; &gt; course, be to define unambigiously the terms &quot;micro </FONT>
<BR><FONT SIZE=2>&gt; mobility&quot; and &quot;macro</FONT>
<BR><FONT SIZE=2>&gt; &gt; mobility&quot;, but since these are already in use and mean </FONT>
<BR><FONT SIZE=2>&gt; various different</FONT>
<BR><FONT SIZE=2>&gt; &gt; things depending on the context, I would imagine that the </FONT>
<BR><FONT SIZE=2>&gt; use of them would</FONT>
<BR><FONT SIZE=2>&gt; &gt; lead to misunderstandings.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; Here I would prefer we use the terminology of edge versus </FONT>
<BR><FONT SIZE=2>&gt; core mobility.</FONT>
<BR><FONT SIZE=2>&gt; Can somebody shoot me down so I can get off this mantra??? :-)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; TNX,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Phil (N9FCW, PSK/QPSK mbox = 10.140.700 MHz)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C080B4.5D3C37B0--


From owner-seamoby@diameter.org  Wed Jan 17 15:44:57 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25899
	for <seamoby-archive@odin.ietf.org>; Wed, 17 Jan 2001 15:44:56 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0HJWll06800
	for seamoby-list; Wed, 17 Jan 2001 11:32:47 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0HJWYW06789
	for <Seamoby@diameter.org>; Wed, 17 Jan 2001 11:32:35 -0800
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Wed, 17 Jan 2001 13:38:53 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <DCDS0DDQ>; Wed, 17 Jan 2001 13:38:54 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8B27@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Dana L. Blair'" <dblair@cisco.com>,
        Phil Neumiller <neumiller@telocity.com>, jaakko.sundquist@nokia.com
Cc: Seamoby@diameter.org, seamoby-mm@cdma-2000.org
Subject: RE: [seamoby] micro, schmicro
Date: Wed, 17 Jan 2001 13:38:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C080B4.BA6EB520"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C080B4.BA6EB520
Content-Type: text/plain;
	charset="iso-8859-1"

Dana:

   You do not seem to have a concrete objection to "edge
mobility". I tend to agree concerning "core mobility", although
there is already a problem with the difference in denotation
between the Internet use of "core" versus the cellular use of 
"core".

   What not be clear and use "MIP" and "edge mobility"?

Gary

> -----Original Message-----
> From: Dana L. Blair [mailto:dblair@cisco.com]
> Sent: Wednesday, January 17, 2001 8:54 AM
> To: Phil Neumiller; jaakko.sundquist@nokia.com
> Cc: Seamoby@diameter.org; seamoby-mm@cdma-2000.org
> Subject: Re: [seamoby] micro, schmicro
> 
> 
> Let's take this discussion back to the micro-mobility alias, 
> since it is a mobility
> discussion.
> 
> At 07:39 AM 1/17/01 -0600, Phil Neumiller wrote:
> >jaakko.sundquist@nokia.com wrote:
> >> 
> >> Hi all,
> >> 
> >> I don't know, if this helps at all, but I thought I might 
> share some of my
> >> (not too distant) earlier experiences in mobility work on 
> H.323 systems.
> >> First of all, I have never seen a good definition for 
> micro and macro
> >> mobility. Yet people use these as if they were clearly and 
> similarly
> >> understood by everyone. If you ask me, micro mobility in 
> the context of IP
> >> networks is something that happens behind an access point 
> or a base station,
> >> i.e. no change of the CoA is involved and thus there isn't 
> much (anything?)
> >> that needs to be done in the IP layer. However, as I said, 
> I'm sure there
> >> are other definitions for micro mobility as well.
> >
> >You are correct.  This seems to be the running definition or 
> what I have
> >called the "classic" definition of micro-mobility.  Now I have
> >questioned
> >whether this distinction is a useful one.  My feeling is that edge
> >versus
> >core mobility is a far more important distinction than a change in
> >subnet.
> 
> Edge and Core are too abstract terms to discuss detailed 
> mobility solutions.
> Cellular folks use the term Core to reference an MSC, HLR, 
> other other systems.
> IP folks use the term Core to referece a high speed backbone 
> IP network.
> Since we are within the IP context let's use specific IP 
> terms.  That is
> why I defined micro-mobility in terms of IP addressing an 
> Access Links.
> 
> >
> >Also, I believe edge mobility is active ALL the time, and 
> core mobility 
> >(mobile IP) is active WHEN subnet boundaries change.  Also, I believe
> 
> I think you need to define subnet more specifically.  For 
> example, an ethernet
> is an IP subnet which is part of a larger IP subnet for a 
> department which
> is part of a company IP subnet which is part of an ISP IP 
> subnet which is
> part of the internet.  Which subnet boundary are you referencing ?
> 
> I tried to avoid the subnet ambiguity by saying there are 
> some boundaries where
> the routable IP address assigned to the MN must change.  Then 
> there are others
> where it does not change.  micromobility applies to those 
> cases where the
> address does not change.
> 
> >that edge mobility must compensate for the latency of adjustments in
> >core
> >routing updates made by mobile IP.
> >
> >So, as I have stated in every design team message list, I 
> hope we can 
> >convince the list to abandon this terminology and recognize the real 
> >problem which is edge versus core.  Complex behavior 
> enabling seamless
> >mobility will be best implemented in edge devices of the global
> >Internet.
> >This is the ONLY way that it will scale globally.  As Tom Petty said,
> >"No, I won't back down.." on this one.
> 
> I don't think we disagree.  This design team is focussing on 
> mobility solutions
> that can be implemented at the edge of an IP network where 
> the IP address
> does not change.
> 
> Let's discuss on the call today.
> 
> thanks,
> Dana
> 
> >
> >> What we did in the H.323 Mobility work was not to use 
> these terms, but
> >> instead refer to the scope of the mobility in terms that 
> were already
> >> defined for H.323. Thus we ended up talking about 
> intra-zone, inter-zone,
> >> intra-domain and inter-domain mobility. In a similar 
> manner, I would imagine
> >> that terms, such as "intra/inter-link mobility", 
> "intra/inter-subnet
> >> mobility", "intra/inter domain mobility" or something 
> similar could be used
> >> with regards to Mobile IP and Seamoby. An alternative for 
> this would, of
> >> course, be to define unambigiously the terms "micro 
> mobility" and "macro
> >> mobility", but since these are already in use and mean 
> various different
> >> things depending on the context, I would imagine that the 
> use of them would
> >> lead to misunderstandings.
> >> 
> >Here I would prefer we use the terminology of edge versus 
> core mobility.
> >Can somebody shoot me down so I can get off this mantra??? :-)
> >
> >TNX,
> >
> >Phil (N9FCW, PSK/QPSK mbox = 10.140.700 MHz)
> 
> 

------_=_NextPart_001_01C080B4.BA6EB520
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] micro, schmicro</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Dana:</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; You do not seem to have a concrete objection to &quot;edge</FONT>
<BR><FONT SIZE=2>mobility&quot;. I tend to agree concerning &quot;core mobility&quot;, although</FONT>
<BR><FONT SIZE=2>there is already a problem with the difference in denotation</FONT>
<BR><FONT SIZE=2>between the Internet use of &quot;core&quot; versus the cellular use of </FONT>
<BR><FONT SIZE=2>&quot;core&quot;.</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; What not be clear and use &quot;MIP&quot; and &quot;edge mobility&quot;?</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Dana L. Blair [<A HREF="mailto:dblair@cisco.com">mailto:dblair@cisco.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, January 17, 2001 8:54 AM</FONT>
<BR><FONT SIZE=2>&gt; To: Phil Neumiller; jaakko.sundquist@nokia.com</FONT>
<BR><FONT SIZE=2>&gt; Cc: Seamoby@diameter.org; seamoby-mm@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: [seamoby] micro, schmicro</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Let's take this discussion back to the micro-mobility alias, </FONT>
<BR><FONT SIZE=2>&gt; since it is a mobility</FONT>
<BR><FONT SIZE=2>&gt; discussion.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; At 07:39 AM 1/17/01 -0600, Phil Neumiller wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt;jaakko.sundquist@nokia.com wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; Hi all,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; I don't know, if this helps at all, but I thought I might </FONT>
<BR><FONT SIZE=2>&gt; share some of my</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; (not too distant) earlier experiences in mobility work on </FONT>
<BR><FONT SIZE=2>&gt; H.323 systems.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; First of all, I have never seen a good definition for </FONT>
<BR><FONT SIZE=2>&gt; micro and macro</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; mobility. Yet people use these as if they were clearly and </FONT>
<BR><FONT SIZE=2>&gt; similarly</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; understood by everyone. If you ask me, micro mobility in </FONT>
<BR><FONT SIZE=2>&gt; the context of IP</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; networks is something that happens behind an access point </FONT>
<BR><FONT SIZE=2>&gt; or a base station,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; i.e. no change of the CoA is involved and thus there isn't </FONT>
<BR><FONT SIZE=2>&gt; much (anything?)</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; that needs to be done in the IP layer. However, as I said, </FONT>
<BR><FONT SIZE=2>&gt; I'm sure there</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; are other definitions for micro mobility as well.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;You are correct.&nbsp; This seems to be the running definition or </FONT>
<BR><FONT SIZE=2>&gt; what I have</FONT>
<BR><FONT SIZE=2>&gt; &gt;called the &quot;classic&quot; definition of micro-mobility.&nbsp; Now I have</FONT>
<BR><FONT SIZE=2>&gt; &gt;questioned</FONT>
<BR><FONT SIZE=2>&gt; &gt;whether this distinction is a useful one.&nbsp; My feeling is that edge</FONT>
<BR><FONT SIZE=2>&gt; &gt;versus</FONT>
<BR><FONT SIZE=2>&gt; &gt;core mobility is a far more important distinction than a change in</FONT>
<BR><FONT SIZE=2>&gt; &gt;subnet.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Edge and Core are too abstract terms to discuss detailed </FONT>
<BR><FONT SIZE=2>&gt; mobility solutions.</FONT>
<BR><FONT SIZE=2>&gt; Cellular folks use the term Core to reference an MSC, HLR, </FONT>
<BR><FONT SIZE=2>&gt; other other systems.</FONT>
<BR><FONT SIZE=2>&gt; IP folks use the term Core to referece a high speed backbone </FONT>
<BR><FONT SIZE=2>&gt; IP network.</FONT>
<BR><FONT SIZE=2>&gt; Since we are within the IP context let's use specific IP </FONT>
<BR><FONT SIZE=2>&gt; terms.&nbsp; That is</FONT>
<BR><FONT SIZE=2>&gt; why I defined micro-mobility in terms of IP addressing an </FONT>
<BR><FONT SIZE=2>&gt; Access Links.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;Also, I believe edge mobility is active ALL the time, and </FONT>
<BR><FONT SIZE=2>&gt; core mobility </FONT>
<BR><FONT SIZE=2>&gt; &gt;(mobile IP) is active WHEN subnet boundaries change.&nbsp; Also, I believe</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I think you need to define subnet more specifically.&nbsp; For </FONT>
<BR><FONT SIZE=2>&gt; example, an ethernet</FONT>
<BR><FONT SIZE=2>&gt; is an IP subnet which is part of a larger IP subnet for a </FONT>
<BR><FONT SIZE=2>&gt; department which</FONT>
<BR><FONT SIZE=2>&gt; is part of a company IP subnet which is part of an ISP IP </FONT>
<BR><FONT SIZE=2>&gt; subnet which is</FONT>
<BR><FONT SIZE=2>&gt; part of the internet.&nbsp; Which subnet boundary are you referencing ?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I tried to avoid the subnet ambiguity by saying there are </FONT>
<BR><FONT SIZE=2>&gt; some boundaries where</FONT>
<BR><FONT SIZE=2>&gt; the routable IP address assigned to the MN must change.&nbsp; Then </FONT>
<BR><FONT SIZE=2>&gt; there are others</FONT>
<BR><FONT SIZE=2>&gt; where it does not change.&nbsp; micromobility applies to those </FONT>
<BR><FONT SIZE=2>&gt; cases where the</FONT>
<BR><FONT SIZE=2>&gt; address does not change.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;that edge mobility must compensate for the latency of adjustments in</FONT>
<BR><FONT SIZE=2>&gt; &gt;core</FONT>
<BR><FONT SIZE=2>&gt; &gt;routing updates made by mobile IP.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;So, as I have stated in every design team message list, I </FONT>
<BR><FONT SIZE=2>&gt; hope we can </FONT>
<BR><FONT SIZE=2>&gt; &gt;convince the list to abandon this terminology and recognize the real </FONT>
<BR><FONT SIZE=2>&gt; &gt;problem which is edge versus core.&nbsp; Complex behavior </FONT>
<BR><FONT SIZE=2>&gt; enabling seamless</FONT>
<BR><FONT SIZE=2>&gt; &gt;mobility will be best implemented in edge devices of the global</FONT>
<BR><FONT SIZE=2>&gt; &gt;Internet.</FONT>
<BR><FONT SIZE=2>&gt; &gt;This is the ONLY way that it will scale globally.&nbsp; As Tom Petty said,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&quot;No, I won't back down..&quot; on this one.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I don't think we disagree.&nbsp; This design team is focussing on </FONT>
<BR><FONT SIZE=2>&gt; mobility solutions</FONT>
<BR><FONT SIZE=2>&gt; that can be implemented at the edge of an IP network where </FONT>
<BR><FONT SIZE=2>&gt; the IP address</FONT>
<BR><FONT SIZE=2>&gt; does not change.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Let's discuss on the call today.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; thanks,</FONT>
<BR><FONT SIZE=2>&gt; Dana</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; What we did in the H.323 Mobility work was not to use </FONT>
<BR><FONT SIZE=2>&gt; these terms, but</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; instead refer to the scope of the mobility in terms that </FONT>
<BR><FONT SIZE=2>&gt; were already</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; defined for H.323. Thus we ended up talking about </FONT>
<BR><FONT SIZE=2>&gt; intra-zone, inter-zone,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; intra-domain and inter-domain mobility. In a similar </FONT>
<BR><FONT SIZE=2>&gt; manner, I would imagine</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; that terms, such as &quot;intra/inter-link mobility&quot;, </FONT>
<BR><FONT SIZE=2>&gt; &quot;intra/inter-subnet</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; mobility&quot;, &quot;intra/inter domain mobility&quot; or something </FONT>
<BR><FONT SIZE=2>&gt; similar could be used</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; with regards to Mobile IP and Seamoby. An alternative for </FONT>
<BR><FONT SIZE=2>&gt; this would, of</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; course, be to define unambigiously the terms &quot;micro </FONT>
<BR><FONT SIZE=2>&gt; mobility&quot; and &quot;macro</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; mobility&quot;, but since these are already in use and mean </FONT>
<BR><FONT SIZE=2>&gt; various different</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; things depending on the context, I would imagine that the </FONT>
<BR><FONT SIZE=2>&gt; use of them would</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; lead to misunderstandings.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;Here I would prefer we use the terminology of edge versus </FONT>
<BR><FONT SIZE=2>&gt; core mobility.</FONT>
<BR><FONT SIZE=2>&gt; &gt;Can somebody shoot me down so I can get off this mantra??? :-)</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;TNX,</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;Phil (N9FCW, PSK/QPSK mbox = 10.140.700 MHz)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C080B4.BA6EB520--


From owner-seamoby@diameter.org  Wed Jan 17 16:14:46 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26224
	for <seamoby-archive@odin.ietf.org>; Wed, 17 Jan 2001 16:14:45 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0HKi3406974
	for seamoby-list; Wed, 17 Jan 2001 12:44:03 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0HKhvW06969
	for <seamoby@diameter.org>; Wed, 17 Jan 2001 12:44:01 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 17 Jan 2001 14:23:28 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <D1PR9FCQ>; Wed, 17 Jan 2001 14:20:50 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8B33@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Phil_Neumiller@3com.com'" <Phil_Neumiller@3Com.com>
Cc: seamoby@diameter.org
Subject: RE: [seamoby] micro, schmicro
Date: Wed, 17 Jan 2001 14:20:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C080BA.947E4730"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C080BA.947E4730
Content-Type: text/plain;
	charset="iso-8859-1"

> -----Original Message-----
> From: Phil_Neumiller@3com.com [mailto:Phil_Neumiller@3com.com]
> Sent: Wednesday, January 17, 2001 11:08 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@diameter.org
> Subject: RE: [seamoby] micro, schmicro
> 
> 
> Sent by:  "Gary Kenward" <gkenward@nortelnetworks.com>
> 
> 
> And I would like to add an observation: it has been
> suggested by someone that the FA belongs at the AP.
> 
> pdn>This has been "formerly" suggested by the MIPv4 fast
> pdn>handoff team in the form of drafts.
> 
> This would imply many things, not the least of which is
> changes to the definition of what an FA does - assuming
> the purpose of the FA being at the AP is to support
> SeaMoby.
> 
> pdn>No, this was not the purpose.  Several of "us" on
> pdn>the list believe there are many problems with an
> pdn>FA chicken in every AP pot.

I didn't say I supported the proposal, I was simply echoing
the distilled version.

> 
> The alternative, which is what this discussion implicitly
> includes, is a third mobility agent at the AP. This has
> been somewhat hidden by referring to the SeaMoby
> functions indirectly as AP functions.
> 
> pdn>Yeeas!  However, a peer-to-peer model is even NICER,
> pdn>where a MN can be a Mobility agent (if it wants to
> pdn>(IIWT), an AP can be an MA IIWT, an AR can be and MA
> pdn>IIWT, etc.  This would be the most flexible.  Each MA
> pdn>reflecting its own self interest while happily exchanging
> pdn>context with a friendly neighborhood of MAs.  Can you
> pdn>say moblity utopia?

The old Mobile Data International packet data system used
mobile control handover. Worked extremely well, except that
10 - 20% of the bandwidth could easily be consumed by the
handover signalling (yeah, I know Phil, bandwidth isn't really 
scarce). And there wasn't much pretense of security.

> 
> Now we have at least 4 mobility agents: the HA, FA, AP
> and at least one mobility functional entity within the link
> layer.
> 
> pdn>You Nortel guys just can't shake the hierarchy can you...
> pdn>(:-)) <<< - Real big sh*t eatin grin (sorry Gary).
> pdn>Now we have a plethora of MAs all speaking CNP to each
> pdn>other in Phil's utopian mobility enabled globe.

Excuuuuuuse me! I didn't create the hierarchy. The MIP people
did. Indeed, I think I missed a level of MIP hierarch, FH/HMIP,
which has introduced yet another mobility agent: the GFA.
Frankly, I actually believe that you only need one mobility
solution (and that doesn't mean MIP nor soft handoff). However, I 
do believe that for scalability reasons, there are local and global
components.

> 
> pdn>Try being flippant once and a while, it releases the
> pdn>creative juices.  May be try being flipper since this
> pdn>is SeaMoby.

Don't get me started, the outside world may not be ready for Gary
Kenward's flippancy...

But, since you ask, I was originally going to propose that we use the
term "C-mobility" instead of "micromobility".

> 
> Bye,
> 
> -pdn

A bientot.
Gary

------_=_NextPart_001_01C080BA.947E4730
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] micro, schmicro</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Phil_Neumiller@3com.com [<A HREF="mailto:Phil_Neumiller@3com.com">mailto:Phil_Neumiller@3com.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, January 17, 2001 11:08 AM</FONT>
<BR><FONT SIZE=2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Cc: seamoby@diameter.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [seamoby] micro, schmicro</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Sent by:&nbsp; &quot;Gary Kenward&quot; &lt;gkenward@nortelnetworks.com&gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; And I would like to add an observation: it has been</FONT>
<BR><FONT SIZE=2>&gt; suggested by someone that the FA belongs at the AP.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;This has been &quot;formerly&quot; suggested by the MIPv4 fast</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;handoff team in the form of drafts.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; This would imply many things, not the least of which is</FONT>
<BR><FONT SIZE=2>&gt; changes to the definition of what an FA does - assuming</FONT>
<BR><FONT SIZE=2>&gt; the purpose of the FA being at the AP is to support</FONT>
<BR><FONT SIZE=2>&gt; SeaMoby.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;No, this was not the purpose.&nbsp; Several of &quot;us&quot; on</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;the list believe there are many problems with an</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;FA chicken in every AP pot.</FONT>
</P>

<P><FONT SIZE=2>I didn't say I supported the proposal, I was simply echoing</FONT>
<BR><FONT SIZE=2>the distilled version.</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The alternative, which is what this discussion implicitly</FONT>
<BR><FONT SIZE=2>&gt; includes, is a third mobility agent at the AP. This has</FONT>
<BR><FONT SIZE=2>&gt; been somewhat hidden by referring to the SeaMoby</FONT>
<BR><FONT SIZE=2>&gt; functions indirectly as AP functions.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;Yeeas!&nbsp; However, a peer-to-peer model is even NICER,</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;where a MN can be a Mobility agent (if it wants to</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;(IIWT), an AP can be an MA IIWT, an AR can be and MA</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;IIWT, etc.&nbsp; This would be the most flexible.&nbsp; Each MA</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;reflecting its own self interest while happily exchanging</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;context with a friendly neighborhood of MAs.&nbsp; Can you</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;say moblity utopia?</FONT>
</P>

<P><FONT SIZE=2>The old Mobile Data International packet data system used</FONT>
<BR><FONT SIZE=2>mobile control handover. Worked extremely well, except that</FONT>
<BR><FONT SIZE=2>10 - 20% of the bandwidth could easily be consumed by the</FONT>
<BR><FONT SIZE=2>handover signalling (yeah, I know Phil, bandwidth isn't really </FONT>
<BR><FONT SIZE=2>scarce). And there wasn't much pretense of security.</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Now we have at least 4 mobility agents: the HA, FA, AP</FONT>
<BR><FONT SIZE=2>&gt; and at least one mobility functional entity within the link</FONT>
<BR><FONT SIZE=2>&gt; layer.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;You Nortel guys just can't shake the hierarchy can you...</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;(:-)) &lt;&lt;&lt; - Real big sh*t eatin grin (sorry Gary).</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;Now we have a plethora of MAs all speaking CNP to each</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;other in Phil's utopian mobility enabled globe.</FONT>
</P>

<P><FONT SIZE=2>Excuuuuuuse me! I didn't create the hierarchy. The MIP people</FONT>
<BR><FONT SIZE=2>did. Indeed, I think I missed a level of MIP hierarch, FH/HMIP,</FONT>
<BR><FONT SIZE=2>which has introduced yet another mobility agent: the GFA.</FONT>
<BR><FONT SIZE=2>Frankly, I actually believe that you only need one mobility</FONT>
<BR><FONT SIZE=2>solution (and that doesn't mean MIP nor soft handoff). However, I </FONT>
<BR><FONT SIZE=2>do believe that for scalability reasons, there are local and global</FONT>
<BR><FONT SIZE=2>components.</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;Try being flippant once and a while, it releases the</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;creative juices.&nbsp; May be try being flipper since this</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;is SeaMoby.</FONT>
</P>

<P><FONT SIZE=2>Don't get me started, the outside world may not be ready for Gary</FONT>
<BR><FONT SIZE=2>Kenward's flippancy...</FONT>
</P>

<P><FONT SIZE=2>But, since you ask, I was originally going to propose that we use the</FONT>
<BR><FONT SIZE=2>term &quot;C-mobility&quot; instead of &quot;micromobility&quot;.</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Bye,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -pdn</FONT>
</P>

<P><FONT SIZE=2>A bientot.</FONT>
<BR><FONT SIZE=2>Gary</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C080BA.947E4730--


From owner-seamoby@diameter.org  Wed Jan 17 18:17:45 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28383
	for <seamoby-archive@odin.ietf.org>; Wed, 17 Jan 2001 18:17:43 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0HM6mu07117
	for seamoby-list; Wed, 17 Jan 2001 14:06:48 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0HM6iW07107
	for <Seamoby@diameter.org>; Wed, 17 Jan 2001 14:06:44 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 17 Jan 2001 16:06:06 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <D1PR9JA7>; Wed, 17 Jan 2001 16:06:09 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8069FF55F@zwdld001.ca.nortel.com>
From: "Guilhem Tardy" <guilhem.tardy@nortelnetworks.com>
To: "Gary Kenward" <gkenward@nortelnetworks.com>,
        "'Dana L. Blair'" <dblair@cisco.com>,
        Phil Neumiller <neumiller@telocity.com>, jaakko.sundquist@nokia.com
Cc: Seamoby@diameter.org, seamoby-mm@cdma-2000.org
Subject: RE: [seamoby] micro, schmicro
Date: Wed, 17 Jan 2001 16:06:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C080C9.4C8F1080"
X-Orig: <guilhem.tardy@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C080C9.4C8F1080
Content-Type: text/plain;
	charset="iso-8859-1"

 

-----Original Message-----
From: Kenward, Gary [WDLN2:AN10:EXCH] 
Sent: Wednesday, January 17, 2001 1:39 PM
To: 'Dana L. Blair'; Phil Neumiller; jaakko.sundquist@nokia.com
Cc: Seamoby@diameter.org; seamoby-mm@cdma-2000.org
Subject: RE: [seamoby] micro, schmicro



Dana: 

   You do not seem to have a concrete objection to "edge 
mobility". I tend to agree concerning "core mobility", although 
there is already a problem with the difference in denotation 
between the Internet use of "core" versus the cellular use of 
"core". 

   What not be clear and use "MIP" and "edge mobility"?  

This would make MIP as the official inter-domain mobility solution for
Seamoby. While one of the reasons of Seamoby is that some hosts might not be
MIP-enabled. I don't buy your solution, but it is only semantics anyway. For
the record, I was suggesting in a previous message to the mm list to use
'intra-domain' and 'inter-domain' mobility (which is consistant with
Jaakkoo's views, I believe), and talk about an 'edge mobility domain' as the
collection of separately administered networks which agree to cooperate on
the matter of mobility. I also pointed out the need for a guaranteed
uniqueness of IP addresses within the so-called edge mobility domain.

Guilhem. 

Gary 

> -----Original Message----- 
> From: Dana L. Blair [ mailto:dblair@cisco.com <mailto:dblair@cisco.com> ] 
> Sent: Wednesday, January 17, 2001 8:54 AM 
> To: Phil Neumiller; jaakko.sundquist@nokia.com 
> Cc: Seamoby@diameter.org; seamoby-mm@cdma-2000.org 
> Subject: Re: [seamoby] micro, schmicro 
> 
> 
> Let's take this discussion back to the micro-mobility alias, 
> since it is a mobility 
> discussion. 
> 
> At 07:39 AM 1/17/01 -0600, Phil Neumiller wrote: 
> >jaakko.sundquist@nokia.com wrote: 
> >> 
> >> Hi all, 
> >> 
> >> I don't know, if this helps at all, but I thought I might 
> share some of my 
> >> (not too distant) earlier experiences in mobility work on 
> H.323 systems. 
> >> First of all, I have never seen a good definition for 
> micro and macro 
> >> mobility. Yet people use these as if they were clearly and 
> similarly 
> >> understood by everyone. If you ask me, micro mobility in 
> the context of IP 
> >> networks is something that happens behind an access point 
> or a base station, 
> >> i.e. no change of the CoA is involved and thus there isn't 
> much (anything?) 
> >> that needs to be done in the IP layer. However, as I said, 
> I'm sure there 
> >> are other definitions for micro mobility as well. 
> > 
> >You are correct.  This seems to be the running definition or 
> what I have 
> >called the "classic" definition of micro-mobility.  Now I have 
> >questioned 
> >whether this distinction is a useful one.  My feeling is that edge 
> >versus 
> >core mobility is a far more important distinction than a change in 
> >subnet. 
> 
> Edge and Core are too abstract terms to discuss detailed 
> mobility solutions. 
> Cellular folks use the term Core to reference an MSC, HLR, 
> other other systems. 
> IP folks use the term Core to referece a high speed backbone 
> IP network. 
> Since we are within the IP context let's use specific IP 
> terms.  That is 
> why I defined micro-mobility in terms of IP addressing an 
> Access Links. 
> 
> > 
> >Also, I believe edge mobility is active ALL the time, and 
> core mobility 
> >(mobile IP) is active WHEN subnet boundaries change.  Also, I believe 
> 
> I think you need to define subnet more specifically.  For 
> example, an ethernet 
> is an IP subnet which is part of a larger IP subnet for a 
> department which 
> is part of a company IP subnet which is part of an ISP IP 
> subnet which is 
> part of the internet.  Which subnet boundary are you referencing ? 
> 
> I tried to avoid the subnet ambiguity by saying there are 
> some boundaries where 
> the routable IP address assigned to the MN must change.  Then 
> there are others 
> where it does not change.  micromobility applies to those 
> cases where the 
> address does not change. 
> 
> >that edge mobility must compensate for the latency of adjustments in 
> >core 
> >routing updates made by mobile IP. 
> > 
> >So, as I have stated in every design team message list, I 
> hope we can 
> >convince the list to abandon this terminology and recognize the real 
> >problem which is edge versus core.  Complex behavior 
> enabling seamless 
> >mobility will be best implemented in edge devices of the global 
> >Internet. 
> >This is the ONLY way that it will scale globally.  As Tom Petty said, 
> >"No, I won't back down.." on this one. 
> 
> I don't think we disagree.  This design team is focussing on 
> mobility solutions 
> that can be implemented at the edge of an IP network where 
> the IP address 
> does not change. 
> 
> Let's discuss on the call today. 
> 
> thanks, 
> Dana 
> 
> > 
> >> What we did in the H.323 Mobility work was not to use 
> these terms, but 
> >> instead refer to the scope of the mobility in terms that 
> were already 
> >> defined for H.323. Thus we ended up talking about 
> intra-zone, inter-zone, 
> >> intra-domain and inter-domain mobility. In a similar 
> manner, I would imagine 
> >> that terms, such as "intra/inter-link mobility", 
> "intra/inter-subnet 
> >> mobility", "intra/inter domain mobility" or something 
> similar could be used 
> >> with regards to Mobile IP and Seamoby. An alternative for 
> this would, of 
> >> course, be to define unambigiously the terms "micro 
> mobility" and "macro 
> >> mobility", but since these are already in use and mean 
> various different 
> >> things depending on the context, I would imagine that the 
> use of them would 
> >> lead to misunderstandings. 
> >> 
> >Here I would prefer we use the terminology of edge versus 
> core mobility. 
> >Can somebody shoot me down so I can get off this mantra??? :-) 
> > 
> >TNX, 
> > 
> >Phil (N9FCW, PSK/QPSK mbox = 10.140.700 MHz) 
> 
> 


------_=_NextPart_001_01C080C9.4C8F1080
Content-Type: text/html;
	charset="iso-8859-1"

<!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] micro, schmicro</TITLE>

<META content="MSHTML 5.50.4134.600" 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> Kenward, Gary 
  [WDLN2:AN10:EXCH] <BR><B>Sent:</B> Wednesday, January 17, 2001 1:39 
  PM<BR><B>To:</B> 'Dana L. Blair'; Phil Neumiller; 
  jaakko.sundquist@nokia.com<BR><B>Cc:</B> Seamoby@diameter.org; 
  seamoby-mm@cdma-2000.org<BR><B>Subject:</B> RE: [seamoby] micro, 
  schmicro<BR><BR></FONT></DIV>
  <P><FONT size=2>Dana:</FONT> </P>
  <P><FONT size=2>&nbsp;&nbsp; You do not seem to have a concrete objection to 
  "edge</FONT> <BR><FONT size=2>mobility". I tend to agree concerning "core 
  mobility", although</FONT> <BR><FONT size=2>there is already a problem with 
  the difference in denotation</FONT> <BR><FONT size=2>between the Internet use 
  of "core" versus the cellular use of </FONT><BR><FONT size=2>"core".</FONT> 
  </P>
  <P><FONT size=2>&nbsp;&nbsp; What not be clear and use "MIP" and "edge 
  mobility"?</FONT>&nbsp;<SPAN class=982140221-17012001><FONT face=Arial 
  color=#0000ff size=2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=982140221-17012001><FONT face=Arial color=#0000ff size=2>This 
  would make MIP as the official inter-domain mobility solution for Seamoby. 
  While one of the reasons of Seamoby is that some hosts might not be 
  MIP-enabled. I don't buy your solution, but it is only semantics anyway. For 
  the record, I was suggesting in a previous message to the mm list to use 
  'intra-domain' and 'inter-domain' mobility (which is consistant with Jaakkoo's 
  views, I believe), and talk about an 'edge mobility domain' as the collection 
  of separately administered networks which agree to cooperate on the matter of 
  mobility. I also pointed out the need for a guaranteed uniqueness of IP 
  addresses within the so-called edge mobility domain.</FONT></SPAN></P>
  <P><SPAN class=982140221-17012001><FONT face=Arial color=#0000ff 
  size=2>Guilhem.</FONT>&nbsp;</SPAN></P>
  <P><FONT size=2>Gary</FONT> </P>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  From: Dana L. Blair [<A 
  href="mailto:dblair@cisco.com">mailto:dblair@cisco.com</A>]</FONT> <BR><FONT 
  size=2>&gt; Sent: Wednesday, January 17, 2001 8:54 AM</FONT> <BR><FONT 
  size=2>&gt; To: Phil Neumiller; jaakko.sundquist@nokia.com</FONT> <BR><FONT 
  size=2>&gt; Cc: Seamoby@diameter.org; seamoby-mm@cdma-2000.org</FONT> 
  <BR><FONT size=2>&gt; Subject: Re: [seamoby] micro, schmicro</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Let's 
  take this discussion back to the micro-mobility alias, </FONT><BR><FONT 
  size=2>&gt; since it is a mobility</FONT> <BR><FONT size=2>&gt; 
  discussion.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; At 07:39 
  AM 1/17/01 -0600, Phil Neumiller wrote:</FONT> <BR><FONT size=2>&gt; 
  &gt;jaakko.sundquist@nokia.com wrote:</FONT> <BR><FONT size=2>&gt; &gt;&gt; 
  </FONT><BR><FONT size=2>&gt; &gt;&gt; Hi all,</FONT> <BR><FONT size=2>&gt; 
  &gt;&gt; </FONT><BR><FONT size=2>&gt; &gt;&gt; I don't know, if this helps at 
  all, but I thought I might </FONT><BR><FONT size=2>&gt; share some of 
  my</FONT> <BR><FONT size=2>&gt; &gt;&gt; (not too distant) earlier experiences 
  in mobility work on </FONT><BR><FONT size=2>&gt; H.323 systems.</FONT> 
  <BR><FONT size=2>&gt; &gt;&gt; First of all, I have never seen a good 
  definition for </FONT><BR><FONT size=2>&gt; micro and macro</FONT> <BR><FONT 
  size=2>&gt; &gt;&gt; mobility. Yet people use these as if they were clearly 
  and </FONT><BR><FONT size=2>&gt; similarly</FONT> <BR><FONT size=2>&gt; 
  &gt;&gt; understood by everyone. If you ask me, micro mobility in 
  </FONT><BR><FONT size=2>&gt; the context of IP</FONT> <BR><FONT size=2>&gt; 
  &gt;&gt; networks is something that happens behind an access point 
  </FONT><BR><FONT size=2>&gt; or a base station,</FONT> <BR><FONT size=2>&gt; 
  &gt;&gt; i.e. no change of the CoA is involved and thus there isn't 
  </FONT><BR><FONT size=2>&gt; much (anything?)</FONT> <BR><FONT size=2>&gt; 
  &gt;&gt; that needs to be done in the IP layer. However, as I said, 
  </FONT><BR><FONT size=2>&gt; I'm sure there</FONT> <BR><FONT size=2>&gt; 
  &gt;&gt; are other definitions for micro mobility as well.</FONT> <BR><FONT 
  size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;You are correct.&nbsp; This 
  seems to be the running definition or </FONT><BR><FONT size=2>&gt; what I 
  have</FONT> <BR><FONT size=2>&gt; &gt;called the "classic" definition of 
  micro-mobility.&nbsp; Now I have</FONT> <BR><FONT size=2>&gt; 
  &gt;questioned</FONT> <BR><FONT size=2>&gt; &gt;whether this distinction is a 
  useful one.&nbsp; My feeling is that edge</FONT> <BR><FONT size=2>&gt; 
  &gt;versus</FONT> <BR><FONT size=2>&gt; &gt;core mobility is a far more 
  important distinction than a change in</FONT> <BR><FONT size=2>&gt; 
  &gt;subnet.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Edge and 
  Core are too abstract terms to discuss detailed </FONT><BR><FONT size=2>&gt; 
  mobility solutions.</FONT> <BR><FONT size=2>&gt; Cellular folks use the term 
  Core to reference an MSC, HLR, </FONT><BR><FONT size=2>&gt; other other 
  systems.</FONT> <BR><FONT size=2>&gt; IP folks use the term Core to referece a 
  high speed backbone </FONT><BR><FONT size=2>&gt; IP network.</FONT> <BR><FONT 
  size=2>&gt; Since we are within the IP context let's use specific IP 
  </FONT><BR><FONT size=2>&gt; terms.&nbsp; That is</FONT> <BR><FONT size=2>&gt; 
  why I defined micro-mobility in terms of IP addressing an </FONT><BR><FONT 
  size=2>&gt; Access Links.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;Also, I believe edge 
  mobility is active ALL the time, and </FONT><BR><FONT size=2>&gt; core 
  mobility </FONT><BR><FONT size=2>&gt; &gt;(mobile IP) is active WHEN subnet 
  boundaries change.&nbsp; Also, I believe</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; I think you need to define subnet more 
  specifically.&nbsp; For </FONT><BR><FONT size=2>&gt; example, an 
  ethernet</FONT> <BR><FONT size=2>&gt; is an IP subnet which is part of a 
  larger IP subnet for a </FONT><BR><FONT size=2>&gt; department which</FONT> 
  <BR><FONT size=2>&gt; is part of a company IP subnet which is part of an ISP 
  IP </FONT><BR><FONT size=2>&gt; subnet which is</FONT> <BR><FONT size=2>&gt; 
  part of the internet.&nbsp; Which subnet boundary are you referencing ?</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; I tried to avoid the subnet 
  ambiguity by saying there are </FONT><BR><FONT size=2>&gt; some boundaries 
  where</FONT> <BR><FONT size=2>&gt; the routable IP address assigned to the MN 
  must change.&nbsp; Then </FONT><BR><FONT size=2>&gt; there are others</FONT> 
  <BR><FONT size=2>&gt; where it does not change.&nbsp; micromobility applies to 
  those </FONT><BR><FONT size=2>&gt; cases where the</FONT> <BR><FONT 
  size=2>&gt; address does not change.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; &gt;that edge mobility must compensate for the 
  latency of adjustments in</FONT> <BR><FONT size=2>&gt; &gt;core</FONT> 
  <BR><FONT size=2>&gt; &gt;routing updates made by mobile IP.</FONT> <BR><FONT 
  size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;So, as I have stated in 
  every design team message list, I </FONT><BR><FONT size=2>&gt; hope we can 
  </FONT><BR><FONT size=2>&gt; &gt;convince the list to abandon this terminology 
  and recognize the real </FONT><BR><FONT size=2>&gt; &gt;problem which is edge 
  versus core.&nbsp; Complex behavior </FONT><BR><FONT size=2>&gt; enabling 
  seamless</FONT> <BR><FONT size=2>&gt; &gt;mobility will be best implemented in 
  edge devices of the global</FONT> <BR><FONT size=2>&gt; &gt;Internet.</FONT> 
  <BR><FONT size=2>&gt; &gt;This is the ONLY way that it will scale 
  globally.&nbsp; As Tom Petty said,</FONT> <BR><FONT size=2>&gt; &gt;"No, I 
  won't back down.." on this one.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; I don't think we disagree.&nbsp; This design team is focussing on 
  </FONT><BR><FONT size=2>&gt; mobility solutions</FONT> <BR><FONT size=2>&gt; 
  that can be implemented at the edge of an IP network where </FONT><BR><FONT 
  size=2>&gt; the IP address</FONT> <BR><FONT size=2>&gt; does not 
  change.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Let's 
  discuss on the call today.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; thanks,</FONT> <BR><FONT size=2>&gt; Dana</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; 
  &gt;&gt; What we did in the H.323 Mobility work was not to use 
  </FONT><BR><FONT size=2>&gt; these terms, but</FONT> <BR><FONT size=2>&gt; 
  &gt;&gt; instead refer to the scope of the mobility in terms that 
  </FONT><BR><FONT size=2>&gt; were already</FONT> <BR><FONT size=2>&gt; 
  &gt;&gt; defined for H.323. Thus we ended up talking about </FONT><BR><FONT 
  size=2>&gt; intra-zone, inter-zone,</FONT> <BR><FONT size=2>&gt; &gt;&gt; 
  intra-domain and inter-domain mobility. In a similar </FONT><BR><FONT 
  size=2>&gt; manner, I would imagine</FONT> <BR><FONT size=2>&gt; &gt;&gt; that 
  terms, such as "intra/inter-link mobility", </FONT><BR><FONT size=2>&gt; 
  "intra/inter-subnet</FONT> <BR><FONT size=2>&gt; &gt;&gt; mobility", 
  "intra/inter domain mobility" or something </FONT><BR><FONT size=2>&gt; 
  similar could be used</FONT> <BR><FONT size=2>&gt; &gt;&gt; with regards to 
  Mobile IP and Seamoby. An alternative for </FONT><BR><FONT size=2>&gt; this 
  would, of</FONT> <BR><FONT size=2>&gt; &gt;&gt; course, be to define 
  unambigiously the terms "micro </FONT><BR><FONT size=2>&gt; mobility" and 
  "macro</FONT> <BR><FONT size=2>&gt; &gt;&gt; mobility", but since these are 
  already in use and mean </FONT><BR><FONT size=2>&gt; various different</FONT> 
  <BR><FONT size=2>&gt; &gt;&gt; things depending on the context, I would 
  imagine that the </FONT><BR><FONT size=2>&gt; use of them would</FONT> 
  <BR><FONT size=2>&gt; &gt;&gt; lead to misunderstandings.</FONT> <BR><FONT 
  size=2>&gt; &gt;&gt; </FONT><BR><FONT size=2>&gt; &gt;Here I would prefer we 
  use the terminology of edge versus </FONT><BR><FONT size=2>&gt; core 
  mobility.</FONT> <BR><FONT size=2>&gt; &gt;Can somebody shoot me down so I can 
  get off this mantra??? :-)</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT 
  size=2>&gt; &gt;TNX,</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT 
  size=2>&gt; &gt;Phil (N9FCW, PSK/QPSK mbox = 10.140.700 MHz)</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C080C9.4C8F1080--


From owner-seamoby@diameter.org  Wed Jan 17 19:28:54 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29657
	for <seamoby-archive@odin.ietf.org>; Wed, 17 Jan 2001 19:28:52 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0HNNeT07300
	for seamoby-list; Wed, 17 Jan 2001 15:23:40 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0HNNaW07290
	for <Seamoby@diameter.org>; Wed, 17 Jan 2001 15:23:36 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 17 Jan 2001 16:51:16 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <D1PR9KHZ>; Wed, 17 Jan 2001 16:43:46 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8069FF561@zwdld001.ca.nortel.com>
From: "Guilhem Tardy" <guilhem.tardy@nortelnetworks.com>
To: "Gary Kenward" <gkenward@nortelnetworks.com>
Cc: "'Seamoby@diameter.org'" <Seamoby@diameter.org>,
        "'seamoby-mm@cdma-2000.org'" <seamoby-mm@cdma-2000.org>
Subject: RE: [seamoby] micro, schmicro
Date: Wed, 17 Jan 2001 16:43:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C080CE.8F99E620"
X-Orig: <guilhem.tardy@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C080CE.8F99E620
Content-Type: text/plain;
	charset="iso-8859-1"

Gary,
 
OK, I don't propose to solve the same issues that MIP, and I am sorry for
this misunderstanding. If this makes all easier, let's forget the
"collection of separately administered networks..." Or I will have to define
what I intended by 'network', and then go with you over 'subnet', 'domain',
etc. Well, I might still define 'domain' after all. ;)
 
Still I don't buy the MIP/edge mobility terms, for the reason that it
defines Seamoby as a son of MIP, while it should be totally orthogonal to
any 'inter-domain' mobility solution in my opinion, as it should be totally
orthogonal to any link-layer mobility solution, too. Which doesn't preclude
interactions with those other mobility solutions, of course.
 
The fact that the definition of a 'domain' is not well agreed upon is quite
what I was shooting for. This is a logical entity more than a physical
entity, which makes it more flexible to define case by case. To me, a domain
is a network for which there's only one authority. Therefore, I can assume
that an edge mobility domain can guarantee me a unique IP address througout.
 
Frankly, I don't intend to go at war over some semantics. Whatever the
consensus, micro/macro, MIP/edge, intra/inter-domain, I will follow. But I
wanted to make my point, which is done now, and therefore I won't argue with
you or anyone on this anymore.
 
Guilhem.

-----Original Message-----
From: Kenward, Gary [WDLN2:AN10:EXCH] 
Sent: Wednesday, January 17, 2001 4:16 PM
To: Tardy, Guilhem [WDLN2:AN33:EXCH]
Subject: RE: [seamoby] micro, schmicro


Guilhem:
 
  The first problem is that none of the terms you use - domain,
inter-domain, intra-domain have definitions that have been agreed
upon.
 
   The second problem is that what you describe as "edge mobility"
"as the collection of separately administered networks which agree to 
cooperate on the matter of mobility" is clearly the issue that MIP is
designed to solve.
 
Gary

-----Original Message-----
From: Tardy, Guilhem [WDLN2:AN33:EXCH] 
Sent: Wednesday, January 17, 2001 4:06 PM
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Dana L. Blair'; Phil Neumiller;
jaakko.sundquist@nokia.com
Cc: Seamoby@diameter.org; seamoby-mm@cdma-2000.org
Subject: RE: [seamoby] micro, schmicro


 

-----Original Message-----
From: Kenward, Gary [WDLN2:AN10:EXCH] 
Sent: Wednesday, January 17, 2001 1:39 PM
To: 'Dana L. Blair'; Phil Neumiller; jaakko.sundquist@nokia.com
Cc: Seamoby@diameter.org; seamoby-mm@cdma-2000.org
Subject: RE: [seamoby] micro, schmicro



Dana: 

   You do not seem to have a concrete objection to "edge 
mobility". I tend to agree concerning "core mobility", although 
there is already a problem with the difference in denotation 
between the Internet use of "core" versus the cellular use of 
"core". 

   What not be clear and use "MIP" and "edge mobility"?  

This would make MIP as the official inter-domain mobility solution for
Seamoby. While one of the reasons of Seamoby is that some hosts might not be
MIP-enabled. I don't buy your solution, but it is only semantics anyway. For
the record, I was suggesting in a previous message to the mm list to use
'intra-domain' and 'inter-domain' mobility (which is consistant with
Jaakkoo's views, I believe), and talk about an 'edge mobility domain' as the
collection of separately administered networks which agree to cooperate on
the matter of mobility. I also pointed out the need for a guaranteed
uniqueness of IP addresses within the so-called edge mobility domain.

Guilhem. 

Gary 

> -----Original Message----- 
> From: Dana L. Blair [ mailto:dblair@cisco.com <mailto:dblair@cisco.com> ] 
> Sent: Wednesday, January 17, 2001 8:54 AM 
> To: Phil Neumiller; jaakko.sundquist@nokia.com 
> Cc: Seamoby@diameter.org; seamoby-mm@cdma-2000.org 
> Subject: Re: [seamoby] micro, schmicro 
> 
> 
> Let's take this discussion back to the micro-mobility alias, 
> since it is a mobility 
> discussion. 
> 
> At 07:39 AM 1/17/01 -0600, Phil Neumiller wrote: 
> >jaakko.sundquist@nokia.com wrote: 
> >> 
> >> Hi all, 
> >> 
> >> I don't know, if this helps at all, but I thought I might 
> share some of my 
> >> (not too distant) earlier experiences in mobility work on 
> H.323 systems. 
> >> First of all, I have never seen a good definition for 
> micro and macro 
> >> mobility. Yet people use these as if they were clearly and 
> similarly 
> >> understood by everyone. If you ask me, micro mobility in 
> the context of IP 
> >> networks is something that happens behind an access point 
> or a base station, 
> >> i.e. no change of the CoA is involved and thus there isn't 
> much (anything?) 
> >> that needs to be done in the IP layer. However, as I said, 
> I'm sure there 
> >> are other definitions for micro mobility as well. 
> > 
> >You are correct.  This seems to be the running definition or 
> what I have 
> >called the "classic" definition of micro-mobility.  Now I have 
> >questioned 
> >whether this distinction is a useful one.  My feeling is that edge 
> >versus 
> >core mobility is a far more important distinction than a change in 
> >subnet. 
> 
> Edge and Core are too abstract terms to discuss detailed 
> mobility solutions. 
> Cellular folks use the term Core to reference an MSC, HLR, 
> other other systems. 
> IP folks use the term Core to referece a high speed backbone 
> IP network. 
> Since we are within the IP context let's use specific IP 
> terms.  That is 
> why I defined micro-mobility in terms of IP addressing an 
> Access Links. 
> 
> > 
> >Also, I believe edge mobility is active ALL the time, and 
> core mobility 
> >(mobile IP) is active WHEN subnet boundaries change.  Also, I believe 
> 
> I think you need to define subnet more specifically.  For 
> example, an ethernet 
> is an IP subnet which is part of a larger IP subnet for a 
> department which 
> is part of a company IP subnet which is part of an ISP IP 
> subnet which is 
> part of the internet.  Which subnet boundary are you referencing ? 
> 
> I tried to avoid the subnet ambiguity by saying there are 
> some boundaries where 
> the routable IP address assigned to the MN must change.  Then 
> there are others 
> where it does not change.  micromobility applies to those 
> cases where the 
> address does not change. 
> 
> >that edge mobility must compensate for the latency of adjustments in 
> >core 
> >routing updates made by mobile IP. 
> > 
> >So, as I have stated in every design team message list, I 
> hope we can 
> >convince the list to abandon this terminology and recognize the real 
> >problem which is edge versus core.  Complex behavior 
> enabling seamless 
> >mobility will be best implemented in edge devices of the global 
> >Internet. 
> >This is the ONLY way that it will scale globally.  As Tom Petty said, 
> >"No, I won't back down.." on this one. 
> 
> I don't think we disagree.  This design team is focussing on 
> mobility solutions 
> that can be implemented at the edge of an IP network where 
> the IP address 
> does not change. 
> 
> Let's discuss on the call today. 
> 
> thanks, 
> Dana 
> 
> > 
> >> What we did in the H.323 Mobility work was not to use 
> these terms, but 
> >> instead refer to the scope of the mobility in terms that 
> were already 
> >> defined for H.323. Thus we ended up talking about 
> intra-zone, inter-zone, 
> >> intra-domain and inter-domain mobility. In a similar 
> manner, I would imagine 
> >> that terms, such as "intra/inter-link mobility", 
> "intra/inter-subnet 
> >> mobility", "intra/inter domain mobility" or something 
> similar could be used 
> >> with regards to Mobile IP and Seamoby. An alternative for 
> this would, of 
> >> course, be to define unambigiously the terms "micro 
> mobility" and "macro 
> >> mobility", but since these are already in use and mean 
> various different 
> >> things depending on the context, I would imagine that the 
> use of them would 
> >> lead to misunderstandings. 
> >> 
> >Here I would prefer we use the terminology of edge versus 
> core mobility. 
> >Can somebody shoot me down so I can get off this mantra??? :-) 
> > 
> >TNX, 
> > 
> >Phil (N9FCW, PSK/QPSK mbox = 10.140.700 MHz) 
> 
> 


------_=_NextPart_001_01C080CE.8F99E620
Content-Type: text/html;
	charset="iso-8859-1"

<!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] micro, schmicro</TITLE>

<META content="MSHTML 5.50.4134.600" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=443312721-17012001><FONT face=Arial 
color=#0000ff><STRONG>Gary,</STRONG></FONT></SPAN></DIV>
<DIV><SPAN class=443312721-17012001><STRONG><FONT face=Arial 
color=#0000ff></FONT></STRONG></SPAN>&nbsp;</DIV>
<DIV><SPAN class=443312721-17012001><FONT face=Arial color=#0000ff><STRONG>OK, I 
don't propose to solve the same issues that MIP, and I am sorry for this 
misunderstanding. If this makes all easier, let's forget the "collection of 
separately administered networks..." Or I will have to define what I intended by 
'network', and then go with you over 'subnet', 'domain',&nbsp;etc. Well, I might 
still define 'domain' after all. ;)</STRONG></FONT></SPAN></DIV>
<DIV><SPAN class=443312721-17012001><STRONG><FONT face=Arial 
color=#0000ff></FONT></STRONG></SPAN>&nbsp;</DIV>
<DIV><SPAN class=443312721-17012001><FONT face=Arial color=#0000ff><STRONG>Still 
I don't buy the MIP/edge mobility terms, for the reason that it defines Seamoby 
as a son of MIP, while it should be totally orthogonal to any 'inter-domain' 
mobility solution in my opinion, as it should be totally orthogonal to any 
link-layer mobility solution, too. Which doesn't preclude interactions with 
those other mobility solutions, of course.</STRONG></FONT></SPAN></DIV>
<DIV><SPAN class=443312721-17012001><STRONG><FONT face=Arial 
color=#0000ff></FONT></STRONG></SPAN>&nbsp;</DIV>
<DIV><SPAN class=443312721-17012001><STRONG><FONT face=Arial color=#0000ff>The 
fact that&nbsp;the definition&nbsp;of a 'domain' is not well agreed upon is 
quite what I was shooting for. This is a logical entity more than a physical 
entity, which makes it more flexible to define case by case. To me, a domain is 
a network for which there's only one authority. Therefore, I can assume that an 
edge mobility domain can guarantee me a unique IP address 
througout.</FONT></STRONG></SPAN></DIV>
<DIV><SPAN class=443312721-17012001><STRONG><FONT face=Arial 
color=#0000ff></FONT></STRONG></SPAN>&nbsp;</DIV>
<DIV><SPAN class=443312721-17012001><STRONG><FONT face=Arial 
color=#0000ff>Frankly, I don't intend to go at war over some semantics. Whatever 
the consensus, micro/macro, MIP/edge, intra/inter-domain, I will follow. But I 
wanted to make my point, which is done now, and therefore I won't argue with you 
or anyone on this anymore.</FONT></STRONG></SPAN></DIV>
<DIV><SPAN class=443312721-17012001><STRONG><FONT face=Arial 
color=#0000ff></FONT></STRONG></SPAN>&nbsp;</DIV>
<DIV><SPAN class=443312721-17012001><STRONG><FONT face=Arial 
color=#0000ff>Guilhem.</FONT></STRONG></SPAN></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> Kenward, Gary 
  [WDLN2:AN10:EXCH] <BR><B>Sent:</B> Wednesday, January 17, 2001 4:16 
  PM<BR><B>To:</B> Tardy, Guilhem [WDLN2:AN33:EXCH]<BR><B>Subject:</B> RE: 
  [seamoby] micro, schmicro<BR><BR></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=920430021-17012001>Guilhem:</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=920430021-17012001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920430021-17012001>&nbsp; The 
  first problem is that none of the terms you use - domain,</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920430021-17012001>inter-domain, 
  intra-domain have definitions that have been agreed</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=920430021-17012001>upon.</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=920430021-17012001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920430021-17012001>&nbsp;&nbsp; 
  The second problem is that what you describe as "edge 
  mobility"</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920430021-17012001>"as the 
  collection of separately administered networks which agree to 
  </SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920430021-17012001>cooperate on 
  the matter of mobility" is clearly the issue that M</SPAN></FONT><FONT 
  face="Comic Sans MS"><SPAN class=920430021-17012001>IP </SPAN></FONT><FONT 
  face="Comic Sans MS"><SPAN class=920430021-17012001>is</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920430021-17012001>designed to 
  solve.</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=920430021-17012001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=920430021-17012001>Gary</SPAN></FONT></DIV>
  <BLOCKQUOTE dir=ltr 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000080 2px solid; MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Tardy, Guilhem 
    [WDLN2:AN33:EXCH] <BR><B>Sent:</B> Wednesday, January 17, 2001 4:06 
    PM<BR><B>To:</B> Kenward, Gary [WDLN2:AN10:EXCH]; 'Dana L. Blair'; Phil 
    Neumiller; jaakko.sundquist@nokia.com<BR><B>Cc:</B> Seamoby@diameter.org; 
    seamoby-mm@cdma-2000.org<BR><B>Subject:</B> RE: [seamoby] micro, 
    schmicro<BR><BR></DIV></FONT>
    <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> Kenward, Gary 
      [WDLN2:AN10:EXCH] <BR><B>Sent:</B> Wednesday, January 17, 2001 1:39 
      PM<BR><B>To:</B> 'Dana L. Blair'; Phil Neumiller; 
      jaakko.sundquist@nokia.com<BR><B>Cc:</B> Seamoby@diameter.org; 
      seamoby-mm@cdma-2000.org<BR><B>Subject:</B> RE: [seamoby] micro, 
      schmicro<BR><BR></FONT></DIV>
      <P><FONT size=2>Dana:</FONT> </P>
      <P><FONT size=2>&nbsp;&nbsp; You do not seem to have a concrete objection 
      to "edge</FONT> <BR><FONT size=2>mobility". I tend to agree concerning 
      "core mobility", although</FONT> <BR><FONT size=2>there is already a 
      problem with the difference in denotation</FONT> <BR><FONT size=2>between 
      the Internet use of "core" versus the cellular use of </FONT><BR><FONT 
      size=2>"core".</FONT> </P>
      <P><FONT size=2>&nbsp;&nbsp; What not be clear and use "MIP" and "edge 
      mobility"?</FONT>&nbsp;<SPAN class=982140221-17012001><FONT face=Arial 
      color=#0000ff size=2>&nbsp;</FONT></SPAN></P>
      <P><SPAN class=982140221-17012001><FONT face=Arial color=#0000ff 
      size=2>This would make MIP as the official inter-domain mobility solution 
      for Seamoby. While one of the reasons of Seamoby is that some hosts might 
      not be MIP-enabled. I don't buy your solution, but it is only semantics 
      anyway. For the record, I was suggesting in a previous message to the mm 
      list to use 'intra-domain' and 'inter-domain' mobility (which is 
      consistant with Jaakkoo's views, I believe), and talk about an 'edge 
      mobility domain' as the collection of separately administered networks 
      which agree to cooperate on the matter of mobility. I also pointed out the 
      need for a guaranteed uniqueness of IP addresses within the so-called edge 
      mobility domain.</FONT></SPAN></P>
      <P><SPAN class=982140221-17012001><FONT face=Arial color=#0000ff 
      size=2>Guilhem.</FONT>&nbsp;</SPAN></P>
      <P><FONT size=2>Gary</FONT> </P>
      <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT 
      size=2>&gt; From: Dana L. Blair [<A 
      href="mailto:dblair@cisco.com">mailto:dblair@cisco.com</A>]</FONT> 
      <BR><FONT size=2>&gt; Sent: Wednesday, January 17, 2001 8:54 AM</FONT> 
      <BR><FONT size=2>&gt; To: Phil Neumiller; 
      jaakko.sundquist@nokia.com</FONT> <BR><FONT size=2>&gt; Cc: 
      Seamoby@diameter.org; seamoby-mm@cdma-2000.org</FONT> <BR><FONT 
      size=2>&gt; Subject: Re: [seamoby] micro, schmicro</FONT> <BR><FONT 
      size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
      Let's take this discussion back to the micro-mobility alias, 
      </FONT><BR><FONT size=2>&gt; since it is a mobility</FONT> <BR><FONT 
      size=2>&gt; discussion.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
      size=2>&gt; At 07:39 AM 1/17/01 -0600, Phil Neumiller wrote:</FONT> 
      <BR><FONT size=2>&gt; &gt;jaakko.sundquist@nokia.com wrote:</FONT> 
      <BR><FONT size=2>&gt; &gt;&gt; </FONT><BR><FONT size=2>&gt; &gt;&gt; Hi 
      all,</FONT> <BR><FONT size=2>&gt; &gt;&gt; </FONT><BR><FONT size=2>&gt; 
      &gt;&gt; I don't know, if this helps at all, but I thought I might 
      </FONT><BR><FONT size=2>&gt; share some of my</FONT> <BR><FONT size=2>&gt; 
      &gt;&gt; (not too distant) earlier experiences in mobility work on 
      </FONT><BR><FONT size=2>&gt; H.323 systems.</FONT> <BR><FONT size=2>&gt; 
      &gt;&gt; First of all, I have never seen a good definition for 
      </FONT><BR><FONT size=2>&gt; micro and macro</FONT> <BR><FONT size=2>&gt; 
      &gt;&gt; mobility. Yet people use these as if they were clearly and 
      </FONT><BR><FONT size=2>&gt; similarly</FONT> <BR><FONT size=2>&gt; 
      &gt;&gt; understood by everyone. If you ask me, micro mobility in 
      </FONT><BR><FONT size=2>&gt; the context of IP</FONT> <BR><FONT 
      size=2>&gt; &gt;&gt; networks is something that happens behind an access 
      point </FONT><BR><FONT size=2>&gt; or a base station,</FONT> <BR><FONT 
      size=2>&gt; &gt;&gt; i.e. no change of the CoA is involved and thus there 
      isn't </FONT><BR><FONT size=2>&gt; much (anything?)</FONT> <BR><FONT 
      size=2>&gt; &gt;&gt; that needs to be done in the IP layer. However, as I 
      said, </FONT><BR><FONT size=2>&gt; I'm sure there</FONT> <BR><FONT 
      size=2>&gt; &gt;&gt; are other definitions for micro mobility as 
      well.</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; 
      &gt;You are correct.&nbsp; This seems to be the running definition or 
      </FONT><BR><FONT size=2>&gt; what I have</FONT> <BR><FONT size=2>&gt; 
      &gt;called the "classic" definition of micro-mobility.&nbsp; Now I 
      have</FONT> <BR><FONT size=2>&gt; &gt;questioned</FONT> <BR><FONT 
      size=2>&gt; &gt;whether this distinction is a useful one.&nbsp; My feeling 
      is that edge</FONT> <BR><FONT size=2>&gt; &gt;versus</FONT> <BR><FONT 
      size=2>&gt; &gt;core mobility is a far more important distinction than a 
      change in</FONT> <BR><FONT size=2>&gt; &gt;subnet.</FONT> <BR><FONT 
      size=2>&gt; </FONT><BR><FONT size=2>&gt; Edge and Core are too abstract 
      terms to discuss detailed </FONT><BR><FONT size=2>&gt; mobility 
      solutions.</FONT> <BR><FONT size=2>&gt; Cellular folks use the term Core 
      to reference an MSC, HLR, </FONT><BR><FONT size=2>&gt; other other 
      systems.</FONT> <BR><FONT size=2>&gt; IP folks use the term Core to 
      referece a high speed backbone </FONT><BR><FONT size=2>&gt; IP 
      network.</FONT> <BR><FONT size=2>&gt; Since we are within the IP context 
      let's use specific IP </FONT><BR><FONT size=2>&gt; terms.&nbsp; That 
      is</FONT> <BR><FONT size=2>&gt; why I defined micro-mobility in terms of 
      IP addressing an </FONT><BR><FONT size=2>&gt; Access Links.</FONT> 
      <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT 
      size=2>&gt; &gt;Also, I believe edge mobility is active ALL the time, and 
      </FONT><BR><FONT size=2>&gt; core mobility </FONT><BR><FONT size=2>&gt; 
      &gt;(mobile IP) is active WHEN subnet boundaries change.&nbsp; Also, I 
      believe</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; I think 
      you need to define subnet more specifically.&nbsp; For </FONT><BR><FONT 
      size=2>&gt; example, an ethernet</FONT> <BR><FONT size=2>&gt; is an IP 
      subnet which is part of a larger IP subnet for a </FONT><BR><FONT 
      size=2>&gt; department which</FONT> <BR><FONT size=2>&gt; is part of a 
      company IP subnet which is part of an ISP IP </FONT><BR><FONT size=2>&gt; 
      subnet which is</FONT> <BR><FONT size=2>&gt; part of the internet.&nbsp; 
      Which subnet boundary are you referencing ?</FONT> <BR><FONT size=2>&gt; 
      </FONT><BR><FONT size=2>&gt; I tried to avoid the subnet ambiguity by 
      saying there are </FONT><BR><FONT size=2>&gt; some boundaries where</FONT> 
      <BR><FONT size=2>&gt; the routable IP address assigned to the MN must 
      change.&nbsp; Then </FONT><BR><FONT size=2>&gt; there are others</FONT> 
      <BR><FONT size=2>&gt; where it does not change.&nbsp; micromobility 
      applies to those </FONT><BR><FONT size=2>&gt; cases where the</FONT> 
      <BR><FONT size=2>&gt; address does not change.</FONT> <BR><FONT 
      size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt;that edge mobility must 
      compensate for the latency of adjustments in</FONT> <BR><FONT size=2>&gt; 
      &gt;core</FONT> <BR><FONT size=2>&gt; &gt;routing updates made by mobile 
      IP.</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;So, 
      as I have stated in every design team message list, I </FONT><BR><FONT 
      size=2>&gt; hope we can </FONT><BR><FONT size=2>&gt; &gt;convince the list 
      to abandon this terminology and recognize the real </FONT><BR><FONT 
      size=2>&gt; &gt;problem which is edge versus core.&nbsp; Complex behavior 
      </FONT><BR><FONT size=2>&gt; enabling seamless</FONT> <BR><FONT 
      size=2>&gt; &gt;mobility will be best implemented in edge devices of the 
      global</FONT> <BR><FONT size=2>&gt; &gt;Internet.</FONT> <BR><FONT 
      size=2>&gt; &gt;This is the ONLY way that it will scale globally.&nbsp; As 
      Tom Petty said,</FONT> <BR><FONT size=2>&gt; &gt;"No, I won't back down.." 
      on this one.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; I 
      don't think we disagree.&nbsp; This design team is focussing on 
      </FONT><BR><FONT size=2>&gt; mobility solutions</FONT> <BR><FONT 
      size=2>&gt; that can be implemented at the edge of an IP network where 
      </FONT><BR><FONT size=2>&gt; the IP address</FONT> <BR><FONT size=2>&gt; 
      does not change.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
      Let's discuss on the call today.</FONT> <BR><FONT size=2>&gt; 
      </FONT><BR><FONT size=2>&gt; thanks,</FONT> <BR><FONT size=2>&gt; 
      Dana</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt;</FONT> 
      <BR><FONT size=2>&gt; &gt;&gt; What we did in the H.323 Mobility work was 
      not to use </FONT><BR><FONT size=2>&gt; these terms, but</FONT> <BR><FONT 
      size=2>&gt; &gt;&gt; instead refer to the scope of the mobility in terms 
      that </FONT><BR><FONT size=2>&gt; were already</FONT> <BR><FONT 
      size=2>&gt; &gt;&gt; defined for H.323. Thus we ended up talking about 
      </FONT><BR><FONT size=2>&gt; intra-zone, inter-zone,</FONT> <BR><FONT 
      size=2>&gt; &gt;&gt; intra-domain and inter-domain mobility. In a similar 
      </FONT><BR><FONT size=2>&gt; manner, I would imagine</FONT> <BR><FONT 
      size=2>&gt; &gt;&gt; that terms, such as "intra/inter-link mobility", 
      </FONT><BR><FONT size=2>&gt; "intra/inter-subnet</FONT> <BR><FONT 
      size=2>&gt; &gt;&gt; mobility", "intra/inter domain mobility" or something 
      </FONT><BR><FONT size=2>&gt; similar could be used</FONT> <BR><FONT 
      size=2>&gt; &gt;&gt; with regards to Mobile IP and Seamoby. An alternative 
      for </FONT><BR><FONT size=2>&gt; this would, of</FONT> <BR><FONT 
      size=2>&gt; &gt;&gt; course, be to define unambigiously the terms "micro 
      </FONT><BR><FONT size=2>&gt; mobility" and "macro</FONT> <BR><FONT 
      size=2>&gt; &gt;&gt; mobility", but since these are already in use and 
      mean </FONT><BR><FONT size=2>&gt; various different</FONT> <BR><FONT 
      size=2>&gt; &gt;&gt; things depending on the context, I would imagine that 
      the </FONT><BR><FONT size=2>&gt; use of them would</FONT> <BR><FONT 
      size=2>&gt; &gt;&gt; lead to misunderstandings.</FONT> <BR><FONT 
      size=2>&gt; &gt;&gt; </FONT><BR><FONT size=2>&gt; &gt;Here I would prefer 
      we use the terminology of edge versus </FONT><BR><FONT size=2>&gt; core 
      mobility.</FONT> <BR><FONT size=2>&gt; &gt;Can somebody shoot me down so I 
      can get off this mantra??? :-)</FONT> <BR><FONT size=2>&gt; &gt;</FONT> 
      <BR><FONT size=2>&gt; &gt;TNX,</FONT> <BR><FONT size=2>&gt; &gt;</FONT> 
      <BR><FONT size=2>&gt; &gt;Phil (N9FCW, PSK/QPSK mbox = 10.140.700 
      MHz)</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    </FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C080CE.8F99E620--


From owner-seamoby@diameter.org  Thu Jan 18 02:19:39 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20492
	for <seamoby-archive@odin.ietf.org>; Thu, 18 Jan 2001 02:19:39 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0I6B4007637
	for seamoby-list; Wed, 17 Jan 2001 22:11:04 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0I6B2W07632
	for <Seamoby@diameter.org>; Wed, 17 Jan 2001 22:11:02 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <CTQSV513>; Thu, 18 Jan 2001 00:19:23 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078BB1@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'Phil Neumiller'"
	 <neumiller@telocity.com>,
        jaakko.sundquist@nokia.com
Cc: Seamoby@diameter.org
Subject: RE: [seamoby] micro, schmicro
Date: Thu, 18 Jan 2001 00:19:23 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0810E.37DCB506"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0810E.37DCB506
Content-Type: text/plain;
	charset="iso-8859-1"

I agree, it is much better than "domain", "sub-net", "coverage area", or
"service area".
 
- Kulwinder. 
  
> Here I would prefer we use the terminology of edge versus 
> core mobility. 
> Can somebody shoot me down so I can get off this mantra??? :-) 
> 
> TNX, 
> 
> Phil (N9FCW, PSK/QPSK mbox = 10.140.700 MHz) 
> 

------_=_NextPart_001_01C0810E.37DCB506
Content-Type: text/html;
	charset="iso-8859-1"

<!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] micro, schmicro</TITLE>

<META content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT size=2><SPAN class=376371605-18012001><FONT face=Arial 
color=#0000ff>I agree,&nbsp;it is much better than&nbsp;"domain", "sub-net", 
"coverage area", or "service area".</FONT></SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=376371605-18012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT size=2><SPAN class=376371605-18012001><FONT face=Arial 
color=#0000ff>- Kulwinder.</FONT>&nbsp;</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN 
class=376371605-18012001>&nbsp;</SPAN>&nbsp;</FONT><BR><FONT size=2>&gt; Here I 
would prefer we use the terminology of edge versus </FONT><BR><FONT size=2>&gt; 
core mobility.</FONT> <BR><FONT size=2>&gt; Can somebody shoot me down so I can 
get off this mantra??? :-)</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt; TNX,</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Phil 
(N9FCW, PSK/QPSK mbox = 10.140.700 MHz)</FONT> <BR><FONT size=2>&gt; 
</FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C0810E.37DCB506--


From owner-seamoby@diameter.org  Thu Jan 18 02:34:57 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20621
	for <seamoby-archive@odin.ietf.org>; Thu, 18 Jan 2001 02:34:57 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0I6SqQ07666
	for seamoby-list; Wed, 17 Jan 2001 22:28:52 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0I6SmW07656
	for <Seamoby@diameter.org>; Wed, 17 Jan 2001 22:28:48 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <CTQSV51R>; Thu, 18 Jan 2001 00:37:09 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078BB2@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'Dana L. Blair'"
	 <dblair@cisco.com>,
        Phil Neumiller <neumiller@telocity.com>, jaakko.sundquist@nokia.com
Cc: Seamoby@diameter.org, seamoby-mm@cdma-2000.org
Subject: RE: [seamoby] micro, schmicro
Date: Thu, 18 Jan 2001 00:37:08 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C08110.B2F89C43"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C08110.B2F89C43
Content-Type: text/plain;
	charset="iso-8859-1"

Why not be technology neutral and NOT use MIP vs edge terminology?
 
MIP maybe replaced in the future for reasons known, or unknown to us.
I know it is very, very hard for a Nortel guy to even imagine the
possibility of a Universe with no MIP, 
but stranger things have happened.
 
I fully and completely support Phil's suggestion.
 
Let's be protocol neutral and go with " edge vs core".  Let's at least start
with:
 
 - a clean slate
 - figure out what we need SeaMoby to be first
 - Learn about the requirements of all of the different network types that
need SeaMoby. 
- Learn about the protocols that can offer some functionality to SeaMoby:
ie. SLP.
 
- Kulwinder.
 
 
 

------_=_NextPart_001_01C08110.B2F89C43
Content-Type: text/html;
	charset="iso-8859-1"

<!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] micro, schmicro</TITLE>

<META content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=941521905-18012001><FONT face=Arial color=#0000ff size=2>Why 
not be technology neutral and&nbsp;NOT use MIP vs edge 
terminology?</FONT></SPAN></DIV>
<DIV><SPAN class=941521905-18012001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=941521905-18012001><FONT face=Arial color=#0000ff size=2>MIP 
maybe replaced in the future for reasons known, or unknown to 
us.</FONT></SPAN></DIV>
<DIV><SPAN class=941521905-18012001><FONT face=Arial color=#0000ff size=2>I know 
it is very, very hard for a Nortel guy to even imagine the possibility of a 
Universe with no MIP, </FONT></SPAN></DIV>
<DIV><SPAN class=941521905-18012001><FONT face=Arial color=#0000ff size=2>but 
stranger things have happened.</FONT></SPAN></DIV>
<DIV><SPAN class=941521905-18012001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV><SPAN class=941521905-18012001>
<DIV><SPAN class=941521905-18012001><FONT face=Arial color=#0000ff size=2>I 
fully&nbsp;and completely support Phil's suggestion.</FONT></SPAN></DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2>Let's be protocol neutral 
and go with " edge vs core".&nbsp; Let's&nbsp;<SPAN class=941521905-18012001>at 
least </SPAN>start with<SPAN 
class=941521905-18012001>:</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
class=941521905-18012001></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><SPAN class=941521905-18012001></SPAN><FONT face=Arial><FONT 
color=#0000ff><FONT size=2>&nbsp;<SPAN class=941521905-18012001>- </SPAN>a clean 
slate</FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
class=941521905-18012001>&nbsp;- </SPAN>figure out what we need SeaMoby to be 
first</FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
class=941521905-18012001>&nbsp;-&nbsp;Learn about the requirements of all of the 
different&nbsp;network types that need 
SeaMoby.&nbsp;</SPAN></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=941521905-18012001><FONT face=Arial color=#0000ff size=2>- 
Learn about the protocols that can offer some functionality to SeaMoby: ie. 
SLP.</FONT></SPAN></DIV>
<DIV><SPAN class=941521905-18012001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=941521905-18012001><FONT face=Arial color=#0000ff size=2>- 
Kulwinder.</FONT></SPAN></DIV>
<DIV><SPAN class=941521905-18012001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=941521905-18012001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=941521905-18012001><FONT 
size=2></FONT></SPAN>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C08110.B2F89C43--


From owner-seamoby@diameter.org  Thu Jan 18 05:07:39 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21606
	for <seamoby-archive@odin.ietf.org>; Thu, 18 Jan 2001 05:07:37 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0I9Hho07988
	for seamoby-list; Thu, 18 Jan 2001 01:17:43 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0I9HeW07983
	for <seamoby@diameter.org>; Thu, 18 Jan 2001 01:17:40 -0800
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0I8Qw226732
	for <seamoby@diameter.org>; Thu, 18 Jan 2001 10:26:58 +0200 (EET)
Received: from esebh03nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T512dd93144ac158f2415c@esvir04nok.ntc.nokia.com>;
 Thu, 18 Jan 2001 10:25:59 +0200
Received: by esebh03nok with Internet Mail Service (5.5.2652.78)
	id <C0KKX4R7>; Thu, 18 Jan 2001 10:25:35 +0200
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DF636@eseis04nok>
From: john.loughney@nokia.com
To: gkenward@nortelnetworks.com
Cc: seamoby@diameter.org
Subject: RE: [seamoby] micro, schmicro
Date: Thu, 18 Jan 2001 10:25:33 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Gary,
 
And I would like to add an observation: it has been 
suggested by someone that the FA belongs at the AP. 
This would imply many things, not the least of which is 
changes to the definition of what an FA does - assuming 
the purpose of the FA being at the AP is to support 
SeaMoby. 

[<JAL> ]  FA is a Mobile IPv4 term (if I am not 
mistaken).  I think we should avoid using this
term - as I do believe we are considering IPv6
usage.
 
br,
John


From owner-seamoby@diameter.org  Thu Jan 18 12:41:10 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29302
	for <seamoby-archive@odin.ietf.org>; Thu, 18 Jan 2001 12:41:10 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0IGjac08696
	for seamoby-list; Thu, 18 Jan 2001 08:45:36 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0IGjYW08691
	for <seamoby@diameter.org>; Thu, 18 Jan 2001 08:45:34 -0800
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f0IEQ8113020
	for <seamoby@diameter.org>; Thu, 18 Jan 2001 06:26:08 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104])
	by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f0IERD027537
	for <seamoby@diameter.org>; Thu, 18 Jan 2001 06:27:13 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 882569D8.004F6089 ; Thu, 18 Jan 2001 06:27:00 -0800
X-Lotus-FromDomain: 3COM
From: Phil_Neumiller@3Com.com
To: seamoby@diameter.org
Message-ID: <882569D8.004F5610.00@hqoutbound.ops.3com.com>
Date: Thu, 18 Jan 2001 08:31:23 -0600
Subject: [seamoby] More beating my head against the wall....
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-seamoby@diameter.org
Precedence: bulk




---------------------- Forwarded by Phil Neumiller/MW/US/3Com on 01/18/2001
08:24 AM ---------------------------

Phil Neumiller/MW/US/3Com
01/17/2001 03:36 PM


Sent by:  Phil Neumiller  -  Network Systems Architect, RCG


To:   seamoby@diameter.org
cc:
Subject:  More beating my head against the wall....

BZZZZZZZTTTTTT.  WRONG ANSWER.

When Phil thinks of "edge mobility" (the mobility previously known as
micromobility), he does not give a rat's gluteous maximus about a
change in COA.  He sincerely believes that a new routable IP address
(not necessarily KNOWN TO BE THE COA YET) can be known to the
source AP well before MIP knows jack.  Methinks my arguments (which
have made my face rather blue) have escaped all.

NO NO NO NO.  In Phil's utopian world, edge mobility may indeed mean
an EVENTUAL change in COA forced by a prefix/subnet change that is
handled by edge mobility!  EDGE MOBILITY compensates for the delay
incured upstream in the big I by mobile IP when the COA MUST CHANGE.
So yes EDGE MOBILITY DOES ROUTING!!!!    Yes this is the main
problem statement of EDGE mobility.  NO, I don't think the classical
definition of micromobility buys me squat for seamlessness.

Yikes, I must have said this about 89 times now.  Maybe I need to
take a break or something since I can not seam to communicate this
no matter how hard I try.

Am I totally wacked here or what???

Thanks,

Phil





From owner-seamoby@diameter.org  Thu Jan 18 13:13:17 2001
Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00265
	for <seamoby-archive@odin.ietf.org>; Thu, 18 Jan 2001 13:13:17 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0IH83x08753
	for seamoby-list; Thu, 18 Jan 2001 09:08:03 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zircon.3com.com (zircon.3com.com [192.156.136.159])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0IH80W08748
	for <seamoby@diameter.org>; Thu, 18 Jan 2001 09:08:01 -0800
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by zircon.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f0IEXAo00487;
	Thu, 18 Jan 2001 06:33:10 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104])
	by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f0IEVp028432;
	Thu, 18 Jan 2001 06:31:51 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 882569D8.004FFAED ; Thu, 18 Jan 2001 06:33:35 -0800
X-Lotus-FromDomain: 3COM
From: Phil_Neumiller@3Com.com
To: seamoby@diameter.org
cc: pcalhoun@eng.sun.com, gkenward@nortelnetworks.com
Message-ID: <882569D8.004FF818.00@hqoutbound.ops.3com.com>
Date: Thu, 18 Jan 2001 08:39:20 -0600
Subject: [seamoby] SeaMoby list is sloooowwww
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-seamoby@diameter.org
Precedence: bulk



I find the sluggishness of the SeaMoby list almost unbearable.  In the "heat
of combat" (scholarly debate), I often find my train of thought derailed by an
inability to react to thoughts and rebuttals on this list.  I hereby raise a
formal
protest to Pat R. Calhoun (aka PatC++) to fix this deficiency in the list.
Other than the sluggishness the actual content on the diameter site etc.,
has been extremely well done by Pat.  Don't take it personally Pat, but your
listserv SUCKS!  The one running at Nortel spews messages almost
immediately, HOWEVER THAT ONE DROPS MESSAGES!!!!  Its 2001 and
we can't get listserv to work?  Yikes....


-Flippant Neumiller




From owner-seamoby@diameter.org  Thu Jan 18 16:06:11 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05421
	for <seamoby-archive@odin.ietf.org>; Thu, 18 Jan 2001 16:06:08 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0II9kW08943
	for seamoby-list; Thu, 18 Jan 2001 10:09:46 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0II9gW08933
	for <seamoby@diameter.org>; Thu, 18 Jan 2001 10:09:43 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 18 Jan 2001 12:14:51 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <DGL450GR>; Thu, 18 Jan 2001 12:12:44 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8B4A@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: seamoby@diameter.org
Subject: RE: [seamoby] More beating my head against the wall....
Date: Thu, 18 Jan 2001 12:12:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C08171.DC57E810"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C08171.DC57E810
Content-Type: text/plain;
	charset="iso-8859-1"


> -----Original Message-----
> From: Phil_Neumiller@3Com.com [mailto:Phil_Neumiller@3Com.com]
> Sent: Thursday, January 18, 2001 9:31 AM
> To: seamoby@diameter.org
> Subject: [seamoby] More beating my head against the wall....

*snip*

> 
> Am I totally wacked here or what???

Ask us no questions and we will tell you no lies?
(j/k).

I would tend to agree with you Phil, but do we have tangible evidence that 
the MIP routing is too slow, and the routing at the edge is required? I
*believe*
it is a problem, but I suspect the claim would be contentious without
numbers.
Anyone want to publish an experimental ID? Or, have I missed something
again,
is there already publish results on MIP routing performance?

Just asking,
Gary

> 
> Thanks,
> 
> Phil
> 
> 
> 
> 

------_=_NextPart_001_01C08171.DC57E810
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] More beating my head against the wall....</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Phil_Neumiller@3Com.com [<A HREF="mailto:Phil_Neumiller@3Com.com">mailto:Phil_Neumiller@3Com.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, January 18, 2001 9:31 AM</FONT>
<BR><FONT SIZE=2>&gt; To: seamoby@diameter.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: [seamoby] More beating my head against the wall....</FONT>
</P>

<P><FONT SIZE=2>*snip*</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Am I totally wacked here or what???</FONT>
</P>

<P><FONT SIZE=2>Ask us no questions and we will tell you no lies?</FONT>
<BR><FONT SIZE=2>(j/k).</FONT>
</P>

<P><FONT SIZE=2>I would tend to agree with you Phil, but do we have tangible evidence that </FONT>
<BR><FONT SIZE=2>the MIP routing is too slow, and the routing at the edge is required? I *believe*</FONT>
<BR><FONT SIZE=2>it is a problem, but I suspect the claim would be contentious without numbers.</FONT>
<BR><FONT SIZE=2>Anyone want to publish an experimental ID? Or, have I missed something again,</FONT>
<BR><FONT SIZE=2>is there already publish results on MIP routing performance?</FONT>
</P>

<P><FONT SIZE=2>Just asking,</FONT>
<BR><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thanks,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Phil</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C08171.DC57E810--


From owner-seamoby@diameter.org  Thu Jan 18 16:26:29 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05730
	for <seamoby-archive@odin.ietf.org>; Thu, 18 Jan 2001 16:26:28 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0II9l908944
	for seamoby-list; Thu, 18 Jan 2001 10:09:47 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0II9hW08934
	for <seamoby@diameter.org>; Thu, 18 Jan 2001 10:09:43 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 18 Jan 2001 12:15:16 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <DGL450JQ>; Thu, 18 Jan 2001 12:14:59 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8B4B@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: seamoby@diameter.org
Subject: RE: [seamoby] SeaMoby list is sloooowwww
Date: Thu, 18 Jan 2001 12:14:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C08172.29B53450"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C08172.29B53450
Content-Type: text/plain;
	charset="iso-8859-1"

Hmmm. Maybe we shouldn't move the list to the diameter server.

I think the messages to the Nortel server are lost during handoff.
Stop moving!

Gary

> -----Original Message-----
> From: Phil_Neumiller@3Com.com [mailto:Phil_Neumiller@3Com.com]
> Sent: Thursday, January 18, 2001 9:39 AM
> To: seamoby@diameter.org
> Cc: pcalhoun@eng.sun.com; Kenward, Gary [WDLN2:AN10:EXCH]
> Subject: [seamoby] SeaMoby list is sloooowwww
> 
> 
> 
> 
> I find the sluggishness of the SeaMoby list almost 
> unbearable.  In the "heat
> of combat" (scholarly debate), I often find my train of 
> thought derailed by an
> inability to react to thoughts and rebuttals on this list.  I 
> hereby raise a
> formal
> protest to Pat R. Calhoun (aka PatC++) to fix this deficiency 
> in the list.
> Other than the sluggishness the actual content on the 
> diameter site etc.,
> has been extremely well done by Pat.  Don't take it 
> personally Pat, but your
> listserv SUCKS!  The one running at Nortel spews messages almost
> immediately, HOWEVER THAT ONE DROPS MESSAGES!!!!  Its 2001 and
> we can't get listserv to work?  Yikes....
> 
> 
> -Flippant Neumiller
> 
> 
> 

------_=_NextPart_001_01C08172.29B53450
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] SeaMoby list is sloooowwww</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hmmm. Maybe we shouldn't move the list to the diameter server.</FONT>
</P>

<P><FONT SIZE=2>I think the messages to the Nortel server are lost during handoff.</FONT>
<BR><FONT SIZE=2>Stop moving!</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Phil_Neumiller@3Com.com [<A HREF="mailto:Phil_Neumiller@3Com.com">mailto:Phil_Neumiller@3Com.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, January 18, 2001 9:39 AM</FONT>
<BR><FONT SIZE=2>&gt; To: seamoby@diameter.org</FONT>
<BR><FONT SIZE=2>&gt; Cc: pcalhoun@eng.sun.com; Kenward, Gary [WDLN2:AN10:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Subject: [seamoby] SeaMoby list is sloooowwww</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I find the sluggishness of the SeaMoby list almost </FONT>
<BR><FONT SIZE=2>&gt; unbearable.&nbsp; In the &quot;heat</FONT>
<BR><FONT SIZE=2>&gt; of combat&quot; (scholarly debate), I often find my train of </FONT>
<BR><FONT SIZE=2>&gt; thought derailed by an</FONT>
<BR><FONT SIZE=2>&gt; inability to react to thoughts and rebuttals on this list.&nbsp; I </FONT>
<BR><FONT SIZE=2>&gt; hereby raise a</FONT>
<BR><FONT SIZE=2>&gt; formal</FONT>
<BR><FONT SIZE=2>&gt; protest to Pat R. Calhoun (aka PatC++) to fix this deficiency </FONT>
<BR><FONT SIZE=2>&gt; in the list.</FONT>
<BR><FONT SIZE=2>&gt; Other than the sluggishness the actual content on the </FONT>
<BR><FONT SIZE=2>&gt; diameter site etc.,</FONT>
<BR><FONT SIZE=2>&gt; has been extremely well done by Pat.&nbsp; Don't take it </FONT>
<BR><FONT SIZE=2>&gt; personally Pat, but your</FONT>
<BR><FONT SIZE=2>&gt; listserv SUCKS!&nbsp; The one running at Nortel spews messages almost</FONT>
<BR><FONT SIZE=2>&gt; immediately, HOWEVER THAT ONE DROPS MESSAGES!!!!&nbsp; Its 2001 and</FONT>
<BR><FONT SIZE=2>&gt; we can't get listserv to work?&nbsp; Yikes....</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -Flippant Neumiller</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C08172.29B53450--


From owner-seamoby@diameter.org  Thu Jan 18 16:54:59 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05941
	for <seamoby-archive@odin.ietf.org>; Thu, 18 Jan 2001 16:54:59 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0IIb5Y09047
	for seamoby-list; Thu, 18 Jan 2001 10:37:05 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0IIb3W09042
	for <seamoby@diameter.org>; Thu, 18 Jan 2001 10:37:03 -0800
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02459;
	Thu, 18 Jan 2001 09:45:23 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA27816;
	Thu, 18 Jan 2001 09:45:21 -0800 (PST)
Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id JAA19968;
	Thu, 18 Jan 2001 09:44:36 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Message-Id: <200101181744.JAA19968@nasnfs.eng.sun.com>
Date: Thu, 18 Jan 2001 09:43:03 -0800
To: <Phil_Neumiller@3com.com>, <seamoby@diameter.org>
Cc: <gkenward@nortelnetworks.com>, <Pat.Calhoun@eng.sun.com>
Reply-To: <Pat.Calhoun@eng.sun.com>
Subject: Re: [seamoby] SeaMoby list is sloooowwww
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

If you have a list server, please go ahead and take over the list, archiving, etc.
I just did a test, and my message was posted in less than 4 minutes. Not sure
what you mean by slugishness.... perhaps yesterday was particularly bad, but with
5 lists being hosted on one site...

PatC
>
>
>I find the sluggishness of the SeaMoby list almost unbearable.  In the "heat
>of combat" (scholarly debate), I often find my train of thought derailed by an
>inability to react to thoughts and rebuttals on this list.  I hereby raise a
>formal
>protest to Pat R. Calhoun (aka PatC++) to fix this deficiency in the list.
>Other than the sluggishness the actual content on the diameter site etc.,
>has been extremely well done by Pat.  Don't take it personally Pat, but your
>listserv SUCKS!  The one running at Nortel spews messages almost
>immediately, HOWEVER THAT ONE DROPS MESSAGES!!!!  Its 2001 and
>we can't get listserv to work?  Yikes....
>
>
>-Flippant Neumiller
>
>




From owner-seamoby@diameter.org  Thu Jan 18 17:27:24 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06368
	for <seamoby-archive@odin.ietf.org>; Thu, 18 Jan 2001 17:27:21 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0IIKxG08984
	for seamoby-list; Thu, 18 Jan 2001 10:20:59 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0IIKuW08979
	for <seamoby@diameter.org>; Thu, 18 Jan 2001 10:20:57 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 18 Jan 2001 12:14:17 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <DGL450BS>; Thu, 18 Jan 2001 12:07:32 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8B49@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'seamoby'" <seamoby@diameter.org>
Subject: RE: [seamoby] micro, schmicro
Date: Thu, 18 Jan 2001 12:07:20 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: text/plain; charset="iso-8859-1"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This issue is not edge vs MIP nor Seamoby vs MIP. It is in our charter to
interwork
with other IETF technology solutions, including, specifically MIP. Thus, we
have to
define the boundary, and consider how the two would interwork.
 
In addition, until we have the "edge" problem resolved, we really have no
business touching
on MIP issues, never mind talking about MIP being replaced.
 
Having said this, I would re-emphasize an earlier point made that I
supported: SeaMoby
does need to interoperate with MIP, but it should also be able to work
without MIP (implying that the services provided by MIP are either not
required or provided by another, possibly proprietary solution).
 
Gary

-----Original Message-----
From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
Sent: Thursday, January 18, 2001 12:37 AM
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Dana L. Blair'; Phil Neumiller;
jaakko.sundquist@nokia.com
Cc: Seamoby@diameter.org; seamoby-mm@cdma-2000.org
Subject: RE: [seamoby] micro, schmicro


Why not be technology neutral and NOT use MIP vs edge terminology?
 
MIP maybe replaced in the future for reasons known, or unknown to us.
I know it is very, very hard for a Nortel guy to even imagine the
possibility of a Universe with no MIP, 
but stranger things have happened.
 

I fully and completely support Phil's suggestion.
 
Let's be protocol neutral and go with " edge vs core".  Let's at least start
with:
 
 - a clean slate
 - figure out what we need SeaMoby to be first
 - Learn about the requirements of all of the different network types that
need SeaMoby. 
- Learn about the protocols that can offer some functionality to SeaMoby:
ie. SLP.
 
- Kulwinder.
 
 
 



From owner-seamoby@diameter.org  Thu Jan 18 18:06:14 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06704
	for <seamoby-archive@odin.ietf.org>; Thu, 18 Jan 2001 18:06:13 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0ILsbk01078
	for seamoby-list; Thu, 18 Jan 2001 13:54:37 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0ILsYo01073
	for <seamoby@diameter.org>; Thu, 18 Jan 2001 13:54:35 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 18 Jan 2001 14:03:13 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <DGL46DNM>; Thu, 18 Jan 2001 14:02:22 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E805B22556@zwdld001.ca.nortel.com>
From: "Hamid Syed" <hmsyed@nortelnetworks.com>
To: "'Phil_Neumiller@3Com.com'" <Phil_Neumiller@3Com.com>
Cc: seamoby_context@standards.nortelnetworks.com, seamoby@diameter.org,
        seamoby-mm@cdma-2000.org
Subject: RE: [seamoby] A CNP perspective on context transfer.
Date: Thu, 18 Jan 2001 14:02:16 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C08181.2CCAB3E0"
X-Orig: <hmsyed@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C08181.2CCAB3E0
Content-Type: text/plain

Hi Phil,

I guess the main problem is "when" to carry out the actual context transfer
and what may happen between the time the context was transfered and the time
when the actual handover of bearer resources occur
For example, in the proactive approach, the actual transfer of context
happens whenever the candidate and the source realizes that the mobile may
get connectivity thru the candidate. Of course, the candidate can submit a
bid but this bid would be based on its current capabilities, which may
change with the time. Again as an example, one of the factors while deciding
a bid is resource availability. The candidate can submit a bid with the
current available resources at time t1, but the mobile may decide to get
connected to it at time t2. Now between this delta time, the situation of
the available resources at the candidate may change. This is one example
where one of the deciding factor is time-dependent. The whole purpose of
context transfer and bidding would fail in this scenario. Not to mention
that the situation may become even worst for per packet context information.

just some thoughts

-Hamid Syed

> -----Original Message-----
> From:	Phil_Neumiller@3Com.com [SMTP:Phil_Neumiller@3Com.com]
> Sent:	Tuesday, January 16, 2001 3:07 PM
> To:	Syed, Hamid [WDLN2:AN22:EXCH]
> Cc:	seamoby_context@standards.nortelnetworks.com; seamoby@diameter.org;
> seamoby-mm@cdma-2000.org
> Subject:	[seamoby] A CNP perspective on context transfer.
> 
> 
> 
> 
> The contract bidding analogy is very applicable to context transfer.
> Consider
> the following.
> 
> A CONTRACT between an AP/AR pair may be established by a process of mutual
> selection based on a two way transfer of context.  Handover candidates
> (contractors)
> evaluate hand over requests made by handover sources.  The candidates then
> submit bids on those parts of contracts for which they are suited.  The
> bids
> contain
> the parts of the contract that can be handled by both parties.  The
> handover
> source
> can then take the best bid from its perspective and assign the handover in
> a
> locally
> optimal manner.  This scales to the globe.
> 
> I believe the transport mechanism we put in place for context transfer
> should
> support this pattern.  The semantics of payload are interpreted by the
> local
> mobility manager (micro-mobility) not the transport mechanism itself.
> 
> Thanks,
> 
> Phil
> 
> 

------_=_NextPart_001_01C08181.2CCAB3E0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: [seamoby] A CNP perspective on context transfer.</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hi Phil,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I guess the main =
problem is &quot;when&quot; to carry out the actual context transfer =
and what may happen between the time the context was transfered and the =
time when the actual handover of bearer resources occur</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">For example, in the =
proactive approach, the actual transfer of context happens whenever the =
candidate and the source realizes that the mobile may get connectivity =
thru the candidate. Of course, the candidate can submit a bid but this =
bid would be based on its current capabilities, which may change with =
the time. Again as an example, one of the factors while deciding a bid =
is resource availability. The candidate can submit a bid with the =
current available resources at time t1, but the mobile may decide to =
get connected to it at time t2. Now between this delta time, the =
situation of the available resources at the candidate may change. This =
is one example where one of the deciding factor is time-dependent. The =
whole purpose of context transfer and bidding would fail in this =
scenario. Not to mention that the situation may become even worst for =
per packet context information.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">just some =
thoughts</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">-Hamid Syed</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Phil_Neumiller@3Com.com =
[SMTP:Phil_Neumiller@3Com.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Tuesday, January 16, 2001 3:07 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Syed, Hamid [WDLN2:AN22:EXCH]</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">seamoby_context@standards.nortelnetworks.com; =
seamoby@diameter.org; seamoby-mm@cdma-2000.org</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">[seamoby] A CNP perspective on =
context transfer.</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">The contract bidding analogy is very =
applicable to context transfer.&nbsp; Consider</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the following.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">A CONTRACT between an AP/AR pair may =
be established by a process of mutual</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">selection based on a two way transfer =
of context.&nbsp; Handover candidates</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">(contractors)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">evaluate hand over requests made by =
handover sources.&nbsp; The candidates then</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">submit bids on those parts of =
contracts for which they are suited.&nbsp; The bids</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">contain</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the parts of the contract that can be =
handled by both parties.&nbsp; The handover</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">source</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">can then take the best bid from its =
perspective and assign the handover in a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">locally</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">optimal manner.&nbsp; This scales to =
the globe.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I believe the transport mechanism we =
put in place for context transfer should</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">support this pattern.&nbsp; The =
semantics of payload are interpreted by the local</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">mobility manager (micro-mobility) not =
the transport mechanism itself.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Phil</FONT>
</P>
<BR>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C08181.2CCAB3E0--


From owner-seamoby@diameter.org  Thu Jan 18 18:44:16 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07204
	for <seamoby-archive@odin.ietf.org>; Thu, 18 Jan 2001 18:44:15 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0IJOcu09138
	for seamoby-list; Thu, 18 Jan 2001 11:24:38 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0IJOaW09133
	for <seamoby@diameter.org>; Thu, 18 Jan 2001 11:24:36 -0800
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Thu, 18 Jan 2001 13:32:13 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <DGL46BY3>; Thu, 18 Jan 2001 13:25:05 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8069FF565@zwdld001.ca.nortel.com>
From: "Guilhem Tardy" <guilhem.tardy@nortelnetworks.com>
To: "Gary Kenward" <gkenward@nortelnetworks.com>,
        "'seamoby'" <seamoby@diameter.org>
Subject: RE: [seamoby] micro, schmicro
Date: Thu, 18 Jan 2001 13:24:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0817B.F417B9D0"
X-Orig: <guilhem.tardy@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0817B.F417B9D0
Content-Type: text/plain;
	charset="iso-8859-1"

Gary,

I totally agree with your last message. :)

So, when those boundaries are defined in a neutral wording (i.e. not
specific to MIP), I strongly support interworking with MIP *and* whatever
else IETF technology solutions outside of those boundaries. I certainly did
NOT intend to have Seamoby replace any IETF technology solutions *outside of
the boundaries of Seamoby* (even MIP, believe me!), and I feel overjoyed by
reading your last paragraph which emphasizes the neutrality of Seamoby
regarding to those IETF (or proprietary, as you noted) technology solutions.

Guilhem.

> -----Original Message-----
> From: Kenward, Gary [WDLN2:AN10:EXCH] 
> Sent: Thursday, January 18, 2001 12:07 PM
> To: 'seamoby'
> Subject: RE: [seamoby] micro, schmicro
> 
> 
> This issue is not edge vs MIP nor Seamoby vs MIP. It is in 
> our charter to
> interwork
> with other IETF technology solutions, including, specifically 
> MIP. Thus, we
> have to
> define the boundary, and consider how the two would interwork.
>  
> In addition, until we have the "edge" problem resolved, we 
> really have no
> business touching
> on MIP issues, never mind talking about MIP being replaced.
>  
> Having said this, I would re-emphasize an earlier point made that I
> supported: SeaMoby
> does need to interoperate with MIP, but it should also be able to work
> without MIP (implying that the services provided by MIP are either not
> required or provided by another, possibly proprietary solution).
>  
> Gary
> 
> -----Original Message-----
> From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
> Sent: Thursday, January 18, 2001 12:37 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Dana L. Blair'; Phil Neumiller;
> jaakko.sundquist@nokia.com
> Cc: Seamoby@diameter.org; seamoby-mm@cdma-2000.org
> Subject: RE: [seamoby] micro, schmicro
> 
> 
> Why not be technology neutral and NOT use MIP vs edge terminology?
>  
> MIP maybe replaced in the future for reasons known, or unknown to us.
> I know it is very, very hard for a Nortel guy to even imagine the
> possibility of a Universe with no MIP, 
> but stranger things have happened.
>  
> 
> I fully and completely support Phil's suggestion.
>  
> Let's be protocol neutral and go with " edge vs core".  Let's 
> at least start
> with:
>  
>  - a clean slate
>  - figure out what we need SeaMoby to be first
>  - Learn about the requirements of all of the different 
> network types that
> need SeaMoby. 
> - Learn about the protocols that can offer some functionality 
> to SeaMoby:
> ie. SLP.
>  
> - Kulwinder.
>  
>  
>  
> 
> 

------_=_NextPart_001_01C0817B.F417B9D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: [seamoby] micro, schmicro</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Gary,</FONT>
</P>

<P><FONT SIZE=3D2>I totally agree with your last message. :)</FONT>
</P>

<P><FONT SIZE=3D2>So, when those boundaries are defined in a neutral =
wording (i.e. not specific to MIP), I strongly support interworking =
with MIP *and* whatever else IETF technology solutions outside of those =
boundaries. I certainly did NOT intend to have Seamoby replace any IETF =
technology solutions *outside of the boundaries of Seamoby* (even MIP, =
believe me!), and I feel overjoyed by reading your last paragraph which =
emphasizes the neutrality of Seamoby regarding to those IETF (or =
proprietary, as you noted) technology solutions.</FONT></P>

<P><FONT SIZE=3D2>Guilhem.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Kenward, Gary [WDLN2:AN10:EXCH] </FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, January 18, 2001 12:07 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'seamoby'</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [seamoby] micro, schmicro</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This issue is not edge vs MIP nor Seamoby vs =
MIP. It is in </FONT>
<BR><FONT SIZE=3D2>&gt; our charter to</FONT>
<BR><FONT SIZE=3D2>&gt; interwork</FONT>
<BR><FONT SIZE=3D2>&gt; with other IETF technology solutions, =
including, specifically </FONT>
<BR><FONT SIZE=3D2>&gt; MIP. Thus, we</FONT>
<BR><FONT SIZE=3D2>&gt; have to</FONT>
<BR><FONT SIZE=3D2>&gt; define the boundary, and consider how the two =
would interwork.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; In addition, until we have the &quot;edge&quot; =
problem resolved, we </FONT>
<BR><FONT SIZE=3D2>&gt; really have no</FONT>
<BR><FONT SIZE=3D2>&gt; business touching</FONT>
<BR><FONT SIZE=3D2>&gt; on MIP issues, never mind talking about MIP =
being replaced.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; Having said this, I would re-emphasize an =
earlier point made that I</FONT>
<BR><FONT SIZE=3D2>&gt; supported: SeaMoby</FONT>
<BR><FONT SIZE=3D2>&gt; does need to interoperate with MIP, but it =
should also be able to work</FONT>
<BR><FONT SIZE=3D2>&gt; without MIP (implying that the services =
provided by MIP are either not</FONT>
<BR><FONT SIZE=3D2>&gt; required or provided by another, possibly =
proprietary solution).</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; Gary</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Kulwinder Atwal [<A =
HREF=3D"mailto:kulwinder.atwal@zucotto.com">mailto:kulwinder.atwal@zucot=
to.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, January 18, 2001 12:37 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Dana L. =
Blair'; Phil Neumiller;</FONT>
<BR><FONT SIZE=3D2>&gt; jaakko.sundquist@nokia.com</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Seamoby@diameter.org; =
seamoby-mm@cdma-2000.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [seamoby] micro, schmicro</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Why not be technology neutral and NOT use MIP =
vs edge terminology?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; MIP maybe replaced in the future for reasons =
known, or unknown to us.</FONT>
<BR><FONT SIZE=3D2>&gt; I know it is very, very hard for a Nortel guy =
to even imagine the</FONT>
<BR><FONT SIZE=3D2>&gt; possibility of a Universe with no MIP, </FONT>
<BR><FONT SIZE=3D2>&gt; but stranger things have happened.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I fully and completely support Phil's =
suggestion.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; Let's be protocol neutral and go with &quot; =
edge vs core&quot;.&nbsp; Let's </FONT>
<BR><FONT SIZE=3D2>&gt; at least start</FONT>
<BR><FONT SIZE=3D2>&gt; with:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; - a clean slate</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; - figure out what we need SeaMoby to be =
first</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; - Learn about the requirements of all of =
the different </FONT>
<BR><FONT SIZE=3D2>&gt; network types that</FONT>
<BR><FONT SIZE=3D2>&gt; need SeaMoby. </FONT>
<BR><FONT SIZE=3D2>&gt; - Learn about the protocols that can offer some =
functionality </FONT>
<BR><FONT SIZE=3D2>&gt; to SeaMoby:</FONT>
<BR><FONT SIZE=3D2>&gt; ie. SLP.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; - Kulwinder.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0817B.F417B9D0--


From owner-seamoby@diameter.org  Thu Jan 18 19:08:39 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07450
	for <seamoby-archive@odin.ietf.org>; Thu, 18 Jan 2001 19:08:39 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0INGRw01269
	for seamoby-list; Thu, 18 Jan 2001 15:16:27 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0INGPo01264
	for <seamoby@cdma-2000.org>; Thu, 18 Jan 2001 15:16:25 -0800
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA23665
	for <seamoby@cdma-2000.org>; Thu, 18 Jan 2001 14:23:45 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA00767
	for <seamoby@cdma-2000.org>; Thu, 18 Jan 2001 14:23:43 -0800 (PST)
Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id OAA07172
	for <seamoby@cdma-2000.org>; Thu, 18 Jan 2001 14:23:28 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Message-Id: <200101182223.OAA07172@nasnfs.eng.sun.com>
Date: Thu, 18 Jan 2001 14:21:27 -0800
To: <seamoby@cdma-2000.org>
Reply-To: <Pat.Calhoun@eng.sun.com>
Subject: [seamoby] Mail Server and rolling blackouts
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

As many of you already know, California is undergoing rolling
blackouts due to energy shortages. The mail server was hit earlier today
for at least an hour, so any delays perceived by the mail server was
not a server problem, but a power problem.

It is obviously back up,

PatC



From owner-seamoby@diameter.org  Thu Jan 18 21:38:11 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09369
	for <seamoby-archive@odin.ietf.org>; Thu, 18 Jan 2001 21:38:11 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0J1ZWs01475
	for seamoby-list; Thu, 18 Jan 2001 17:35:32 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0J1ZUo01470
	for <seamoby@diameter.org>; Thu, 18 Jan 2001 17:35:30 -0800
Received: from agate.ops.3com.com (agate.3com.com [139.87.50.118])
	by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f0J0fb111855;
	Thu, 18 Jan 2001 16:41:41 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104])
	by agate.ops.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f0J0ggZ03969;
	Thu, 18 Jan 2001 16:42:42 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 882569D8.0077CE38 ; Thu, 18 Jan 2001 13:48:35 -0800
X-Lotus-FromDomain: 3COM
From: Phil_Neumiller@3Com.com
To: "Gary Kenward" <gkenward@nortelnetworks.com>
cc: seamoby@diameter.org
Message-ID: <882569D8.0076D5ED.00@hqoutbound.ops.3com.com>
Date: Thu, 18 Jan 2001 14:38:22 -0600
Subject: RE: [seamoby] More beating my head against the wall....
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=Gy8Gtx0rcg9tKbBsTR15HygUy0CadnZIWXTPPiN0syjwItYQz0Al3nPJ"
Content-Disposition: inline
Sender: owner-seamoby@diameter.org
Precedence: bulk

--0__=Gy8Gtx0rcg9tKbBsTR15HygUy0CadnZIWXTPPiN0syjwItYQz0Al3nPJ
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline







Sent by:  "Gary Kenward" <gkenward@nortelnetworks.com>

*snip*


I would tend to agree with you Phil, but do we have tangible evidence that
the MIP routing is too slow, and the routing at the edge is required? I
*believe*
it is a problem, but I suspect the claim would be contentious without
numbers.

pdn>If it were not slow (my measurements done about 2 years back indicated
pdn>that it was), why would the MIP group be so actively pursuing fast
pdn>handoff?  My REAL belief is that fast hand off work belongs in
pdn>SeaMoby.  That is if you are willing to seperate the world into
pdn>Core routing (mobile IP) and edge tunnelling (SeaMoby).  This type of
pdn>division of labor makes MUCH more sense to me technically, but the
pdn>politics of such a reorganization make its possibility of existence
pdn>tenuous.  Just think how the MIP group would be free to worry about
pdn>optimizing the router chains for mobility rather than edge device
pdn>junk.  SeaMoby would only have to worry about eventually sending a
pdn>new MIP registration while a temporary tunnel keeps the connection
pdn>seamless.  Perhaps I really am wacked, but this is the way I see
pdn>it.




--0__=Gy8Gtx0rcg9tKbBsTR15HygUy0CadnZIWXTPPiN0syjwItYQz0Al3nPJ
Content-type: text/html; 
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U
PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1Mi4zNSI+DQo8VElUTEU+UkU6IFtz
ZWFtb2J5XSBNb3JlIGJlYXRpbmcgbXkgaGVhZCBhZ2FpbnN0IHRoZSB3YWxsLi4uLjwvVElUTEU+
DQo8L0hFQUQ+DQo8Qk9EWT4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yPiZndDsgLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgRnJvbTogUGhp
bF9OZXVtaWxsZXJAM0NvbS5jb20gWzxBIEhSRUY9Im1haWx0bzpQaGlsX05ldW1pbGxlckAzQ29t
LmNvbSI+bWFpbHRvOlBoaWxfTmV1bWlsbGVyQDNDb20uY29tPC9BPl08L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yPiZndDsgU2VudDogVGh1cnNkYXksIEphbnVhcnkgMTgsIDIwMDEgOTozMSBBTTwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBUbzogc2VhbW9ieUBkaWFtZXRlci5vcmc8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgU3ViamVjdDogW3NlYW1vYnldIE1vcmUgYmVhdGlu
ZyBteSBoZWFkIGFnYWluc3QgdGhlIHdhbGwuLi4uPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBT
SVpFPTI+KnNuaXAqPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgQW0gSSB0b3RhbGx5IHdhY2tlZCBoZXJlIG9yIHdoYXQ/
Pz88L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5Bc2sgdXMgbm8gcXVlc3Rpb25zIGFu
ZCB3ZSB3aWxsIHRlbGwgeW91IG5vIGxpZXM/PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4oai9r
KS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5JIHdvdWxkIHRlbmQgdG8gYWdyZWUg
d2l0aCB5b3UgUGhpbCwgYnV0IGRvIHdlIGhhdmUgdGFuZ2libGUgZXZpZGVuY2UgdGhhdCA8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yPnRoZSBNSVAgcm91dGluZyBpcyB0b28gc2xvdywgYW5kIHRo
ZSByb3V0aW5nIGF0IHRoZSBlZGdlIGlzIHJlcXVpcmVkPyBJICpiZWxpZXZlKjwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTI+aXQgaXMgYSBwcm9ibGVtLCBidXQgSSBzdXNwZWN0IHRoZSBjbGFpbSB3
b3VsZCBiZSBjb250ZW50aW91cyB3aXRob3V0IG51bWJlcnMuPC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9Mj5BbnlvbmUgd2FudCB0byBwdWJsaXNoIGFuIGV4cGVyaW1lbnRhbCBJRD8gT3IsIGhhdmUg
SSBtaXNzZWQgc29tZXRoaW5nIGFnYWluLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+aXMgdGhl
cmUgYWxyZWFkeSBwdWJsaXNoIHJlc3VsdHMgb24gTUlQIHJvdXRpbmcgcGVyZm9ybWFuY2U/PC9G
T05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+SnVzdCBhc2tpbmcsPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9Mj5HYXJ5PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgVGhhbmtzLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgUGhpbDwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZP
TlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4NCg==

--0__=Gy8Gtx0rcg9tKbBsTR15HygUy0CadnZIWXTPPiN0syjwItYQz0Al3nPJ--



From owner-seamoby@diameter.org  Thu Jan 18 23:42:17 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA11664
	for <seamoby-archive@odin.ietf.org>; Thu, 18 Jan 2001 23:42:17 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0J3TOg01585
	for seamoby-list; Thu, 18 Jan 2001 19:29:24 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f0J3TMo01580
	for <seamoby@diameter.org>; Thu, 18 Jan 2001 19:29:22 -0800
Received: (cpmta 25568 invoked from network); 18 Jan 2001 18:36:42 -0800
Received: from dsl-64-193-0-129.telocity.com (HELO telocity.com) (64.193.0.129)
  by smtp.telocity.com (209.228.33.217) with SMTP; 18 Jan 2001 18:36:42 -0800
X-Sent: 19 Jan 2001 02:36:42 GMT
Message-ID: <3A67A8A2.E58E42C@telocity.com>
Date: Thu, 18 Jan 2001 20:38:26 -0600
From: Phil Neumiller <neumiller@telocity.com>
Organization: 3Com
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: seamoby@diameter.org
Subject: [seamoby] Location finding methods versus MIP home agent.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Just some random thoughts....

I see that a home agent (MIPv4/MIPv6) can help us find a MN
with a static home address provided it registers when it moves
from FA/COA(prefix) subnet to FA/COA(prefix) subnet.  This
seems to replace the cellular equivalent of an HLR/VLR in the
location sense, not the AAA.

Also, one could image, an IP accessible HLR/VLR gateway.

One could also imagine dynamic DNS being able to handle this.

One could also imagine some sort of LDAP directory that helped
locate mobiles.

I am sure we could dream up more proprietary looking schemes.

Am I missing any of the other obvious possibilities here?


From owner-seamoby@diameter.org  Thu Jan 18 23:42:20 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA11675
	for <seamoby-archive@odin.ietf.org>; Thu, 18 Jan 2001 23:42:18 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0J3JCY01568
	for seamoby-list; Thu, 18 Jan 2001 19:19:12 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from c007.snv.cp.net (c007-h014.c007.snv.cp.net [209.228.33.221])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f0J3J9o01558
	for <seamoby@diameter.org>; Thu, 18 Jan 2001 19:19:09 -0800
Received: (cpmta 27040 invoked from network); 18 Jan 2001 18:26:22 -0800
Received: from dsl-64-193-0-129.telocity.com (HELO telocity.com) (64.193.0.129)
  by smtp.telocity.com (209.228.33.221) with SMTP; 18 Jan 2001 18:26:22 -0800
X-Sent: 19 Jan 2001 02:26:22 GMT
Message-ID: <3A67A636.153B2FB6@telocity.com>
Date: Thu, 18 Jan 2001 20:28:06 -0600
From: Phil Neumiller <neumiller@telocity.com>
Organization: 3Com
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Hamid Syed <hmsyed@nortelnetworks.com>
CC: seamoby_context@standards.nortelnetworks.com, seamoby@diameter.org,
        seamoby-mm@cdma-2000.org
Subject: Re: [seamoby] A CNP perspective on context transfer.
References: <13E2EF604DE5D111B2E50000F80824E805B22556@zwdld001.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello Hamid,

> Hamid Syed wrote:
> 
> Hi Phil,
> 
> I guess the main problem is "when" to carry out the actual context transfer and what may happen between the time the context was
> transfered and the time when the actual handover of bearer resources occur
> 

pdn>This is precisely why I ADVOCATE bundling context transfer in the form of a 
pdn>"contract" with each hand over request sent to handover candidates (contractors).

> For example, in the proactive approach, the actual transfer of context happens whenever the candidate and the source realizes
> that the mobile may get connectivity thru the candidate. Of course, the candidate can submit a bid but this bid would be based on
> its current capabilities, which may change with the time. Again as an example, one of the factors while deciding a bid is
> resource availability. The candidate can submit a bid with the current available resources at time t1, but the mobile may decide
> to get connected to it at time t2. Now between this delta time, the situation of the available resources at the candidate may
> change. This is one example where one of the deciding factor is time-dependent. The whole purpose of context transfer and bidding
> would fail in this scenario. Not to mention that the situation may become even worst for per packet context information.

pdn>Yes, and the VERY closest you can tie state transfer to when it is needed
pdn>(the moment before the handoff decision made) is by bundling the context
pdn>with the handover request and the reflected and pruned context in the bids
pdn>that come back.  The bids will come back from each handover candidate, and
pdn>the manager of the anchor (the microflows bound to the MN that is moving),
pdn>will decide which candidate should get awarded the contract.  I just don't
pdn>see a more efficient way to do this.  Of course I AM WORKING in the SOLUTION
pdn>SPACE here (currently a sin in SeaMoby), but I have the code running, and
pdn>I have been playing with such a system for several years now. :-)

>      -----Original Message-----
>      From:   Phil_Neumiller@3Com.com [SMTP:Phil_Neumiller@3Com.com]
>      Sent:   Tuesday, January 16, 2001 3:07 PM
>      To:     Syed, Hamid [WDLN2:AN22:EXCH]
>      Cc:     seamoby_context@standards.nortelnetworks.com; seamoby@diameter.org; 
 seamoby-mm@cdma-2000.org
>      Subject:        [seamoby] A CNP perspective on context transfer.
> 
>      The contract bidding analogy is very applicable to context transfer.  Consider
>      the following.
> 
>      A CONTRACT between an AP/AR pair may be established by a process of mutual
>      selection based on a two way transfer of context.  Handover candidates (contractors)
>      evaluate hand over requests made by handover sources.  The candidates then
>      submit bids on those parts of contracts for which they are suited.  The bids contain
>      the parts of the contract that can be handled by both parties.  The handover source
>      can then take the best bid from its perspective and assign the handover in a locally
>      optimal manner.  This scales to the globe.
> 
>      I believe the transport mechanism we put in place for context transfer should
>      support this pattern.  The semantics of payload are interpreted by the local
>      mobility manager (micro-mobility) not the transport mechanism itself.
> 
>      Thanks,
> 
>      Phil


From owner-seamoby@diameter.org  Fri Jan 19 00:06:31 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA11867
	for <seamoby-archive@odin.ietf.org>; Fri, 19 Jan 2001 00:06:30 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0J3rHj01603
	for seamoby-list; Thu, 18 Jan 2001 19:53:17 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (flipper.cisco.com [171.69.25.141])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0J3rGo01598
	for <seamoby@diameter.org>; Thu, 18 Jan 2001 19:53:16 -0800
Received: from dblair-pc (ssh-sj1.cisco.com [171.68.225.134])
	by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id SAA13346;
	Thu, 18 Jan 2001 18:55:41 -0800 (PST)
Message-Id: <4.1.20010118215233.00997f00@flipper.cisco.com>
X-Sender: dblair@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 18 Jan 2001 21:54:19 -0500
To: Phil_Neumiller@3Com.com, "Gary Kenward" <gkenward@nortelnetworks.com>
From: Dana Blair <dblair@cisco.com>
Subject: RE: [seamoby] More beating my head against the wall....
Cc: seamoby@diameter.org
In-Reply-To: <882569D8.0076D5ED.00@hqoutbound.ops.3com.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-seamoby@diameter.org
Precedence: bulk

At 02:38 PM 1/18/01 -0600, Phil_Neumiller@3Com.com wrote:
>
>
>
>
>
>
>Sent by:  "Gary Kenward" <gkenward@nortelnetworks.com>
>
>*snip*
>
>
>I would tend to agree with you Phil, but do we have tangible evidence that
>the MIP routing is too slow, and the routing at the edge is required? I
>*believe*
>it is a problem, but I suspect the claim would be contentious without
>numbers.

Slowness can be measured in terms of round trip path, number and size of
packets that need to be sent and received.  This should be done when comparing
various mobility solutions.    

thanks,
Dana

>
>pdn>If it were not slow (my measurements done about 2 years back indicated
>pdn>that it was), why would the MIP group be so actively pursuing fast
>pdn>handoff?  My REAL belief is that fast hand off work belongs in
>pdn>SeaMoby.  That is if you are willing to seperate the world into
>pdn>Core routing (mobile IP) and edge tunnelling (SeaMoby).  This type of
>pdn>division of labor makes MUCH more sense to me technically, but the
>pdn>politics of such a reorganization make its possibility of existence
>pdn>tenuous.  Just think how the MIP group would be free to worry about
>pdn>optimizing the router chains for mobility rather than edge device
>pdn>junk.  SeaMoby would only have to worry about eventually sending a
>pdn>new MIP registration while a temporary tunnel keeps the connection
>pdn>seamless.  Perhaps I really am wacked, but this is the way I see
>pdn>it.
>
>
>
>



From owner-seamoby@diameter.org  Fri Jan 19 01:29:34 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14680
	for <seamoby-archive@odin.ietf.org>; Fri, 19 Jan 2001 01:29:29 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0J5cEf01754
	for seamoby-list; Thu, 18 Jan 2001 21:38:14 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from smtp1.mail.yahoo.com (smtp1.mail.yahoo.com [128.11.69.60])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f0J5c7o01749
	for <seamoby@diameter.org>; Thu, 18 Jan 2001 21:38:12 -0800
Received: from mcns165.docsis43.singa.pore.net (HELO yap) (202.156.43.165)
  by smtp.mail.vip.suc.yahoo.com with SMTP; 19 Jan 2001 04:45:05 -0000
X-Apparently-From: <c4mcr@yahoo.co.uk>
Message-ID: <00aa01c081d2$bb738800$a52b9cca@yap>
Reply-To: "c4mcr" <cny@ieee.org>
From: "c4mcr" <c4mcr@yahoo.co.uk>
To: "Gary Kenward" <gkenward@nortelnetworks.com>, <seamoby@diameter.org>
Subject: Re: [seamoby] More beating my head against the wall....
Date: Fri, 19 Jan 2001 12:45:53 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00A7_01C08215.C996C800"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-seamoby@diameter.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00A7_01C08215.C996C800
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: [seamoby] More beating my head against the wall....Hi

MIPv4 is known to have triangular routing problem.=20
(Yes, there are many papers you can refer to)
Solution: Host based routing.

"Only one solution exist that does not need host based routing and
yet resolve most triangular routing problem --> IIP"

Moving to MIPv6?=20
Reinvented Host based routing=20
(Get away with it, since not many people is it)
Does Yahoo and many millions of server support it?
They eventually will, but when? Do you have patient to wait? :)

"Only one solution exist that allows you to migrate from IPv4 to IPv6
without the pain --> IIP"

Cheers
Chern Nam Yap
  ----Original Message-----
  From: Gary Kenward <gkenward@nortelnetworks.com>
  To: seamoby@diameter.org <seamoby@diameter.org>
  Date: Friday, January 19, 2001 5:03 AM
  Subject: RE: [seamoby] More beating my head against the wall....




  > -----Original Message-----=20
  > From: Phil_Neumiller@3Com.com [mailto:Phil_Neumiller@3Com.com]=20
  > Sent: Thursday, January 18, 2001 9:31 AM=20
  > To: seamoby@diameter.org=20
  > Subject: [seamoby] More beating my head against the wall....=20

  *snip*=20

  >=20
  > Am I totally wacked here or what???=20

  Ask us no questions and we will tell you no lies?=20
  (j/k).=20

  I would tend to agree with you Phil, but do we have tangible evidence =
that=20
  the MIP routing is too slow, and the routing at the edge is required? =
I *believe*=20
  it is a problem, but I suspect the claim would be contentious without =
numbers.=20
  Anyone want to publish an experimental ID? Or, have I missed something =
again,=20
  is there already publish results on MIP routing performance?=20

  Just asking,=20
  Gary=20

  >=20
  > Thanks,=20
  >=20
  > Phil=20
  >=20
  >=20
  >=20
  >=20


------=_NextPart_000_00A7_01C08215.C996C800
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [seamoby] More beating my head against the =
wall....</TITLE>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML =
3.2//EN">
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Hi</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>MIPv4 is known to&nbsp;have triangular routing =
problem.=20
</FONT></DIV>
<DIV><FONT size=3D2>(Yes, there are many papers you can refer =
to)</FONT></DIV>
<DIV><FONT size=3D2>Solution: Host based routing.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>"Only one solution exist that does not need host =
based routing=20
and</FONT></DIV>
<DIV><FONT size=3D2>yet resolve most triangular routing problem --&gt;=20
IIP"</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Moving to MIPv6? </FONT></DIV>
<DIV><FONT size=3D2>Reinvented Host based routing </FONT></DIV>
<DIV><FONT size=3D2>(Get away with it, since not&nbsp;many&nbsp;people =
is=20
it)</FONT></DIV>
<DIV><FONT size=3D2>Does Yahoo and many&nbsp;millions of server support=20
it?</FONT><FONT size=3D2></FONT></DIV>
<DIV><FONT size=3D2>They&nbsp;eventually will, but =
when?</FONT>&nbsp;<FONT=20
size=3D2>Do you have patient to wait? :)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>"Only one solution exist that allows you to migrate =
from IPv4=20
to IPv6</FONT><FONT size=3D2></FONT></DIV>
<DIV><FONT size=3D2>without the pain&nbsp;--&gt; =
IIP"</FONT></DIV></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Cheers</FONT></DIV>
<DIV><FONT size=3D2>Chern Nam Yap</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px">
  <DIV><FONT face=3DArial size=3D2><B>----Original =
Message-----</B><BR><B>From:=20
  </B>Gary Kenward &lt;<A=20
  =
href=3D"mailto:gkenward@nortelnetworks.com">gkenward@nortelnetworks.com</=
A>&gt;<BR><B>To:=20
  </B><A href=3D"mailto:seamoby@diameter.org">seamoby@diameter.org</A> =
&lt;<A=20
  =
href=3D"mailto:seamoby@diameter.org">seamoby@diameter.org</A>&gt;<BR><B>D=
ate:=20
  </B>Friday, January 19, 2001 5:03 AM<BR><B>Subject: </B>RE: [seamoby] =
More=20
  beating my head against the wall....<BR><BR></DIV></FONT><BR>
  <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
  From: <A =
href=3D"mailto:Phil_Neumiller@3Com.com">Phil_Neumiller@3Com.com</A> [<A=20
  =
href=3D"mailto:Phil_Neumiller@3Com.com">mailto:Phil_Neumiller@3Com.com</A=
>]</FONT>=20
  <BR><FONT size=3D2>&gt; Sent: Thursday, January 18, 2001 9:31 =
AM</FONT>=20
  <BR><FONT size=3D2>&gt; To: seamoby@diameter.org</FONT> <BR><FONT =
size=3D2>&gt;=20
  Subject: [seamoby] More beating my head against the wall....</FONT> =
</P>
  <P><FONT size=3D2>*snip*</FONT> </P>
  <P><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Am I totally =
wacked here or=20
  what???</FONT> </P>
  <P><FONT size=3D2>Ask us no questions and we will tell you no =
lies?</FONT>=20
  <BR><FONT size=3D2>(j/k).</FONT> </P>
  <P><FONT size=3D2>I would tend to agree with you Phil, but do we have =
tangible=20
  evidence that </FONT><BR><FONT size=3D2>the MIP routing is too slow, =
and the=20
  routing at the edge is required? I *believe*</FONT> <BR><FONT =
size=3D2>it is a=20
  problem, but I suspect the claim would be contentious without =
numbers.</FONT>=20
  <BR><FONT size=3D2>Anyone want to publish an experimental ID? Or, have =
I missed=20
  something again,</FONT> <BR><FONT size=3D2>is there already publish =
results on=20
  MIP routing performance?</FONT> </P>
  <P><FONT size=3D2>Just asking,</FONT> <BR><FONT size=3D2>Gary</FONT> =
</P>
  <P><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Thanks,</FONT> =
<BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Phil</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00A7_01C08215.C996C800--


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



From owner-seamoby@diameter.org  Fri Jan 19 02:26:45 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA25658
	for <seamoby-archive@odin.ietf.org>; Fri, 19 Jan 2001 02:26:43 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0J600n01769
	for seamoby-list; Thu, 18 Jan 2001 22:00:00 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0J5xvo01764
	for <seamoby@diameter.org>; Thu, 18 Jan 2001 21:59:57 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 19 Jan 2001 00:05:08 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <DGL46NVD>; Fri, 19 Jan 2001 00:05:11 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8B53@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'c4mcr'" <cny@ieee.org>, seamoby <seamoby@diameter.org>
Subject: RE: [seamoby] More beating my head against the wall....
Date: Fri, 19 Jan 2001 00:05:06 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C081D5.639D8A60"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C081D5.639D8A60
Content-Type: text/plain;
	charset="iso-8859-1"

I am aware of the triangular routing problem with MIPv4.
I believe that Phil was referring to CoA used in MIPv6.
 
Still no numbers.
 
Gary

-----Original Message-----
From: c4mcr [mailto:c4mcr@yahoo.co.uk]
Sent: Thursday, January 18, 2001 11:46 PM
To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby
Subject: Re: [seamoby] More beating my head against the wall....


Hi
 
MIPv4 is known to have triangular routing problem. 
(Yes, there are many papers you can refer to)
Solution: Host based routing.
 
"Only one solution exist that does not need host based routing and
yet resolve most triangular routing problem --> IIP"
 
Moving to MIPv6? 
Reinvented Host based routing 
(Get away with it, since not many people is it)
Does Yahoo and many millions of server support it?
They eventually will, but when? Do you have patient to wait? :)
 

"Only one solution exist that allows you to migrate from IPv4 to IPv6
without the pain --> IIP"
 
Cheers
Chern Nam Yap

----Original Message-----
From: Gary Kenward < gkenward@nortelnetworks.com
<mailto:gkenward@nortelnetworks.com> >
To: seamoby@diameter.org <mailto:seamoby@diameter.org>  <
seamoby@diameter.org <mailto:seamoby@diameter.org> >
Date: Friday, January 19, 2001 5:03 AM
Subject: RE: [seamoby] More beating my head against the wall....




> -----Original Message----- 
> From: Phil_Neumiller@3Com.com <mailto:Phil_Neumiller@3Com.com>  [
mailto:Phil_Neumiller@3Com.com <mailto:Phil_Neumiller@3Com.com> ] 
> Sent: Thursday, January 18, 2001 9:31 AM 
> To: seamoby@diameter.org 
> Subject: [seamoby] More beating my head against the wall.... 

*snip* 

> 
> Am I totally wacked here or what??? 

Ask us no questions and we will tell you no lies? 
(j/k). 

I would tend to agree with you Phil, but do we have tangible evidence that 
the MIP routing is too slow, and the routing at the edge is required? I
*believe* 
it is a problem, but I suspect the claim would be contentious without
numbers. 
Anyone want to publish an experimental ID? Or, have I missed something
again, 
is there already publish results on MIP routing performance? 

Just asking, 
Gary 

> 
> Thanks, 
> 
> Phil 
> 
> 
> 
> 


------_=_NextPart_001_01C081D5.639D8A60
Content-Type: text/html;
	charset="iso-8859-1"

<!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] More beating my head against the wall....</TITLE>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face="Comic Sans MS" size=2><SPAN class=640285104-19012001>I am aware 
of the triangular routing problem with MIPv4.</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS" size=2><SPAN class=640285104-19012001>I believe 
that Phil was referring to CoA used in MIPv6.</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=640285104-19012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS" size=2><SPAN class=640285104-19012001>Still no 
numbers.</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=640285104-19012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS" size=2><SPAN 
class=640285104-19012001>Gary</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> c4mcr 
  [mailto:c4mcr@yahoo.co.uk]<BR><B>Sent:</B> Thursday, January 18, 2001 11:46 
  PM<BR><B>To:</B> Kenward, Gary [WDLN2:AN10:EXCH]; seamoby<BR><B>Subject:</B> 
  Re: [seamoby] More beating my head against the wall....<BR><BR></DIV></FONT>
  <DIV><FONT size=2>Hi</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT size=2>MIPv4 is known to&nbsp;have triangular routing problem. 
  </FONT></DIV>
  <DIV><FONT size=2>(Yes, there are many papers you can refer to)</FONT></DIV>
  <DIV><FONT size=2>Solution: Host based routing.</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT size=2>"Only one solution exist that does not need host based 
  routing and</FONT></DIV>
  <DIV><FONT size=2>yet resolve most triangular routing problem --&gt; 
  IIP"</FONT></DIV>
  <DIV><FONT size=2></FONT>&nbsp;</DIV>
  <DIV><FONT size=2>Moving to MIPv6? </FONT></DIV>
  <DIV><FONT size=2>Reinvented Host based routing </FONT></DIV>
  <DIV><FONT size=2>(Get away with it, since not&nbsp;many&nbsp;people is 
  it)</FONT></DIV>
  <DIV><FONT size=2>Does Yahoo and many&nbsp;millions of server support 
  it?</FONT><FONT size=2></FONT></DIV>
  <DIV><FONT size=2>They&nbsp;eventually will, but when?</FONT>&nbsp;<FONT 
  size=2>Do you have patient to wait? :)</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT size=2>
  <DIV><FONT size=2>"Only one solution exist that allows you to migrate from 
  IPv4 to IPv6</FONT><FONT size=2></FONT></DIV>
  <DIV><FONT size=2>without the pain&nbsp;--&gt; IIP"</FONT></DIV></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT size=2>Cheers</FONT></DIV>
  <DIV><FONT size=2>Chern Nam Yap</FONT></DIV>
  <BLOCKQUOTE 
  style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV><FONT face=Arial size=2><B>----Original Message-----</B><BR><B>From: 
    </B>Gary Kenward &lt;<A 
    href="mailto:gkenward@nortelnetworks.com">gkenward@nortelnetworks.com</A>&gt;<BR><B>To: 
    </B><A href="mailto:seamoby@diameter.org">seamoby@diameter.org</A> &lt;<A 
    href="mailto:seamoby@diameter.org">seamoby@diameter.org</A>&gt;<BR><B>Date: 
    </B>Friday, January 19, 2001 5:03 AM<BR><B>Subject: </B>RE: [seamoby] More 
    beating my head against the wall....<BR><BR></DIV></FONT><BR>
    <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
    From: <A href="mailto:Phil_Neumiller@3Com.com">Phil_Neumiller@3Com.com</A> 
    [<A 
    href="mailto:Phil_Neumiller@3Com.com">mailto:Phil_Neumiller@3Com.com</A>]</FONT> 
    <BR><FONT size=2>&gt; Sent: Thursday, January 18, 2001 9:31 AM</FONT> 
    <BR><FONT size=2>&gt; To: seamoby@diameter.org</FONT> <BR><FONT size=2>&gt; 
    Subject: [seamoby] More beating my head against the wall....</FONT> </P>
    <P><FONT size=2>*snip*</FONT> </P>
    <P><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Am I totally wacked here 
    or what???</FONT> </P>
    <P><FONT size=2>Ask us no questions and we will tell you no lies?</FONT> 
    <BR><FONT size=2>(j/k).</FONT> </P>
    <P><FONT size=2>I would tend to agree with you Phil, but do we have tangible 
    evidence that </FONT><BR><FONT size=2>the MIP routing is too slow, and the 
    routing at the edge is required? I *believe*</FONT> <BR><FONT size=2>it is a 
    problem, but I suspect the claim would be contentious without 
    numbers.</FONT> <BR><FONT size=2>Anyone want to publish an experimental ID? 
    Or, have I missed something again,</FONT> <BR><FONT size=2>is there already 
    publish results on MIP routing performance?</FONT> </P>
    <P><FONT size=2>Just asking,</FONT> <BR><FONT size=2>Gary</FONT> </P>
    <P><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Thanks,</FONT> <BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt; Phil</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; </FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C081D5.639D8A60--


From owner-seamoby@diameter.org  Fri Jan 19 02:34:50 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA25699
	for <seamoby-archive@odin.ietf.org>; Fri, 19 Jan 2001 02:34:49 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0J6C8C01814
	for seamoby-list; Thu, 18 Jan 2001 22:12:08 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0J6C2o01809
	for <seamoby@diameter.org>; Thu, 18 Jan 2001 22:12:06 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 19 Jan 2001 00:19:09 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <DGL46NXH>; Fri, 19 Jan 2001 00:19:12 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8B55@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Phil_Neumiller@3Com.com'" <Phil_Neumiller@3Com.com>
Cc: seamoby@diameter.org
Subject: RE: [seamoby] More beating my head against the wall....
Date: Fri, 19 Jan 2001 00:19:08 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C081D7.59459CE0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C081D7.59459CE0
Content-Type: text/plain;
	charset="iso-8859-1"

You are preaching to the choir, as you fully well know.
My point was, is there quantitative justification for the statement you
made that MIP is too slow?

Gary

> -----Original Message-----
> From: Phil_Neumiller@3Com.com [mailto:Phil_Neumiller@3Com.com]
> Sent: Thursday, January 18, 2001 3:38 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@diameter.org
> Subject: RE: [seamoby] More beating my head against the wall....
> 
> 
> 
> 
> 
> 
> 
> 
> Sent by:  "Gary Kenward" <gkenward@nortelnetworks.com>
> 
> *snip*
> 
> 
> I would tend to agree with you Phil, but do we have tangible 
> evidence that
> the MIP routing is too slow, and the routing at the edge is 
> required? I
> *believe*
> it is a problem, but I suspect the claim would be contentious without
> numbers.
> 
> pdn>If it were not slow (my measurements done about 2 years 
> back indicated
> pdn>that it was), why would the MIP group be so actively pursuing fast
> pdn>handoff?  My REAL belief is that fast hand off work belongs in
> pdn>SeaMoby.  That is if you are willing to seperate the world into
> pdn>Core routing (mobile IP) and edge tunnelling (SeaMoby).  
> This type of
> pdn>division of labor makes MUCH more sense to me technically, but the
> pdn>politics of such a reorganization make its possibility of 
> existence
> pdn>tenuous.  Just think how the MIP group would be free to 
> worry about
> pdn>optimizing the router chains for mobility rather than edge device
> pdn>junk.  SeaMoby would only have to worry about eventually sending a
> pdn>new MIP registration while a temporary tunnel keeps the connection
> pdn>seamless.  Perhaps I really am wacked, but this is the way I see
> pdn>it.
> 
> 
> 
> 

------_=_NextPart_001_01C081D7.59459CE0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] More beating my head against the wall....</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>You are preaching to the choir, as you fully well know.</FONT>
<BR><FONT SIZE=2>My point was, is there quantitative justification for the statement you</FONT>
<BR><FONT SIZE=2>made that MIP is too slow?</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Phil_Neumiller@3Com.com [<A HREF="mailto:Phil_Neumiller@3Com.com">mailto:Phil_Neumiller@3Com.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, January 18, 2001 3:38 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Cc: seamoby@diameter.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [seamoby] More beating my head against the wall....</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Sent by:&nbsp; &quot;Gary Kenward&quot; &lt;gkenward@nortelnetworks.com&gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; *snip*</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I would tend to agree with you Phil, but do we have tangible </FONT>
<BR><FONT SIZE=2>&gt; evidence that</FONT>
<BR><FONT SIZE=2>&gt; the MIP routing is too slow, and the routing at the edge is </FONT>
<BR><FONT SIZE=2>&gt; required? I</FONT>
<BR><FONT SIZE=2>&gt; *believe*</FONT>
<BR><FONT SIZE=2>&gt; it is a problem, but I suspect the claim would be contentious without</FONT>
<BR><FONT SIZE=2>&gt; numbers.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;If it were not slow (my measurements done about 2 years </FONT>
<BR><FONT SIZE=2>&gt; back indicated</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;that it was), why would the MIP group be so actively pursuing fast</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;handoff?&nbsp; My REAL belief is that fast hand off work belongs in</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;SeaMoby.&nbsp; That is if you are willing to seperate the world into</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;Core routing (mobile IP) and edge tunnelling (SeaMoby).&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; This type of</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;division of labor makes MUCH more sense to me technically, but the</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;politics of such a reorganization make its possibility of </FONT>
<BR><FONT SIZE=2>&gt; existence</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;tenuous.&nbsp; Just think how the MIP group would be free to </FONT>
<BR><FONT SIZE=2>&gt; worry about</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;optimizing the router chains for mobility rather than edge device</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;junk.&nbsp; SeaMoby would only have to worry about eventually sending a</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;new MIP registration while a temporary tunnel keeps the connection</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;seamless.&nbsp; Perhaps I really am wacked, but this is the way I see</FONT>
<BR><FONT SIZE=2>&gt; pdn&gt;it.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C081D7.59459CE0--


From owner-seamoby@diameter.org  Fri Jan 19 05:45:01 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA26978
	for <seamoby-archive@odin.ietf.org>; Fri, 19 Jan 2001 05:45:00 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0J7ul501892
	for seamoby-list; Thu, 18 Jan 2001 23:56:47 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0J7uho01887
	for <seamoby@diameter.org>; Thu, 18 Jan 2001 23:56:45 -0800
Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0J73wC03417
	for <seamoby@diameter.org>; Fri, 19 Jan 2001 09:03:58 +0200 (EET)
Received: from esebh01nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T5132b45f2cac158f22148@esvir02nok.nokia.com>;
 Fri, 19 Jan 2001 09:03:52 +0200
Received: by esebh01nok with Internet Mail Service (5.5.2652.78)
	id <C0KDMBVW>; Fri, 19 Jan 2001 09:03:52 +0200
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680A7C3@eseis04nok>
From: john.loughney@nokia.com
To: gkenward@nortelnetworks.com, seamoby@diameter.org
Subject: RE: [seamoby] micro, schmicro
Date: Fri, 19 Jan 2001 09:03:50 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Gary,

> Having said this, I would re-emphasize an earlier point made that I
> supported: SeaMoby
> does need to interoperate with MIP, but it should also be able to work
> without MIP (implying that the services provided by MIP are either not
> required or provided by another, possibly proprietary solution).

I think more importantly, as I said at the IETF in San Diego, I 
don't think any of us want to attend a BOF called 'Interworking
between SeaMoby & Mobile IP' ...

br,
John


From owner-seamoby@diameter.org  Fri Jan 19 05:50:17 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA27042
	for <seamoby-archive@odin.ietf.org>; Fri, 19 Jan 2001 05:50:17 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0J7vbq01901
	for seamoby-list; Thu, 18 Jan 2001 23:57:37 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0J7vXo01896
	for <seamoby@diameter.org>; Thu, 18 Jan 2001 23:57:34 -0800
Received: from melkinpaasi.cs.Helsinki.FI (jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.8.8/8.8.8) with ESMTP id JAA01745; Fri, 19 Jan 2001 09:04:51 +0200
Date: Fri, 19 Jan 2001 09:04:50 +0200 (EET)
From: Jukka Manner <jmanner@cs.helsinki.fi>
To: Zach Shelby <zach.shelby@vtt.fi>
cc: <seamoby@diameter.org>
Subject: Re: [seamoby] RE: Terminology draft
In-Reply-To: <149607601675.20010116110552@vtt.fi>
Message-ID: <Pine.LNX.4.30.0101190850280.15666-100000@melkinpaasi.cs.Helsinki.FI>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk


	Hi Zach,

	Thank you for your comments and support for the draft, we REALLY
appreciate it. Here are some answers to your comments.

	Regards,

	Jukka


On Tue, 16 Jan 2001, Zach Shelby wrote:

> After reviewing draft-brain-seamoby-terms-00.txt I find it to be an
> excellent compilation of very reasonable terminology and encourage all
> to get comments back to the authors on this.  Is it possible for this
> draft (or one similar) to go to RFC for seamoby?
>
> Comment. Add a section on synonyms, including all the alternative
> terms floating around our different backgrounds, with the appropriate
> equivalent term of the draft. BS = AP is a good start.

	I'm not sure whether that would be the best way. Maybe the descriptions
could be rephrased so that the synonyms would always be the last sentence of a
definition.

>
> Another. Section 2.2.1 (scope of handover) Add a "layer 2 handover"
> example situation to the appendix. I'm still not clear how this is a
> handover. If the same interface has multiple channels which the user
> can use, isn't that micro-diversity? Or should it could be called
> "layer 2 reconfiguration", or not be called at all.
>

	The layer 2 handover was meant to describe a handover between APs (or
"base-stations") which would not be directly visible at the IP-layers, for
example the IP-routing would not change. Of course every handover is at least
layer 2. The point is that the "serving AP" changes. In our work a layer 2
handover is not really needed, but was included in order to, hopefully, remove
confusion about terminology.



From owner-seamoby@diameter.org  Fri Jan 19 10:03:21 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00130
	for <seamoby-archive@odin.ietf.org>; Fri, 19 Jan 2001 10:03:21 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0JDQro02467
	for seamoby-list; Fri, 19 Jan 2001 05:26:53 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from c007.snv.cp.net (c007-h015.c007.snv.cp.net [209.228.33.222])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f0JDQpo02459
	for <seamoby@diameter.org>; Fri, 19 Jan 2001 05:26:51 -0800
Received: (cpmta 26051 invoked from network); 19 Jan 2001 04:34:10 -0800
Received: from dsl-64-193-0-129.telocity.com (HELO telocity.com) (64.193.0.129)
  by smtp.telocity.com (209.228.33.222) with SMTP; 19 Jan 2001 04:34:10 -0800
X-Sent: 19 Jan 2001 12:34:10 GMT
Message-ID: <3A6834A7.B6A360EE@telocity.com>
Date: Fri, 19 Jan 2001 06:35:51 -0600
From: Phil Neumiller <neumiller@telocity.com>
Organization: 3Com
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: c4mcr <cny@ieee.org>
CC: Gary Kenward <gkenward@nortelnetworks.com>, seamoby@diameter.org,
        pcalhoun@diameter.org
Subject: [seamoby] IIP, get it now at www.seamoby.org
References: <00aa01c081d2$bb738800$a52b9cca@yap>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello Chern,

Glad to see you back on the list even if it is just for
an advertisement.  :-)   Would you please consider adding
the following link http://www.diameter.org/seamoby.html
to your web site that www.seamoby.org points to?

Thank you,

Phil Neumiller
SeaMoby Evangelist at Large (SEAL - ork, ork, ork)
(or is that "Large" SeaMoby Evangelist)

> c4mcr wrote:
> 
> Hi
> 
> MIPv4 is known to have triangular routing problem.
> (Yes, there are many papers you can refer to)
> Solution: Host based routing.
> 
> "Only one solution exist that does not need host based routing and
> yet resolve most triangular routing problem --> IIP"
> 
> Moving to MIPv6?
> Reinvented Host based routing
> (Get away with it, since not many people is it)
> Does Yahoo and many millions of server support it?
> They eventually will, but when? Do you have patient to wait? :)
> 
> "Only one solution exist that allows you to migrate from IPv4 to IPv6
> without the pain --> IIP"
> 
> Cheers
> Chern Nam Yap


From owner-seamoby@diameter.org  Fri Jan 19 12:59:38 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03430
	for <seamoby-archive@odin.ietf.org>; Fri, 19 Jan 2001 12:59:37 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0JFxTV02814
	for seamoby-list; Fri, 19 Jan 2001 07:59:29 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from sirius.ctr.columbia.edu (sirius.ctr.columbia.edu [128.59.64.60])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0JFxQo02809
	for <seamoby@diameter.org>; Fri, 19 Jan 2001 07:59:26 -0800
Received: from SWEETPEA (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with SMTP id KAA18261; Fri, 19 Jan 2001 10:06:31 -0500 (EST)
From: "Andrew T. Campbell" <campbell@comet.columbia.edu>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>, <Phil_Neumiller@3Com.com>
Cc: <seamoby@diameter.org>
Subject: RE: [seamoby] More beating my head against the wall....
Date: Fri, 19 Jan 2001 10:05:43 -0800
Message-ID: <00a001c08242$711d4550$3d443b80@SWEETPEA>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00A1_01C081FF.62FA0550"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <13E2EF604DE5D111B2E50000F80824E8057A8B55@zwdld001.ca.nortel.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00A1_01C081FF.62FA0550
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: [seamoby] More beating my head against the wall....

---
Andrew
http://comet.columbia.edu/~campbell

  -----Original Message-----
  From: owner-seamoby@diameter.org [mailto:owner-seamoby@diameter.org]On
Behalf Of Gary Kenward
  Sent: Thursday, January 18, 2001 9:19 PM
  To: 'Phil_Neumiller@3Com.com'
  Cc: seamoby@diameter.org
  Subject: RE: [seamoby] More beating my head against the wall....


  You are preaching to the choir, as you fully well know.
  My point was, is there quantitative justification for the statement you
  made that MIP is too slow?
  [Andrew T. Campbell]

  Nop!

  Gary

  > -----Original Message-----
  > From: Phil_Neumiller@3Com.com [mailto:Phil_Neumiller@3Com.com]
  > Sent: Thursday, January 18, 2001 3:38 PM
  > To: Kenward, Gary [WDLN2:AN10:EXCH]
  > Cc: seamoby@diameter.org
  > Subject: RE: [seamoby] More beating my head against the wall....
  >
  >
  >
  >
  >
  >
  >
  >
  > Sent by:  "Gary Kenward" <gkenward@nortelnetworks.com>
  >
  > *snip*
  >
  >
  > I would tend to agree with you Phil, but do we have tangible
  > evidence that
  > the MIP routing is too slow, and the routing at the edge is
  > required? I
  > *believe*
  > it is a problem, but I suspect the claim would be contentious without
  > numbers.
  >
  > pdn>If it were not slow (my measurements done about 2 years
  > back indicated
  > pdn>that it was), why would the MIP group be so actively pursuing fast
  > pdn>handoff?  My REAL belief is that fast hand off work belongs in
  > pdn>SeaMoby.  That is if you are willing to seperate the world into
  > pdn>Core routing (mobile IP) and edge tunnelling (SeaMoby).
  > This type of
  > pdn>division of labor makes MUCH more sense to me technically, but the
  > pdn>politics of such a reorganization make its possibility of
  > existence
  > pdn>tenuous.  Just think how the MIP group would be free to
  > worry about
  > pdn>optimizing the router chains for mobility rather than edge device
  > pdn>junk.  SeaMoby would only have to worry about eventually sending a
  > pdn>new MIP registration while a temporary tunnel keeps the connection
  > pdn>seamless.  Perhaps I really am wacked, but this is the way I see
  > pdn>it.
  >
  >
  >
  >


------=_NextPart_000_00A1_01C081FF.62FA0550
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: [seamoby] More beating my head against the wall....</TITLE>

<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<P><FONT face=3DArial size=3D2>---</FONT> <BR><FONT face=3DArial =
size=3D2>Andrew</FONT>=20
<BR><FONT face=3DArial size=3D2><A =
href=3D"http://comet.columbia.edu/~campbell"=20
target=3D_blank>http://comet.columbia.edu/~campbell</A></FONT> </P>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
owner-seamoby@diameter.org=20
  [mailto:owner-seamoby@diameter.org]<B>On Behalf Of </B>Gary=20
  Kenward<BR><B>Sent:</B> Thursday, January 18, 2001 9:19 =
PM<BR><B>To:</B>=20
  'Phil_Neumiller@3Com.com'<BR><B>Cc:</B>=20
  seamoby@diameter.org<BR><B>Subject:</B> RE: [seamoby] More beating my =
head=20
  against the wall....<BR><BR></DIV></FONT>
  <P><FONT size=3D2>You are preaching to the choir, as you fully well =
know.</FONT>=20
  <BR><FONT size=3D2>My point was, is there quantitative justification =
for the=20
  statement you</FONT> <BR><FONT size=3D2>made that MIP is too =
slow?</FONT>=20
  <BR><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D330320518-19012001>[Andrew T. =
Campbell]&nbsp;</SPAN></FONT></P>
  <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D330320518-19012001>Nop!&nbsp;</SPAN></FONT></P>
  <P><FONT size=3D2>Gary</FONT> </P>
  <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
  From: Phil_Neumiller@3Com.com [<A=20
  =
href=3D"mailto:Phil_Neumiller@3Com.com">mailto:Phil_Neumiller@3Com.com</A=
>]</FONT>=20
  <BR><FONT size=3D2>&gt; Sent: Thursday, January 18, 2001 3:38 =
PM</FONT>=20
  <BR><FONT size=3D2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]</FONT> =
<BR><FONT=20
  size=3D2>&gt; Cc: seamoby@diameter.org</FONT> <BR><FONT size=3D2>&gt; =
Subject: RE:=20
  [seamoby] More beating my head against the wall....</FONT> <BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; Sent by:&nbsp; "Gary Kenward"=20
  &lt;gkenward@nortelnetworks.com&gt;</FONT> <BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; *snip*</FONT> <BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; I would =
tend to=20
  agree with you Phil, but do we have tangible </FONT><BR><FONT =
size=3D2>&gt;=20
  evidence that</FONT> <BR><FONT size=3D2>&gt; the MIP routing is too =
slow, and=20
  the routing at the edge is </FONT><BR><FONT size=3D2>&gt; required? =
I</FONT>=20
  <BR><FONT size=3D2>&gt; *believe*</FONT> <BR><FONT size=3D2>&gt; it is =
a problem,=20
  but I suspect the claim would be contentious without</FONT> <BR><FONT=20
  size=3D2>&gt; numbers.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  pdn&gt;If it were not slow (my measurements done about 2 years=20
  </FONT><BR><FONT size=3D2>&gt; back indicated</FONT> <BR><FONT =
size=3D2>&gt;=20
  pdn&gt;that it was), why would the MIP group be so actively pursuing=20
  fast</FONT> <BR><FONT size=3D2>&gt; pdn&gt;handoff?&nbsp; My REAL =
belief is that=20
  fast hand off work belongs in</FONT> <BR><FONT size=3D2>&gt;=20
  pdn&gt;SeaMoby.&nbsp; That is if you are willing to seperate the world =

  into</FONT> <BR><FONT size=3D2>&gt; pdn&gt;Core routing (mobile IP) =
and edge=20
  tunnelling (SeaMoby).&nbsp; </FONT><BR><FONT size=3D2>&gt; This type =
of</FONT>=20
  <BR><FONT size=3D2>&gt; pdn&gt;division of labor makes MUCH more sense =
to me=20
  technically, but the</FONT> <BR><FONT size=3D2>&gt; pdn&gt;politics of =
such a=20
  reorganization make its possibility of </FONT><BR><FONT size=3D2>&gt;=20
  existence</FONT> <BR><FONT size=3D2>&gt; pdn&gt;tenuous.&nbsp; Just =
think how=20
  the MIP group would be free to </FONT><BR><FONT size=3D2>&gt; worry =
about</FONT>=20
  <BR><FONT size=3D2>&gt; pdn&gt;optimizing the router chains for =
mobility rather=20
  than edge device</FONT> <BR><FONT size=3D2>&gt; pdn&gt;junk.&nbsp; =
SeaMoby would=20
  only have to worry about eventually sending a</FONT> <BR><FONT =
size=3D2>&gt;=20
  pdn&gt;new MIP registration while a temporary tunnel keeps the=20
  connection</FONT> <BR><FONT size=3D2>&gt; pdn&gt;seamless.&nbsp; =
Perhaps I=20
  really am wacked, but this is the way I see</FONT> <BR><FONT =
size=3D2>&gt;=20
  pdn&gt;it.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt;=20
</FONT></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00A1_01C081FF.62FA0550--



From owner-seamoby@diameter.org  Fri Jan 19 13:39:06 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03983
	for <seamoby-archive@odin.ietf.org>; Fri, 19 Jan 2001 13:39:05 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0JIQRv03291
	for seamoby-list; Fri, 19 Jan 2001 10:26:27 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0JIQOo03286
	for <seamoby@diameter.org>; Fri, 19 Jan 2001 10:26:24 -0800
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Fri, 19 Jan 2001 12:33:25 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <DGL465SA>; Fri, 19 Jan 2001 12:33:27 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8B5C@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>,
        seamoby@diameter.org
Subject: RE: [seamoby] micro, schmicro
Date: Fri, 19 Jan 2001 12:33:24 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0823D.ECF8ACF0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0823D.ECF8ACF0
Content-Type: text/plain;
	charset="iso-8859-1"

I'm not sure that you intended your comment to be humorous, but it 
brought a smile to my face.

I definitely agree.
Gary

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Friday, January 19, 2001 2:04 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@diameter.org
> Subject: RE: [seamoby] micro, schmicro
> 
> 
> Hi Gary,
> 
> > Having said this, I would re-emphasize an earlier point made that I
> > supported: SeaMoby
> > does need to interoperate with MIP, but it should also be 
> able to work
> > without MIP (implying that the services provided by MIP are 
> either not
> > required or provided by another, possibly proprietary solution).
> 
> I think more importantly, as I said at the IETF in San Diego, I 
> don't think any of us want to attend a BOF called 'Interworking
> between SeaMoby & Mobile IP' ...
> 
> br,
> John
> 

------_=_NextPart_001_01C0823D.ECF8ACF0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] micro, schmicro</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I'm not sure that you intended your comment to be humorous, but it </FONT>
<BR><FONT SIZE=2>brought a smile to my face.</FONT>
</P>

<P><FONT SIZE=2>I definitely agree.</FONT>
<BR><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: john.loughney@nokia.com [<A HREF="mailto:john.loughney@nokia.com">mailto:john.loughney@nokia.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Friday, January 19, 2001 2:04 AM</FONT>
<BR><FONT SIZE=2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@diameter.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [seamoby] micro, schmicro</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi Gary,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Having said this, I would re-emphasize an earlier point made that I</FONT>
<BR><FONT SIZE=2>&gt; &gt; supported: SeaMoby</FONT>
<BR><FONT SIZE=2>&gt; &gt; does need to interoperate with MIP, but it should also be </FONT>
<BR><FONT SIZE=2>&gt; able to work</FONT>
<BR><FONT SIZE=2>&gt; &gt; without MIP (implying that the services provided by MIP are </FONT>
<BR><FONT SIZE=2>&gt; either not</FONT>
<BR><FONT SIZE=2>&gt; &gt; required or provided by another, possibly proprietary solution).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I think more importantly, as I said at the IETF in San Diego, I </FONT>
<BR><FONT SIZE=2>&gt; don't think any of us want to attend a BOF called 'Interworking</FONT>
<BR><FONT SIZE=2>&gt; between SeaMoby &amp; Mobile IP' ...</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; br,</FONT>
<BR><FONT SIZE=2>&gt; John</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0823D.ECF8ACF0--


From owner-seamoby@diameter.org  Fri Jan 19 14:10:53 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04566
	for <seamoby-archive@odin.ietf.org>; Fri, 19 Jan 2001 14:10:53 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0JIq7H03326
	for seamoby-list; Fri, 19 Jan 2001 10:52:07 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0JIq5o03321
	for <seamoby@diameter.org>; Fri, 19 Jan 2001 10:52:05 -0800
Received: from agate.ops.3com.com (agate.3com.com [139.87.50.118])
	by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f0JHwI112524
	for <seamoby@diameter.org>; Fri, 19 Jan 2001 09:58:18 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104])
	by agate.ops.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f0JHxO207976
	for <seamoby@diameter.org>; Fri, 19 Jan 2001 09:59:24 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 882569D9.0062F6F4 ; Fri, 19 Jan 2001 10:00:57 -0800
X-Lotus-FromDomain: 3COM
From: Phil_Neumiller@3Com.com
To: seamoby@diameter.org
Message-ID: <882569D9.0062F45A.00@hqoutbound.ops.3com.com>
Date: Fri, 19 Jan 2001 12:05:00 -0600
Subject: [seamoby] [MOBILE-IP] BURP BOF
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-seamoby@diameter.org
Precedence: bulk



According to the description of this new BOF, mobile IP already provides
"seamless and continuous connectivity".  Hmm, what in the world
is SeaMoby for?

Creating a standardized registration protocol for the  application layer
makes a lot of sense.  Perhaps some of the UPnP/SLP work can be
useful here.


---------------------- Forwarded by Phil Neumiller/MW/US/3Com on 01/19/2001
11:48 AM ---------------------------

Please respond to Basavaraj.Patil@nokia.com

Sent by:  Basavaraj Patil <Basavaraj.Patil@nokia.com>


A BOF on Basic User Registration Protocol (BURP)


Charter:

The vision of pervasive computing also includes constantly being
connected and the ability to access the Internet or the enterprise
over the Internet. Mobile computing solutions based on protocols such
as Mobile IP offer seamless and continuous connectivity for
users. However a lot of roadwarriors and other types
of users access the network from places like airports, hotels, malls
and sports complexes. These environments may offer access to the
network over wireless LANs or via Ethernet LAN ports or other
mediums. In such scenarios,
DHCP can provide configuration information  (e.g., giving a valid
address etc.), but there is no standard way for service providers to
obtain user information to perform AAA functions. For users
who do not have Mobile IP clients on their devices but would like to
access the network, they need to register and be authenticated by the
local network service provider before being authorized to use the
resources. The intent of this proposal is to develop an application
layer registration protocol that allows a user to register in the
local network by providing identity and authentication information
to the local network which then uses a AAA infrastructure to validate
the user, charge him and, authorize use of resources.

We would like to request a BOF on a "Basic User Registration
Protocol (BURP)" for the March 2001 meeting of the IETF in Minneapolis.
The objective of the BOF will be to
-- Detail the scope of the proposal and applicable scenarios

-- Chart a course and an action plan (including milestones
and deliverables) for BURP.

-- Investigate  the impact on existing  AAA  protocols  and  make it
flexible to support various authentication schemes.

The goal will be to define a standard UNI for  environments in which
neither PPP nor Mobile IP is required but AAA interaction is
essential.  The basic principle will include:

  -- The solution being a client-server application layer protocol

  -- Is applicable to both IPv4 and IPv6.

  -- User interacts only with a local Registration Agent (RA), which
  may reside on any node in the Network Domain.

  -- It should work with any configuration  protocol, such as DHCP, IPv6
  stateless autoconfiguration, and manual configuration.

  -- Protects RA from replay attacks.

  -- Provide information on and control of network usage.

  -- Interacts with routers/policers to limit packets forwarding based on a
  user's Service Level  Specification  (may be optional or may
  interwork with  standard policy protocols).

  -- Defines an RA-to-AAA interface

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

To subscribe to the mailing list for discussion on this topic, please
follow these instructions:

To subscribe, send mail to urp-request@research.telcordia.com, and
use "subscribe" for the subject line.

To unsubscribe, send mail to urp-request@research.telcordia.com, and
use "unsubscribe" for the subject line.

To contribute to the list, send mail to urp@research.telcordia.com.

For additional help, send mail to urp-request@research.telcordia.com
and use "help" for the subject line.





From owner-seamoby@diameter.org  Fri Jan 19 14:26:10 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04860
	for <seamoby-archive@odin.ietf.org>; Fri, 19 Jan 2001 14:26:09 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0JJI7e03386
	for seamoby-list; Fri, 19 Jan 2001 11:18:07 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0JJI3o03375
	for <Seamoby@diameter.org>; Fri, 19 Jan 2001 11:18:03 -0800
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA29213;
	Fri, 19 Jan 2001 10:25:11 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA18359;
	Fri, 19 Jan 2001 10:25:09 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA13589;
	Fri, 19 Jan 2001 10:24:58 -0800 (PST)
Date: Fri, 19 Jan 2001 10:21:13 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [seamoby-mm] RE: [seamoby] micro, schmicro
To: Guilhem Tardy <guilhem.tardy@nortelnetworks.com>
Cc: Gary Kenward <gkenward@nortelnetworks.com>,
        "'Seamoby@diameter.org'" <Seamoby@diameter.org>,
        "'seamoby-mm@cdma-2000.org'" <seamoby-mm@cdma-2000.org>
In-Reply-To: "Your message with ID" <13E2EF604DE5D111B2E50000F80824E8069FF561@zwdld001.ca.nortel.com>
Message-ID: <Roam.SIMC.2.0.6.979928473.24958.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

>  
> Still I don't buy the MIP/edge mobility terms, for the reason that it
> defines Seamoby as a son of MIP, while it should be totally orthogonal to
> any 'inter-domain' mobility solution in my opinion, as it should be totally
> orthogonal to any link-layer mobility solution, too. Which doesn't preclude
> interactions with those other mobility solutions, of course.

No this doesn't make Seamoby as a son of MIP, it sets the scope of the handoff
to what Mobile IP doesn't address, and that is local changes of point of
attachments that do not require an address change.

This is actually a workable work item, so I don't understand the objection.

PatC



From owner-seamoby@diameter.org  Fri Jan 19 14:46:43 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05202
	for <seamoby-archive@odin.ietf.org>; Fri, 19 Jan 2001 14:46:42 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0JJCu103353
	for seamoby-list; Fri, 19 Jan 2001 11:12:56 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from sirius.ctr.columbia.edu (sirius.ctr.columbia.edu [128.59.64.60])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0JJCqo03348
	for <seamoby@diameter.org>; Fri, 19 Jan 2001 11:12:52 -0800
Received: from SWEETPEA (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with SMTP id NAA25422 for <seamoby@diameter.org>; Fri, 19 Jan 2001 13:20:16 -0500 (EST)
From: "Andrew T. Campbell" <campbell@comet.columbia.edu>
To: <seamoby@diameter.org>
Subject: RE: [seamoby] More beating my head against the wall....
Date: Fri, 19 Jan 2001 13:19:27 -0800
Message-ID: <00c701c0825d$81a50960$3d443b80@SWEETPEA>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00C8_01C0821A.7381C960"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-seamoby@diameter.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00C8_01C0821A.7381C960
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: [seamoby] More beating my head against the wall....


    -----Original Message-----
    From: owner-seamoby@diameter.org [mailto:owner-seamoby@diameter.org]On
Behalf Of Gary Kenward
    Sent: Thursday, January 18, 2001 9:19 PM
    To: 'Phil_Neumiller@3Com.com'
    Cc: seamoby@diameter.org
    Subject: RE: [seamoby] More beating my head against the wall....


    You are preaching to the choir, as you fully well know.
    My point was, is there quantitative justification for the statement you
    made  that MIP is too slow?
    [Andrew T. Campbell]

    I should of added (to my Nop) that CIP is fast but you can tune MIP to
operate "fast" but

    there are penalties to doing that; hence the need for edge mobility.


------=_NextPart_000_00C8_01C0821A.7381C960
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: [seamoby] More beating my head against the wall....</TITLE>

<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px">
  <P>&nbsp;</P>
  <BLOCKQUOTE=20
  style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; =
MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> =
owner-seamoby@diameter.org=20
    [mailto:owner-seamoby@diameter.org]<B>On Behalf Of </B>Gary=20
    Kenward<BR><B>Sent:</B> Thursday, January 18, 2001 9:19 =
PM<BR><B>To:</B>=20
    'Phil_Neumiller@3Com.com'<BR><B>Cc:</B>=20
    seamoby@diameter.org<BR><B>Subject:</B> RE: [seamoby] More beating =
my head=20
    against the wall....<BR><BR></DIV></FONT>
    <P><FONT size=3D2>You are preaching to the choir, as you fully well=20
    know.</FONT> <BR><FONT size=3D2>My point was, is there quantitative=20
    justification for the statement you</FONT> <BR><FONT=20
    size=3D2>made&nbsp;</FONT><FONT size=3D2><SPAN=20
    class=3D412290618-19012001>&nbsp;</SPAN>that MIP is too slow?</FONT> =
<BR><FONT=20
    color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D412290618-19012001>[Andrew T.=20
    Campbell]&nbsp;</SPAN></FONT></P>
    <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D412290618-19012001>I=20
    should of added (to my Nop) that CIP is fast but you can tune MIP=20
    to</SPAN></FONT><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D412290618-19012001>&nbsp;operate "fast"&nbsp;but =
</SPAN></FONT></P>
    <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D412290618-19012001>there are penalties to doing&nbsp;that; =
hence the=20
    need for edge=20
mobility.&nbsp;</SPAN></FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>=


------=_NextPart_000_00C8_01C0821A.7381C960--



From owner-seamoby@diameter.org  Fri Jan 19 14:47:07 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05213
	for <seamoby-archive@odin.ietf.org>; Fri, 19 Jan 2001 14:47:07 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0JJGUp03368
	for seamoby-list; Fri, 19 Jan 2001 11:16:30 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0JJGRo03357
	for <Seamoby@diameter.org>; Fri, 19 Jan 2001 11:16:27 -0800
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA28238;
	Fri, 19 Jan 2001 10:23:43 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA17882;
	Fri, 19 Jan 2001 10:22:58 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA13555;
	Fri, 19 Jan 2001 10:22:49 -0800 (PST)
Date: Fri, 19 Jan 2001 10:19:05 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: RE: [seamoby] micro, schmicro
To: Guilhem Tardy <guilhem.tardy@nortelnetworks.com>
Cc: Gary Kenward <gkenward@nortelnetworks.com>,
        "'Dana L. Blair'" <dblair@cisco.com>,
        Phil Neumiller <neumiller@telocity.com>, jaakko.sundquist@nokia.com,
        Seamoby@diameter.org, seamoby-mm@cdma-2000.org
In-Reply-To: "Your message with ID" <13E2EF604DE5D111B2E50000F80824E8069FF55F@zwdld001.ca.nortel.com>
Message-ID: <Roam.SIMC.2.0.6.979928345.23923.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

> 
>    What not be clear and use "MIP" and "edge mobility"?  
> 
> This would make MIP as the official inter-domain mobility solution for
> Seamoby. 

No, that would make MIP the official inter-domain mobility solution for the 
IETF, which it already is. Attempting to solve this problem again will most
certainly be shot down by the IESG.

I think that the IESG's message is pretty clear. We need to work on problems
that are NOT already being worked on in the Mobile IP WG. 

Using statements like complexity is a red-herring. I've implemented Mobile IP,
and it really isn't that complex. Any piece of code is complex, so I would
argue that it will be very hard to justify another protocol to solve non edge
routing.

PatC



From owner-seamoby@diameter.org  Fri Jan 19 14:47:21 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05229
	for <seamoby-archive@odin.ietf.org>; Fri, 19 Jan 2001 14:47:20 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0JJgif03491
	for seamoby-list; Fri, 19 Jan 2001 11:42:44 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0JJggo03486
	for <seamoby@diameter.org>; Fri, 19 Jan 2001 11:42:42 -0800
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05093;
	Fri, 19 Jan 2001 10:49:34 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA22167;
	Fri, 19 Jan 2001 10:37:15 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA13807;
	Fri, 19 Jan 2001 10:37:14 -0800 (PST)
Date: Fri, 19 Jan 2001 10:33:29 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [seamoby] More beating my head against the wall....
To: c4mcr <cny@ieee.org>
Cc: Gary Kenward <gkenward@nortelnetworks.com>, seamoby@diameter.org
In-Reply-To: "Your message with ID" <00aa01c081d2$bb738800$a52b9cca@yap>
Message-ID: <Roam.SIMC.2.0.6.979929209.29550.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

> Solution: Host based routing.
  ^^^^^^^^

Now that you've proposed a solution, perhaps you can enlighten us on what the
actual problem is.

PatC



From owner-seamoby@diameter.org  Fri Jan 19 14:48:10 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05259
	for <seamoby-archive@odin.ietf.org>; Fri, 19 Jan 2001 14:48:09 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0JJabE03455
	for seamoby-list; Fri, 19 Jan 2001 11:36:37 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0JJaXo03446
	for <Seamoby@diameter.org>; Fri, 19 Jan 2001 11:36:33 -0800
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Fri, 19 Jan 2001 13:43:35 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <DGL4670X>; Fri, 19 Jan 2001 13:43:37 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8069FF579@zwdld001.ca.nortel.com>
From: "Guilhem Tardy" <guilhem.tardy@nortelnetworks.com>
To: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>
Cc: "Gary Kenward" <gkenward@nortelnetworks.com>,
        "'Dana L. Blair'" <dblair@cisco.com>,
        Phil Neumiller <neumiller@telocity.com>, jaakko.sundquist@nokia.com,
        Seamoby@diameter.org, seamoby-mm@cdma-2000.org
Subject: RE: [seamoby] micro, schmicro
Date: Fri, 19 Jan 2001 13:43:29 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C08247.B7565070"
X-Orig: <guilhem.tardy@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C08247.B7565070
Content-Type: text/plain;
	charset="iso-8859-1"

Pat,

You don't need Seamoby to make MIP the official IETF inter-domain solution
(I hope). But there will always be non-standard, private solutions aside of
the official one. Therefore I stand by my point.

I agree that Seamoby must NOT attempt to solve the inter-domain mobility
problem again. I have actually stated this several times in the mailing
list. You were probably answering to someone else in your second paragraph
and on.

Guilhem.

> -----Original Message-----
> From: Pat Calhoun [mailto:Pat.Calhoun@Eng.Sun.COM]
> Sent: Friday, January 19, 2001 1:19 PM
> To: Tardy, Guilhem [WDLN2:AN33:EXCH]
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'Dana L. Blair'; Phil Neumiller;
> jaakko.sundquist@nokia.com; Seamoby@diameter.org;
> seamoby-mm@cdma-2000.org
> Subject: RE: [seamoby] micro, schmicro
> 
> 
> > 
> >    What not be clear and use "MIP" and "edge mobility"?  
> > 
> > This would make MIP as the official inter-domain mobility 
> solution for
> > Seamoby. 
> 
> No, that would make MIP the official inter-domain mobility 
> solution for the 
> IETF, which it already is. Attempting to solve this problem 
> again will most
> certainly be shot down by the IESG.
> 
> I think that the IESG's message is pretty clear. We need to 
> work on problems
> that are NOT already being worked on in the Mobile IP WG. 
> 
> Using statements like complexity is a red-herring. I've 
> implemented Mobile IP,
> and it really isn't that complex. Any piece of code is 
> complex, so I would
> argue that it will be very hard to justify another protocol 
> to solve non edge
> routing.
> 
> PatC
> 
> 

------_=_NextPart_001_01C08247.B7565070
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: [seamoby] micro, schmicro</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Pat,</FONT>
</P>

<P><FONT SIZE=3D2>You don't need Seamoby to make MIP the official IETF =
inter-domain solution (I hope). But there will always be non-standard, =
private solutions aside of the official one. Therefore I stand by my =
point.</FONT></P>

<P><FONT SIZE=3D2>I agree that Seamoby must NOT attempt to solve the =
inter-domain mobility problem again. I have actually stated this =
several times in the mailing list. You were probably answering to =
someone else in your second paragraph and on.</FONT></P>

<P><FONT SIZE=3D2>Guilhem.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Pat Calhoun [<A =
HREF=3D"mailto:Pat.Calhoun@Eng.Sun.COM">mailto:Pat.Calhoun@Eng.Sun.COM</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, January 19, 2001 1:19 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Tardy, Guilhem [WDLN2:AN33:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'Dana L. =
Blair'; Phil Neumiller;</FONT>
<BR><FONT SIZE=3D2>&gt; jaakko.sundquist@nokia.com; =
Seamoby@diameter.org;</FONT>
<BR><FONT SIZE=3D2>&gt; seamoby-mm@cdma-2000.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [seamoby] micro, schmicro</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; What not be clear and =
use &quot;MIP&quot; and &quot;edge mobility&quot;?&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; This would make MIP as the official =
inter-domain mobility </FONT>
<BR><FONT SIZE=3D2>&gt; solution for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Seamoby. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; No, that would make MIP the official =
inter-domain mobility </FONT>
<BR><FONT SIZE=3D2>&gt; solution for the </FONT>
<BR><FONT SIZE=3D2>&gt; IETF, which it already is. Attempting to solve =
this problem </FONT>
<BR><FONT SIZE=3D2>&gt; again will most</FONT>
<BR><FONT SIZE=3D2>&gt; certainly be shot down by the IESG.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think that the IESG's message is pretty =
clear. We need to </FONT>
<BR><FONT SIZE=3D2>&gt; work on problems</FONT>
<BR><FONT SIZE=3D2>&gt; that are NOT already being worked on in the =
Mobile IP WG. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Using statements like complexity is a =
red-herring. I've </FONT>
<BR><FONT SIZE=3D2>&gt; implemented Mobile IP,</FONT>
<BR><FONT SIZE=3D2>&gt; and it really isn't that complex. Any piece of =
code is </FONT>
<BR><FONT SIZE=3D2>&gt; complex, so I would</FONT>
<BR><FONT SIZE=3D2>&gt; argue that it will be very hard to justify =
another protocol </FONT>
<BR><FONT SIZE=3D2>&gt; to solve non edge</FONT>
<BR><FONT SIZE=3D2>&gt; routing.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; PatC</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C08247.B7565070--


From owner-seamoby@diameter.org  Fri Jan 19 14:50:13 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05306
	for <seamoby-archive@odin.ietf.org>; Fri, 19 Jan 2001 14:50:12 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0JJXse03439
	for seamoby-list; Fri, 19 Jan 2001 11:33:54 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0JJXpo03434
	for <seamoby@diameter.org>; Fri, 19 Jan 2001 11:33:52 -0800
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Fri, 19 Jan 2001 13:39:48 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <DGL46755>; Fri, 19 Jan 2001 13:39:50 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057865C2@zwdld001.ca.nortel.com>
From: "Kumarathasan Ampalavanapillai" <kampala@nortelnetworks.com>
To: "'Phil_Neumiller@3Com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
Subject: RE: [seamoby] [MOBILE-IP] BURP BOF
Date: Fri, 19 Jan 2001 13:39:41 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C08247.2F514CC0"
X-Orig: <kampala@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C08247.2F514CC0
Content-Type: text/plain;
	charset="iso-8859-1"

If I understand this right.....It looks like registering yourself in a new
network domain and staying there in that domain to use their
resources......When you go into a new domain you will have to register
yourself there again.....

Cheers,
Kumar A


The Contents of this Email are Nortel Networks Confidential.




-----Original Message-----
From: Phil_Neumiller@3Com.com [mailto:Phil_Neumiller@3Com.com]
Sent: Friday, January 19, 2001 1:05 PM
To: seamoby@diameter.org
Subject: [seamoby] [MOBILE-IP] BURP BOF




According to the description of this new BOF, mobile IP already provides
"seamless and continuous connectivity".  Hmm, what in the world
is SeaMoby for?

Creating a standardized registration protocol for the  application layer
makes a lot of sense.  Perhaps some of the UPnP/SLP work can be
useful here.


---------------------- Forwarded by Phil Neumiller/MW/US/3Com on 01/19/2001
11:48 AM ---------------------------

Please respond to Basavaraj.Patil@nokia.com

Sent by:  Basavaraj Patil <Basavaraj.Patil@nokia.com>


A BOF on Basic User Registration Protocol (BURP)


Charter:

The vision of pervasive computing also includes constantly being
connected and the ability to access the Internet or the enterprise
over the Internet. Mobile computing solutions based on protocols such
as Mobile IP offer seamless and continuous connectivity for
users. However a lot of roadwarriors and other types
of users access the network from places like airports, hotels, malls
and sports complexes. These environments may offer access to the
network over wireless LANs or via Ethernet LAN ports or other
mediums. In such scenarios,
DHCP can provide configuration information  (e.g., giving a valid
address etc.), but there is no standard way for service providers to
obtain user information to perform AAA functions. For users
who do not have Mobile IP clients on their devices but would like to
access the network, they need to register and be authenticated by the
local network service provider before being authorized to use the
resources. The intent of this proposal is to develop an application
layer registration protocol that allows a user to register in the
local network by providing identity and authentication information
to the local network which then uses a AAA infrastructure to validate
the user, charge him and, authorize use of resources.

We would like to request a BOF on a "Basic User Registration
Protocol (BURP)" for the March 2001 meeting of the IETF in Minneapolis.
The objective of the BOF will be to
-- Detail the scope of the proposal and applicable scenarios

-- Chart a course and an action plan (including milestones
and deliverables) for BURP.

-- Investigate  the impact on existing  AAA  protocols  and  make it
flexible to support various authentication schemes.

The goal will be to define a standard UNI for  environments in which
neither PPP nor Mobile IP is required but AAA interaction is
essential.  The basic principle will include:

  -- The solution being a client-server application layer protocol

  -- Is applicable to both IPv4 and IPv6.

  -- User interacts only with a local Registration Agent (RA), which
  may reside on any node in the Network Domain.

  -- It should work with any configuration  protocol, such as DHCP, IPv6
  stateless autoconfiguration, and manual configuration.

  -- Protects RA from replay attacks.

  -- Provide information on and control of network usage.

  -- Interacts with routers/policers to limit packets forwarding based on a
  user's Service Level  Specification  (may be optional or may
  interwork with  standard policy protocols).

  -- Defines an RA-to-AAA interface

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

To subscribe to the mailing list for discussion on this topic, please
follow these instructions:

To subscribe, send mail to urp-request@research.telcordia.com, and
use "subscribe" for the subject line.

To unsubscribe, send mail to urp-request@research.telcordia.com, and
use "unsubscribe" for the subject line.

To contribute to the list, send mail to urp@research.telcordia.com.

For additional help, send mail to urp-request@research.telcordia.com
and use "help" for the subject line.




------_=_NextPart_001_01C08247.2F514CC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: [seamoby] [MOBILE-IP] BURP BOF</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>If I understand this right.....It looks like =
registering yourself in a new network domain and staying there in that =
domain to use their resources......When you go into a new domain you =
will have to register yourself there again.....</FONT></P>

<P><FONT SIZE=3D2>Cheers,</FONT>
<BR><FONT SIZE=3D2>Kumar A</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>The Contents of this Email are Nortel Networks =
Confidential.</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Phil_Neumiller@3Com.com [<A =
HREF=3D"mailto:Phil_Neumiller@3Com.com">mailto:Phil_Neumiller@3Com.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, January 19, 2001 1:05 PM</FONT>
<BR><FONT SIZE=3D2>To: seamoby@diameter.org</FONT>
<BR><FONT SIZE=3D2>Subject: [seamoby] [MOBILE-IP] BURP BOF</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>According to the description of this new BOF, mobile =
IP already provides</FONT>
<BR><FONT SIZE=3D2>&quot;seamless and continuous =
connectivity&quot;.&nbsp; Hmm, what in the world</FONT>
<BR><FONT SIZE=3D2>is SeaMoby for?</FONT>
</P>

<P><FONT SIZE=3D2>Creating a standardized registration protocol for =
the&nbsp; application layer</FONT>
<BR><FONT SIZE=3D2>makes a lot of sense.&nbsp; Perhaps some of the =
UPnP/SLP work can be</FONT>
<BR><FONT SIZE=3D2>useful here.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>---------------------- Forwarded by Phil =
Neumiller/MW/US/3Com on 01/19/2001</FONT>
<BR><FONT SIZE=3D2>11:48 AM ---------------------------</FONT>
</P>

<P><FONT SIZE=3D2>Please respond to Basavaraj.Patil@nokia.com</FONT>
</P>

<P><FONT SIZE=3D2>Sent by:&nbsp; Basavaraj Patil =
&lt;Basavaraj.Patil@nokia.com&gt;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>A BOF on Basic User Registration Protocol =
(BURP)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Charter:</FONT>
</P>

<P><FONT SIZE=3D2>The vision of pervasive computing also includes =
constantly being</FONT>
<BR><FONT SIZE=3D2>connected and the ability to access the Internet or =
the enterprise</FONT>
<BR><FONT SIZE=3D2>over the Internet. Mobile computing solutions based =
on protocols such</FONT>
<BR><FONT SIZE=3D2>as Mobile IP offer seamless and continuous =
connectivity for</FONT>
<BR><FONT SIZE=3D2>users. However a lot of roadwarriors and other =
types</FONT>
<BR><FONT SIZE=3D2>of users access the network from places like =
airports, hotels, malls</FONT>
<BR><FONT SIZE=3D2>and sports complexes. These environments may offer =
access to the</FONT>
<BR><FONT SIZE=3D2>network over wireless LANs or via Ethernet LAN ports =
or other</FONT>
<BR><FONT SIZE=3D2>mediums. In such scenarios,</FONT>
<BR><FONT SIZE=3D2>DHCP can provide configuration information&nbsp; =
(e.g., giving a valid</FONT>
<BR><FONT SIZE=3D2>address etc.), but there is no standard way for =
service providers to</FONT>
<BR><FONT SIZE=3D2>obtain user information to perform AAA functions. =
For users</FONT>
<BR><FONT SIZE=3D2>who do not have Mobile IP clients on their devices =
but would like to</FONT>
<BR><FONT SIZE=3D2>access the network, they need to register and be =
authenticated by the</FONT>
<BR><FONT SIZE=3D2>local network service provider before being =
authorized to use the</FONT>
<BR><FONT SIZE=3D2>resources. The intent of this proposal is to develop =
an application</FONT>
<BR><FONT SIZE=3D2>layer registration protocol that allows a user to =
register in the</FONT>
<BR><FONT SIZE=3D2>local network by providing identity and =
authentication information</FONT>
<BR><FONT SIZE=3D2>to the local network which then uses a AAA =
infrastructure to validate</FONT>
<BR><FONT SIZE=3D2>the user, charge him and, authorize use of =
resources.</FONT>
</P>

<P><FONT SIZE=3D2>We would like to request a BOF on a &quot;Basic User =
Registration</FONT>
<BR><FONT SIZE=3D2>Protocol (BURP)&quot; for the March 2001 meeting of =
the IETF in Minneapolis.</FONT>
<BR><FONT SIZE=3D2>The objective of the BOF will be to</FONT>
<BR><FONT SIZE=3D2>-- Detail the scope of the proposal and applicable =
scenarios</FONT>
</P>

<P><FONT SIZE=3D2>-- Chart a course and an action plan (including =
milestones</FONT>
<BR><FONT SIZE=3D2>and deliverables) for BURP.</FONT>
</P>

<P><FONT SIZE=3D2>-- Investigate&nbsp; the impact on existing&nbsp; =
AAA&nbsp; protocols&nbsp; and&nbsp; make it</FONT>
<BR><FONT SIZE=3D2>flexible to support various authentication =
schemes.</FONT>
</P>

<P><FONT SIZE=3D2>The goal will be to define a standard UNI for&nbsp; =
environments in which</FONT>
<BR><FONT SIZE=3D2>neither PPP nor Mobile IP is required but AAA =
interaction is</FONT>
<BR><FONT SIZE=3D2>essential.&nbsp; The basic principle will =
include:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; -- The solution being a client-server =
application layer protocol</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; -- Is applicable to both IPv4 and IPv6.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; -- User interacts only with a local =
Registration Agent (RA), which</FONT>
<BR><FONT SIZE=3D2>&nbsp; may reside on any node in the Network =
Domain.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; -- It should work with any configuration&nbsp; =
protocol, such as DHCP, IPv6</FONT>
<BR><FONT SIZE=3D2>&nbsp; stateless autoconfiguration, and manual =
configuration.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; -- Protects RA from replay attacks.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; -- Provide information on and control of =
network usage.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; -- Interacts with routers/policers to limit =
packets forwarding based on a</FONT>
<BR><FONT SIZE=3D2>&nbsp; user's Service Level&nbsp; =
Specification&nbsp; (may be optional or may</FONT>
<BR><FONT SIZE=3D2>&nbsp; interwork with&nbsp; standard policy =
protocols).</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; -- Defines an RA-to-AAA interface</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
--------</FONT>
</P>

<P><FONT SIZE=3D2>To subscribe to the mailing list for discussion on =
this topic, please</FONT>
<BR><FONT SIZE=3D2>follow these instructions:</FONT>
</P>

<P><FONT SIZE=3D2>To subscribe, send mail to =
urp-request@research.telcordia.com, and</FONT>
<BR><FONT SIZE=3D2>use &quot;subscribe&quot; for the subject =
line.</FONT>
</P>

<P><FONT SIZE=3D2>To unsubscribe, send mail to =
urp-request@research.telcordia.com, and</FONT>
<BR><FONT SIZE=3D2>use &quot;unsubscribe&quot; for the subject =
line.</FONT>
</P>

<P><FONT SIZE=3D2>To contribute to the list, send mail to =
urp@research.telcordia.com.</FONT>
</P>

<P><FONT SIZE=3D2>For additional help, send mail to =
urp-request@research.telcordia.com</FONT>
<BR><FONT SIZE=3D2>and use &quot;help&quot; for the subject =
line.</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C08247.2F514CC0--


From owner-seamoby@diameter.org  Fri Jan 19 15:04:38 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05505
	for <seamoby-archive@odin.ietf.org>; Fri, 19 Jan 2001 15:04:38 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0JJdwJ03477
	for seamoby-list; Fri, 19 Jan 2001 11:39:58 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0JJdso03466
	for <Seamoby@diameter.org>; Fri, 19 Jan 2001 11:39:54 -0800
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA09615;
	Fri, 19 Jan 2001 10:46:57 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA24986;
	Fri, 19 Jan 2001 10:46:54 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA14090;
	Fri, 19 Jan 2001 10:46:52 -0800 (PST)
Date: Fri, 19 Jan 2001 10:43:07 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: RE: [seamoby] micro, schmicro
To: Guilhem Tardy <guilhem.tardy@nortelnetworks.com>
Cc: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        Gary Kenward <gkenward@nortelnetworks.com>,
        "'Dana L. Blair'" <dblair@cisco.com>,
        Phil Neumiller <neumiller@telocity.com>, jaakko.sundquist@nokia.com,
        Seamoby@diameter.org, seamoby-mm@cdma-2000.org
In-Reply-To: "Your message with ID" <13E2EF604DE5D111B2E50000F80824E8069FF579@zwdld001.ca.nortel.com>
Message-ID: <Roam.SIMC.2.0.6.979929787.3562.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

> Pat,
> 
> You don't need Seamoby to make MIP the official IETF inter-domain solution
> (I hope).
correct.

>  But there will always be non-standard, private solutions aside of
> the official one. Therefore I stand by my point.

correct, there will always be non-standard approaches, but these are out of
scope, and don't need to be discussed.

> 
> I agree that Seamoby must NOT attempt to solve the inter-domain mobility
> problem again. I have actually stated this several times in the mailing
> list. You were probably answering to someone else in your second paragraph
> and on.

Correct, and I appologize if you thought I was address you, I was actually
addressing the mailing list. I have finally caught up to my mail after a week
on the road, so I am trying to compile my thoughts into smaller number of
e-mails.

PatC



From owner-seamoby@diameter.org  Fri Jan 19 15:11:15 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05610
	for <seamoby-archive@odin.ietf.org>; Fri, 19 Jan 2001 15:11:15 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0JJjmu03500
	for seamoby-list; Fri, 19 Jan 2001 11:45:48 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0JJjko03495
	for <seamoby@diameter.org>; Fri, 19 Jan 2001 11:45:46 -0800
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11876;
	Fri, 19 Jan 2001 10:53:08 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA26442;
	Fri, 19 Jan 2001 10:51:58 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA14225;
	Fri, 19 Jan 2001 10:51:49 -0800 (PST)
Date: Fri, 19 Jan 2001 10:48:04 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [seamoby] Location finding methods versus MIP home agent.
To: Phil Neumiller <neumiller@telocity.com>
Cc: seamoby@diameter.org
In-Reply-To: "Your message with ID" <3A67A8A2.E58E42C@telocity.com>
Message-ID: <Roam.SIMC.2.0.6.979930084.13624.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

> Just some random thoughts....

which seem outsidce the scope of seamoby, but I'll respond anyways.

> 
> I see that a home agent (MIPv4/MIPv6) can help us find a MN
> with a static home address provided it registers when it moves
> from FA/COA(prefix) subnet to FA/COA(prefix) subnet.  This
> seems to replace the cellular equivalent of an HLR/VLR in the
> location sense, not the AAA.

Mobile IP also allows for a mobile to receive a dynamic home address. When
used with AAA, it even allows the user to be assigned a dynamic home agent. 

There are two components to HLR.VLR, and mobility management is really only
one of them. User authentication, by way of the authentication center, is
being replaced with AAA.

> 
> Also, one could image, an IP accessible HLR/VLR gateway.

No, the HLR/VLR is going away in the ALL IP cellular networks, and being
replaced with Mobile IP, for mobility management, and AAA, for authentication,
authorization and home agent assignment. > 
> One could also imagine dynamic DNS being able to handle this.

There are many that believe that once a mobile has been assigned a dynamic
home address, the home domain's DNS server is dynamically updated.

> 
> One could also imagine some sort of LDAP directory that helped
> locate mobiles.
? not sure that LDAP has to do here. 

PatC



From owner-seamoby@diameter.org  Sat Jan 20 12:31:16 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28649
	for <seamoby-archive@odin.ietf.org>; Sat, 20 Jan 2001 12:31:16 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0KGZn604492
	for seamoby-list; Sat, 20 Jan 2001 08:35:49 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from smtp1b.mail.yahoo.com (smtp3.mail.yahoo.com [128.11.68.135])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f0KGZjo04484
	for <seamoby@diameter.org>; Sat, 20 Jan 2001 08:35:45 -0800
Received: from mcns165.docsis43.singa.pore.net (HELO yap) (202.156.43.165)
  by smtp.mail.vip.suc.yahoo.com with SMTP; 20 Jan 2001 16:35:29 -0000
X-Apparently-From: <c4mcr@yahoo.co.uk>
Message-ID: <008001c082f7$d3061ca0$a52b9cca@yap>
Reply-To: "c4mcr" <cny@ieee.org>
From: "c4mcr" <c4mcr@yahoo.co.uk>
To: "Phil Neumiller" <neumiller@telocity.com>, "c4mcr" <cny@ieee.org>
Cc: "Gary Kenward" <gkenward@nortelnetworks.com>, <seamoby@diameter.org>,
        <pcalhoun@diameter.org>
Subject: [seamoby] Re: IIP, get it now at www.seamoby.org
Date: Sat, 20 Jan 2001 23:41:45 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Phil

Sure, that should not have any problem.
Anyway that is part of the plan, the web page currently is not finished.
Currently I am not in office.  Once that is done I will inform you about it

Cheers
Chern Nam



-----Original Message-----
From: Phil Neumiller <neumiller@telocity.com>
To: c4mcr <cny@ieee.org>
Cc: Gary Kenward <gkenward@nortelnetworks.com>; seamoby@diameter.org
<seamoby@diameter.org>; pcalhoun@diameter.org <pcalhoun@diameter.org>
Date: Friday, January 19, 2001 8:34 PM
Subject: IIP, get it now at www.seamoby.org


>Hello Chern,
>
>Glad to see you back on the list even if it is just for
>an advertisement.  :-)   Would you please consider adding
>the following link http://www.diameter.org/seamoby.html
>to your web site that www.seamoby.org points to?
>
>Thank you,
>
>Phil Neumiller
>SeaMoby Evangelist at Large (SEAL - ork, ork, ork)
>(or is that "Large" SeaMoby Evangelist)
>
>> c4mcr wrote:
>>
>> Hi
>>
>> MIPv4 is known to have triangular routing problem.
>> (Yes, there are many papers you can refer to)
>> Solution: Host based routing.
>>
>> "Only one solution exist that does not need host based routing and
>> yet resolve most triangular routing problem --> IIP"
>>
>> Moving to MIPv6?
>> Reinvented Host based routing
>> (Get away with it, since not many people is it)
>> Does Yahoo and many millions of server support it?
>> They eventually will, but when? Do you have patient to wait? :)
>>
>> "Only one solution exist that allows you to migrate from IPv4 to IPv6
>> without the pain --> IIP"
>>
>> Cheers
>> Chern Nam Yap




_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



From owner-seamoby@diameter.org  Sun Jan 21 11:35:13 2001
Received: from charizard.diameter.org ([24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09698
	for <seamoby-archive@odin.ietf.org>; Sun, 21 Jan 2001 11:35:07 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0LG0Da10538
	for seamoby-list; Sun, 21 Jan 2001 08:00:13 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from ns.kreative.net (root@ns.kreative.net [216.181.1.200])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0LG0Bo10533
	for <seamoby@diameter.org>; Sun, 21 Jan 2001 08:00:11 -0800
Received: from david (laurel-118.dsdial.net [209.12.175.118])
	by ns.kreative.net (8.9.3/8.9.3) with SMTP id KAA17694;
	Sun, 21 Jan 2001 10:16:31 -0500
Message-ID: <008d01c083bc$82ba1f60$0100000a@david>
From: "Dave Martin" <dmartin@kreative.net>
To: "Gary Kenward" <gkenward@nortelnetworks.com>, <Phil_Neumiller@3Com.com>
Cc: <seamoby@diameter.org>
References: <13E2EF604DE5D111B2E50000F80824E8057A8B55@zwdld001.ca.nortel.com>
Subject: Re: [seamoby] More beating my head against the wall....
Date: Sun, 21 Jan 2001 10:12:02 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_008A_01C08392.990B6AA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-seamoby@diameter.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_008A_01C08392.990B6AA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: [seamoby] More beating my head against the wall....In our current =
Mobile IP network (MIPv4), it takes several seconds (~3) to change FAs =
(COA).  L2 plays almost no part in this delay (our L2 *can* support =
realtime data traffic).  If necessary I can provide more detail on the =
delay budget, but I hope that we can agree that MIP as it is today would =
not support real time services (e.g. voice).

So I would content that MIP (current version) is too slow to support =
mobility between FAs.

I would also contend that MIP will probably always be too slow unless =
something is done to optimize the "edge" to bridge the gap while the =
"core" is updated with new routing information.  My definition of "edge" =
is the closest router to the mobile (AR), and my definition of core is =
the rest of the supporting network (HA, AAA, FA etc).

As a another voice in the choir ... I also believe that the fast-handoff =
work belongs in seamoby.

----- Original Message -----=20
  From: Gary Kenward=20
  To: 'Phil_Neumiller@3Com.com'=20
  Cc: seamoby@diameter.org=20
  Sent: Friday, January 19, 2001 12:19 AM
  Subject: RE: [seamoby] More beating my head against the wall....


  You are preaching to the choir, as you fully well know.=20
  My point was, is there quantitative justification for the statement =
you=20
  made that MIP is too slow?=20

  Gary=20

  > -----Original Message-----=20
  > From: Phil_Neumiller@3Com.com [mailto:Phil_Neumiller@3Com.com]=20
  > Sent: Thursday, January 18, 2001 3:38 PM=20
  > To: Kenward, Gary [WDLN2:AN10:EXCH]=20
  > Cc: seamoby@diameter.org=20
  > Subject: RE: [seamoby] More beating my head against the wall....=20
  >=20
  >=20
  >=20
  >=20
  >=20
  >=20
  >=20
  >=20
  > Sent by:  "Gary Kenward" <gkenward@nortelnetworks.com>=20
  >=20
  > *snip*=20
  >=20
  >=20
  > I would tend to agree with you Phil, but do we have tangible=20
  > evidence that=20
  > the MIP routing is too slow, and the routing at the edge is=20
  > required? I=20
  > *believe*=20
  > it is a problem, but I suspect the claim would be contentious =
without=20
  > numbers.=20
  >=20
  > pdn>If it were not slow (my measurements done about 2 years=20
  > back indicated=20
  > pdn>that it was), why would the MIP group be so actively pursuing =
fast=20
  > pdn>handoff?  My REAL belief is that fast hand off work belongs in=20
  > pdn>SeaMoby.  That is if you are willing to seperate the world into=20
  > pdn>Core routing (mobile IP) and edge tunnelling (SeaMoby). =20
  > This type of=20
  > pdn>division of labor makes MUCH more sense to me technically, but =
the=20
  > pdn>politics of such a reorganization make its possibility of=20
  > existence=20
  > pdn>tenuous.  Just think how the MIP group would be free to=20
  > worry about=20
  > pdn>optimizing the router chains for mobility rather than edge =
device=20
  > pdn>junk.  SeaMoby would only have to worry about eventually sending =
a=20
  > pdn>new MIP registration while a temporary tunnel keeps the =
connection=20
  > pdn>seamless.  Perhaps I really am wacked, but this is the way I see =

  > pdn>it.=20
  >=20
  >=20
  >=20
  >=20


------=_NextPart_000_008A_01C08392.990B6AA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [seamoby] More beating my head against the =
wall....</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>In our current Mobile IP network =
(MIPv4), it takes=20
several seconds (~3) to change FAs (COA).&nbsp; L2 plays almost no part =
in this=20
delay (our L2 *can* support realtime data traffic).&nbsp; If necessary I =
can=20
provide more detail on the delay budget, but I hope that we can agree =
that MIP=20
as it is today would not support real time services (e.g. =
voice).</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>So I would content that MIP (current =
version) is=20
too slow to support mobility between FAs.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I would also contend that MIP will =
probably always=20
be too slow unless something is done to optimize the "edge" to bridge =
the gap=20
while the "core"&nbsp;is updated with new routing information.&nbsp; My=20
definition of "edge" is the closest router to the&nbsp;mobile (AR), and =
my=20
definition of core is the rest of the supporting network (HA, AAA, FA=20
etc).</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>As a another voice in the choir ... I =
also believe=20
that the fast-handoff work belongs in seamoby.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>----- Original Message ----- </DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:gkenward@nortelnetworks.com"=20
  title=3Dgkenward@nortelnetworks.com>Gary Kenward</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  href=3D"mailto:'Phil_Neumiller@3Com.com'"=20
  title=3DPhil_Neumiller@3Com.com>'Phil_Neumiller@3Com.com'</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
href=3D"mailto:seamoby@diameter.org"=20
  title=3Dseamoby@diameter.org>seamoby@diameter.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, January 19, 2001 =
12:19=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: [seamoby] More =
beating my=20
  head against the wall....</DIV>
  <DIV><BR></DIV>
  <P><FONT size=3D2>You are preaching to the choir, as you fully well =
know.</FONT>=20
  <BR><FONT size=3D2>My point was, is there quantitative justification =
for the=20
  statement you</FONT> <BR><FONT size=3D2>made that MIP is too =
slow?</FONT> </P>
  <P><FONT size=3D2>Gary</FONT> </P>
  <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
  From: <A =
href=3D"mailto:Phil_Neumiller@3Com.com">Phil_Neumiller@3Com.com</A> [<A=20
  =
href=3D"mailto:Phil_Neumiller@3Com.com">mailto:Phil_Neumiller@3Com.com</A=
>]</FONT>=20
  <BR><FONT size=3D2>&gt; Sent: Thursday, January 18, 2001 3:38 =
PM</FONT>=20
  <BR><FONT size=3D2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]</FONT> =
<BR><FONT=20
  size=3D2>&gt; Cc: <A=20
  href=3D"mailto:seamoby@diameter.org">seamoby@diameter.org</A></FONT> =
<BR><FONT=20
  size=3D2>&gt; Subject: RE: [seamoby] More beating my head against the=20
  wall....</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =

  </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Sent =
by:&nbsp; "Gary=20
  Kenward" &lt;gkenward@nortelnetworks.com&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; *snip*</FONT> <BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; I would =
tend to=20
  agree with you Phil, but do we have tangible </FONT><BR><FONT =
size=3D2>&gt;=20
  evidence that</FONT> <BR><FONT size=3D2>&gt; the MIP routing is too =
slow, and=20
  the routing at the edge is </FONT><BR><FONT size=3D2>&gt; required? =
I</FONT>=20
  <BR><FONT size=3D2>&gt; *believe*</FONT> <BR><FONT size=3D2>&gt; it is =
a problem,=20
  but I suspect the claim would be contentious without</FONT> <BR><FONT=20
  size=3D2>&gt; numbers.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  pdn&gt;If it were not slow (my measurements done about 2 years=20
  </FONT><BR><FONT size=3D2>&gt; back indicated</FONT> <BR><FONT =
size=3D2>&gt;=20
  pdn&gt;that it was), why would the MIP group be so actively pursuing=20
  fast</FONT> <BR><FONT size=3D2>&gt; pdn&gt;handoff?&nbsp; My REAL =
belief is that=20
  fast hand off work belongs in</FONT> <BR><FONT size=3D2>&gt;=20
  pdn&gt;SeaMoby.&nbsp; That is if you are willing to seperate the world =

  into</FONT> <BR><FONT size=3D2>&gt; pdn&gt;Core routing (mobile IP) =
and edge=20
  tunnelling (SeaMoby).&nbsp; </FONT><BR><FONT size=3D2>&gt; This type =
of</FONT>=20
  <BR><FONT size=3D2>&gt; pdn&gt;division of labor makes MUCH more sense =
to me=20
  technically, but the</FONT> <BR><FONT size=3D2>&gt; pdn&gt;politics of =
such a=20
  reorganization make its possibility of </FONT><BR><FONT size=3D2>&gt;=20
  existence</FONT> <BR><FONT size=3D2>&gt; pdn&gt;tenuous.&nbsp; Just =
think how=20
  the MIP group would be free to </FONT><BR><FONT size=3D2>&gt; worry =
about</FONT>=20
  <BR><FONT size=3D2>&gt; pdn&gt;optimizing the router chains for =
mobility rather=20
  than edge device</FONT> <BR><FONT size=3D2>&gt; pdn&gt;junk.&nbsp; =
SeaMoby would=20
  only have to worry about eventually sending a</FONT> <BR><FONT =
size=3D2>&gt;=20
  pdn&gt;new MIP registration while a temporary tunnel keeps the=20
  connection</FONT> <BR><FONT size=3D2>&gt; pdn&gt;seamless.&nbsp; =
Perhaps I=20
  really am wacked, but this is the way I see</FONT> <BR><FONT =
size=3D2>&gt;=20
  pdn&gt;it.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt;=20
</FONT></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_008A_01C08392.990B6AA0--



From owner-seamoby@diameter.org  Sun Jan 21 14:40:47 2001
Received: from charizard.diameter.org ([24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10712
	for <seamoby-archive@odin.ietf.org>; Sun, 21 Jan 2001 14:40:45 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0LIw7f10625
	for seamoby-list; Sun, 21 Jan 2001 10:58:07 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0LIw5o10620
	for <seamoby@diameter.org>; Sun, 21 Jan 2001 10:58:05 -0800
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18614;
	Sun, 21 Jan 2001 10:05:24 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA03420;
	Sun, 21 Jan 2001 10:05:19 -0800 (PST)
Received: from cinnamon (cinnamon [129.146.122.100])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA24227;
	Sun, 21 Jan 2001 10:05:13 -0800 (PST)
Date: Sun, 21 Jan 2001 10:04:21 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [seamoby] More beating my head against the wall....
To: Dave Martin <dmartin@kreative.net>
Cc: Gary Kenward <gkenward@nortelnetworks.com>, Phil_Neumiller@3Com.com,
        seamoby@diameter.org
In-Reply-To: "Your message with ID" <008d01c083bc$82ba1f60$0100000a@david>
Message-ID: <Roam.SIMC.2.0.6.980100261.11059.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk


> As a another voice in the choir ... I also believe that the fast-handoff
> belongs in seamoby.

Well, Mobile IP work items belong in Mobile IP. They have already fast handoff
in their charter, and I don't see why or how we could convince the IESG to
make them part with it for mere convenience.

Are you, then, stating that Micro-Mobility, or edge mobility, is a solved
problem in Mobile IP?

PatC



From owner-seamoby@diameter.org  Sun Jan 21 17:49:11 2001
Received: from charizard.diameter.org ([24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11611
	for <seamoby-archive@odin.ietf.org>; Sun, 21 Jan 2001 17:49:10 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0LM9Qe10731
	for seamoby-list; Sun, 21 Jan 2001 14:09:26 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from ns.kreative.net (root@ns.kreative.net [216.181.1.200])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0LM9No10726
	for <seamoby@diameter.org>; Sun, 21 Jan 2001 14:09:23 -0800
Received: from david (laurelp-143.dsdial.net [216.181.253.143])
	by ns.kreative.net (8.9.3/8.9.3) with SMTP id QAA25902;
	Sun, 21 Jan 2001 16:12:55 -0500
Message-ID: <011201c083ee$179268a0$0100000a@david>
From: "Dave Martin" <dmartin@kreative.net>
To: "Pat Calhoun" <Pat.Calhoun@eng.sun.com>
Cc: "Gary Kenward" <gkenward@nortelnetworks.com>, <Phil_Neumiller@3Com.com>,
        <seamoby@diameter.org>
References: <Roam.SIMC.2.0.6.980100261.11059.pcalhoun@nasnfs>
Subject: Re: [seamoby] More beating my head against the wall....
Date: Sun, 21 Jan 2001 16:06:57 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

<snipping irrelevant thoughts about where fast-handoff belongs ... the fact
is that it is in the Mobile IP group and I should just accept that fact and
move on>

> Are you, then, stating that Micro-Mobility, or edge mobility, is a solved
> problem in Mobile IP?
>
> PatC

Micro/edge mobility is already solved in most large wireless networks, it's
just that there is no global standard, and that the mobility is typically
done at layer 2.  There is value in having a unified standard to rally
around, and to formally define how layer 2 and layer 3 mobility protocols
should work together.

Your question does actually raise an interesting point. A HA's purpose is to
shield the rest of the network from changes in routing topology as a node
moves from subnet to subnet.  Isn't the intra-domain/micro-mobility problem
basically the same problem at a finer layer--namely to shield the HA from
changes in routing topology?




From owner-seamoby@diameter.org  Sun Jan 21 20:02:37 2001
Received: from charizard.diameter.org ([24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12247
	for <seamoby-archive@odin.ietf.org>; Sun, 21 Jan 2001 20:02:34 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0M0KfN10798
	for seamoby-list; Sun, 21 Jan 2001 16:20:41 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0M0Kdo10793
	for <seamoby@diameter.org>; Sun, 21 Jan 2001 16:20:39 -0800
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch2.nortel.com; Sun, 21 Jan 2001 17:22:21 -0600
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <DLQZYH4V>; Sun, 21 Jan 2001 17:27:01 -0600
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8B65@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Dave Martin'" <dmartin@kreative.net>,
        Phil_Neumiller <Phil_Neumiller@3Com.com>
Cc: seamoby <seamoby@diameter.org>
Subject: RE: [seamoby] More beating my head against the wall....
Date: Sun, 21 Jan 2001 15:39:35 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C083F2.A6101510"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C083F2.A6101510
Content-Type: text/plain;
	charset="iso-8859-1"

Thanks Dave, for the reasoned contribution. I agree with your definitions of
edge versus core, although you refer mostly to what I would call core
services rather then a core network (moot point for now I think).
 
As for micromobility (not fast handoff, as Pat has pointed out), it seems to
me that "bridging the gap" is one view of the objective, when MIP is
present. In reality, "bridging the gap" without MIP should provide a
seamless mobility solution for within the access network at the IP layer.
 
Gary

-----Original Message-----
From: Dave Martin [mailto:dmartin@kreative.net]
Sent: Sunday, January 21, 2001 10:12 AM
To: Kenward, Gary [WDLN2:AN10:EXCH]; Phil_Neumiller
Cc: seamoby
Subject: Re: [seamoby] More beating my head against the wall....


In our current Mobile IP network (MIPv4), it takes several seconds (~3) to
change FAs (COA).  L2 plays almost no part in this delay (our L2 *can*
support realtime data traffic).  If necessary I can provide more detail on
the delay budget, but I hope that we can agree that MIP as it is today would
not support real time services (e.g. voice).
 
So I would content that MIP (current version) is too slow to support
mobility between FAs.
 
I would also contend that MIP will probably always be too slow unless
something is done to optimize the "edge" to bridge the gap while the "core"
is updated with new routing information.  My definition of "edge" is the
closest router to the mobile (AR), and my definition of core is the rest of
the supporting network (HA, AAA, FA etc).
 
As a another voice in the choir ... I also believe that the fast-handoff
work belongs in seamoby.
 
----- Original Message ----- 

From: Gary Kenward <mailto:gkenward@nortelnetworks.com>  
To: 'Phil_Neumiller@3Com.com' <mailto:'Phil_Neumiller@3Com.com'>  
Cc: seamoby@diameter.org <mailto:seamoby@diameter.org>  
Sent: Friday, January 19, 2001 12:19 AM
Subject: RE: [seamoby] More beating my head against the wall....


You are preaching to the choir, as you fully well know. 
My point was, is there quantitative justification for the statement you 
made that MIP is too slow? 

Gary 

> -----Original Message----- 
> From: Phil_Neumiller@3Com.com <mailto:Phil_Neumiller@3Com.com>  [
mailto:Phil_Neumiller@3Com.com <mailto:Phil_Neumiller@3Com.com> ] 
> Sent: Thursday, January 18, 2001 3:38 PM 
> To: Kenward, Gary [WDLN2:AN10:EXCH] 
> Cc: seamoby@diameter.org <mailto:seamoby@diameter.org>  
> Subject: RE: [seamoby] More beating my head against the wall.... 
> 
> 
> 
> 
> 
> 
> 
> 
> Sent by:  "Gary Kenward" <gkenward@nortelnetworks.com> 
> 
> *snip* 
> 
> 
> I would tend to agree with you Phil, but do we have tangible 
> evidence that 
> the MIP routing is too slow, and the routing at the edge is 
> required? I 
> *believe* 
> it is a problem, but I suspect the claim would be contentious without 
> numbers. 
> 
> pdn>If it were not slow (my measurements done about 2 years 
> back indicated 
> pdn>that it was), why would the MIP group be so actively pursuing fast 
> pdn>handoff?  My REAL belief is that fast hand off work belongs in 
> pdn>SeaMoby.  That is if you are willing to seperate the world into 
> pdn>Core routing (mobile IP) and edge tunnelling (SeaMoby).  
> This type of 
> pdn>division of labor makes MUCH more sense to me technically, but the 
> pdn>politics of such a reorganization make its possibility of 
> existence 
> pdn>tenuous.  Just think how the MIP group would be free to 
> worry about 
> pdn>optimizing the router chains for mobility rather than edge device 
> pdn>junk.  SeaMoby would only have to worry about eventually sending a 
> pdn>new MIP registration while a temporary tunnel keeps the connection 
> pdn>seamless.  Perhaps I really am wacked, but this is the way I see 
> pdn>it. 
> 
> 
> 
> 


------_=_NextPart_001_01C083F2.A6101510
Content-Type: text/html;
	charset="iso-8859-1"

<!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] More beating my head against the wall....</TITLE>

<META content="MSHTML 5.00.2314.1000" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face="Comic Sans MS"><SPAN class=010072321-21012001>Thanks Dave, for 
the reasoned contribution. I agree with your definitions of edge versus core, 
although you refer mostly to what I would call core services rather then a core 
network (moot point for now I think).</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=010072321-21012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=010072321-21012001>As for 
micromobility (not fast handoff, as Pat has pointed out), it seems to me that 
"bridging the gap" is one view of the objective, when MIP is present. In 
reality, "bridging the gap" without MIP should provide a seamless mobility 
solution for within the access network at the IP layer.</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=010072321-21012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=010072321-21012001>Gary</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Dave Martin 
  [mailto:dmartin@kreative.net]<BR><B>Sent:</B> Sunday, January 21, 2001 10:12 
  AM<BR><B>To:</B> Kenward, Gary [WDLN2:AN10:EXCH]; Phil_Neumiller<BR><B>Cc:</B> 
  seamoby<BR><B>Subject:</B> Re: [seamoby] More beating my head against the 
  wall....<BR><BR></DIV></FONT>
  <DIV><FONT face=Arial size=2>In our current Mobile IP network (MIPv4), it 
  takes several seconds (~3) to change FAs (COA).&nbsp; L2 plays almost no part 
  in this delay (our L2 *can* support realtime data traffic).&nbsp; If necessary 
  I can provide more detail on the delay budget, but I hope that we can agree 
  that MIP as it is today would not support real time services (e.g. 
  voice).</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>So I would content that MIP (current version) is 
  too slow to support mobility between FAs.</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>I would also contend that MIP will probably 
  always be too slow unless something is done to optimize the "edge" to bridge 
  the gap while the "core"&nbsp;is updated with new routing information.&nbsp; 
  My definition of "edge" is the closest router to the&nbsp;mobile (AR), and my 
  definition of core is the rest of the supporting network (HA, AAA, FA 
  etc).</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>As a another voice in the choir ... I also 
  believe that the fast-handoff work belongs in seamoby.</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV>----- Original Message ----- </DIV>
  <BLOCKQUOTE 
  style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
    <DIV 
    style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
    <A href="mailto:gkenward@nortelnetworks.com" 
    title=gkenward@nortelnetworks.com>Gary Kenward</A> </DIV>
    <DIV style="FONT: 10pt arial"><B>To:</B> <A 
    href="mailto:'Phil_Neumiller@3Com.com'" 
    title=Phil_Neumiller@3Com.com>'Phil_Neumiller@3Com.com'</A> </DIV>
    <DIV style="FONT: 10pt arial"><B>Cc:</B> <A 
    href="mailto:seamoby@diameter.org" 
    title=seamoby@diameter.org>seamoby@diameter.org</A> </DIV>
    <DIV style="FONT: 10pt arial"><B>Sent:</B> Friday, January 19, 2001 12:19 
    AM</DIV>
    <DIV style="FONT: 10pt arial"><B>Subject:</B> RE: [seamoby] More beating my 
    head against the wall....</DIV>
    <DIV><BR></DIV>
    <P><FONT size=2>You are preaching to the choir, as you fully well 
    know.</FONT> <BR><FONT size=2>My point was, is there quantitative 
    justification for the statement you</FONT> <BR><FONT size=2>made that MIP is 
    too slow?</FONT> </P>
    <P><FONT size=2>Gary</FONT> </P>
    <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
    From: <A href="mailto:Phil_Neumiller@3Com.com">Phil_Neumiller@3Com.com</A> 
    [<A 
    href="mailto:Phil_Neumiller@3Com.com">mailto:Phil_Neumiller@3Com.com</A>]</FONT> 
    <BR><FONT size=2>&gt; Sent: Thursday, January 18, 2001 3:38 PM</FONT> 
    <BR><FONT size=2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]</FONT> <BR><FONT 
    size=2>&gt; Cc: <A 
    href="mailto:seamoby@diameter.org">seamoby@diameter.org</A></FONT> <BR><FONT 
    size=2>&gt; Subject: RE: [seamoby] More beating my head against the 
    wall....</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Sent by:&nbsp; 
    "Gary Kenward" &lt;gkenward@nortelnetworks.com&gt;</FONT> <BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt; *snip*</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; I would tend to 
    agree with you Phil, but do we have tangible </FONT><BR><FONT size=2>&gt; 
    evidence that</FONT> <BR><FONT size=2>&gt; the MIP routing is too slow, and 
    the routing at the edge is </FONT><BR><FONT size=2>&gt; required? I</FONT> 
    <BR><FONT size=2>&gt; *believe*</FONT> <BR><FONT size=2>&gt; it is a 
    problem, but I suspect the claim would be contentious without</FONT> 
    <BR><FONT size=2>&gt; numbers.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; pdn&gt;If it were not slow (my measurements done about 2 years 
    </FONT><BR><FONT size=2>&gt; back indicated</FONT> <BR><FONT size=2>&gt; 
    pdn&gt;that it was), why would the MIP group be so actively pursuing 
    fast</FONT> <BR><FONT size=2>&gt; pdn&gt;handoff?&nbsp; My REAL belief is 
    that fast hand off work belongs in</FONT> <BR><FONT size=2>&gt; 
    pdn&gt;SeaMoby.&nbsp; That is if you are willing to seperate the world 
    into</FONT> <BR><FONT size=2>&gt; pdn&gt;Core routing (mobile IP) and edge 
    tunnelling (SeaMoby).&nbsp; </FONT><BR><FONT size=2>&gt; This type of</FONT> 
    <BR><FONT size=2>&gt; pdn&gt;division of labor makes MUCH more sense to me 
    technically, but the</FONT> <BR><FONT size=2>&gt; pdn&gt;politics of such a 
    reorganization make its possibility of </FONT><BR><FONT size=2>&gt; 
    existence</FONT> <BR><FONT size=2>&gt; pdn&gt;tenuous.&nbsp; Just think how 
    the MIP group would be free to </FONT><BR><FONT size=2>&gt; worry 
    about</FONT> <BR><FONT size=2>&gt; pdn&gt;optimizing the router chains for 
    mobility rather than edge device</FONT> <BR><FONT size=2>&gt; 
    pdn&gt;junk.&nbsp; SeaMoby would only have to worry about eventually sending 
    a</FONT> <BR><FONT size=2>&gt; pdn&gt;new MIP registration while a temporary 
    tunnel keeps the connection</FONT> <BR><FONT size=2>&gt; 
    pdn&gt;seamless.&nbsp; Perhaps I really am wacked, but this is the way I 
    see</FONT> <BR><FONT size=2>&gt; pdn&gt;it.</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; </FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C083F2.A6101510--


From owner-seamoby@diameter.org  Sun Jan 21 20:09:16 2001
Received: from charizard.diameter.org ([24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12259
	for <seamoby-archive@odin.ietf.org>; Sun, 21 Jan 2001 20:09:15 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0M0KBG10791
	for seamoby-list; Sun, 21 Jan 2001 16:20:11 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0M0K9o10786
	for <seamoby@diameter.org>; Sun, 21 Jan 2001 16:20:09 -0800
Received: from zrtpd004.us.nortel.com (actually zrtpd004) 
          by ertpg14e1.nortelnetworks.com; Sun, 21 Jan 2001 18:27:02 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <DB806YWP>; Sun, 21 Jan 2001 18:27:01 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8B63@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Phil_Neumiller@3Com.com'" <Phil_Neumiller@3Com.com>,
        seamoby@diameter.org
Subject: RE: [seamoby] [MOBILE-IP] BURP BOF
Date: Sun, 21 Jan 2001 16:26:56 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C083F0.E17C8E00"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C083F0.E17C8E00
Content-Type: text/plain;
	charset="iso-8859-1"

Maybe someone should ask Raj Patil, seeing as he supported the
creation of SeaMoby. Perhaps he simply lumped SeaMoby in with 
MIP for simplicities sake.

gary

> -----Original Message-----
> From: Phil_Neumiller@3Com.com [mailto:Phil_Neumiller@3Com.com]
> Sent: Friday, January 19, 2001 1:05 PM
> To: seamoby@diameter.org
> Subject: [seamoby] [MOBILE-IP] BURP BOF
> 
> 
> 
> 
> According to the description of this new BOF, mobile IP 
> already provides
> "seamless and continuous connectivity".  Hmm, what in the world
> is SeaMoby for?
> 
> Creating a standardized registration protocol for the  
> application layer
> makes a lot of sense.  Perhaps some of the UPnP/SLP work can be
> useful here.
> 
> 
> ---------------------- Forwarded by Phil Neumiller/MW/US/3Com 
> on 01/19/2001
> 11:48 AM ---------------------------
> 
> Please respond to Basavaraj.Patil@nokia.com
> 
> Sent by:  Basavaraj Patil <Basavaraj.Patil@nokia.com>
> 
> 
> A BOF on Basic User Registration Protocol (BURP)
> 
> 
> Charter:
> 
> The vision of pervasive computing also includes constantly being
> connected and the ability to access the Internet or the enterprise
> over the Internet. Mobile computing solutions based on protocols such
> as Mobile IP offer seamless and continuous connectivity for
> users. However a lot of roadwarriors and other types
> of users access the network from places like airports, hotels, malls
> and sports complexes. These environments may offer access to the
> network over wireless LANs or via Ethernet LAN ports or other
> mediums. In such scenarios,
> DHCP can provide configuration information  (e.g., giving a valid
> address etc.), but there is no standard way for service providers to
> obtain user information to perform AAA functions. For users
> who do not have Mobile IP clients on their devices but would like to
> access the network, they need to register and be authenticated by the
> local network service provider before being authorized to use the
> resources. The intent of this proposal is to develop an application
> layer registration protocol that allows a user to register in the
> local network by providing identity and authentication information
> to the local network which then uses a AAA infrastructure to validate
> the user, charge him and, authorize use of resources.
> 
> We would like to request a BOF on a "Basic User Registration
> Protocol (BURP)" for the March 2001 meeting of the IETF in 
> Minneapolis.
> The objective of the BOF will be to
> -- Detail the scope of the proposal and applicable scenarios
> 
> -- Chart a course and an action plan (including milestones
> and deliverables) for BURP.
> 
> -- Investigate  the impact on existing  AAA  protocols  and  make it
> flexible to support various authentication schemes.
> 
> The goal will be to define a standard UNI for  environments in which
> neither PPP nor Mobile IP is required but AAA interaction is
> essential.  The basic principle will include:
> 
>   -- The solution being a client-server application layer protocol
> 
>   -- Is applicable to both IPv4 and IPv6.
> 
>   -- User interacts only with a local Registration Agent (RA), which
>   may reside on any node in the Network Domain.
> 
>   -- It should work with any configuration  protocol, such as 
> DHCP, IPv6
>   stateless autoconfiguration, and manual configuration.
> 
>   -- Protects RA from replay attacks.
> 
>   -- Provide information on and control of network usage.
> 
>   -- Interacts with routers/policers to limit packets 
> forwarding based on a
>   user's Service Level  Specification  (may be optional or may
>   interwork with  standard policy protocols).
> 
>   -- Defines an RA-to-AAA interface
> 
> --------------------------------------------------------------
> ---------
> 
> To subscribe to the mailing list for discussion on this topic, please
> follow these instructions:
> 
> To subscribe, send mail to urp-request@research.telcordia.com, and
> use "subscribe" for the subject line.
> 
> To unsubscribe, send mail to urp-request@research.telcordia.com, and
> use "unsubscribe" for the subject line.
> 
> To contribute to the list, send mail to urp@research.telcordia.com.
> 
> For additional help, send mail to urp-request@research.telcordia.com
> and use "help" for the subject line.
> 
> 
> 
> 

------_=_NextPart_001_01C083F0.E17C8E00
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] [MOBILE-IP] BURP BOF</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Maybe someone should ask Raj Patil, seeing as he supported the</FONT>
<BR><FONT SIZE=2>creation of SeaMoby. Perhaps he simply lumped SeaMoby in with </FONT>
<BR><FONT SIZE=2>MIP for simplicities sake.</FONT>
</P>

<P><FONT SIZE=2>gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Phil_Neumiller@3Com.com [<A HREF="mailto:Phil_Neumiller@3Com.com">mailto:Phil_Neumiller@3Com.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Friday, January 19, 2001 1:05 PM</FONT>
<BR><FONT SIZE=2>&gt; To: seamoby@diameter.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: [seamoby] [MOBILE-IP] BURP BOF</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; According to the description of this new BOF, mobile IP </FONT>
<BR><FONT SIZE=2>&gt; already provides</FONT>
<BR><FONT SIZE=2>&gt; &quot;seamless and continuous connectivity&quot;.&nbsp; Hmm, what in the world</FONT>
<BR><FONT SIZE=2>&gt; is SeaMoby for?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Creating a standardized registration protocol for the&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; application layer</FONT>
<BR><FONT SIZE=2>&gt; makes a lot of sense.&nbsp; Perhaps some of the UPnP/SLP work can be</FONT>
<BR><FONT SIZE=2>&gt; useful here.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ---------------------- Forwarded by Phil Neumiller/MW/US/3Com </FONT>
<BR><FONT SIZE=2>&gt; on 01/19/2001</FONT>
<BR><FONT SIZE=2>&gt; 11:48 AM ---------------------------</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Please respond to Basavaraj.Patil@nokia.com</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Sent by:&nbsp; Basavaraj Patil &lt;Basavaraj.Patil@nokia.com&gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; A BOF on Basic User Registration Protocol (BURP)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Charter:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The vision of pervasive computing also includes constantly being</FONT>
<BR><FONT SIZE=2>&gt; connected and the ability to access the Internet or the enterprise</FONT>
<BR><FONT SIZE=2>&gt; over the Internet. Mobile computing solutions based on protocols such</FONT>
<BR><FONT SIZE=2>&gt; as Mobile IP offer seamless and continuous connectivity for</FONT>
<BR><FONT SIZE=2>&gt; users. However a lot of roadwarriors and other types</FONT>
<BR><FONT SIZE=2>&gt; of users access the network from places like airports, hotels, malls</FONT>
<BR><FONT SIZE=2>&gt; and sports complexes. These environments may offer access to the</FONT>
<BR><FONT SIZE=2>&gt; network over wireless LANs or via Ethernet LAN ports or other</FONT>
<BR><FONT SIZE=2>&gt; mediums. In such scenarios,</FONT>
<BR><FONT SIZE=2>&gt; DHCP can provide configuration information&nbsp; (e.g., giving a valid</FONT>
<BR><FONT SIZE=2>&gt; address etc.), but there is no standard way for service providers to</FONT>
<BR><FONT SIZE=2>&gt; obtain user information to perform AAA functions. For users</FONT>
<BR><FONT SIZE=2>&gt; who do not have Mobile IP clients on their devices but would like to</FONT>
<BR><FONT SIZE=2>&gt; access the network, they need to register and be authenticated by the</FONT>
<BR><FONT SIZE=2>&gt; local network service provider before being authorized to use the</FONT>
<BR><FONT SIZE=2>&gt; resources. The intent of this proposal is to develop an application</FONT>
<BR><FONT SIZE=2>&gt; layer registration protocol that allows a user to register in the</FONT>
<BR><FONT SIZE=2>&gt; local network by providing identity and authentication information</FONT>
<BR><FONT SIZE=2>&gt; to the local network which then uses a AAA infrastructure to validate</FONT>
<BR><FONT SIZE=2>&gt; the user, charge him and, authorize use of resources.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; We would like to request a BOF on a &quot;Basic User Registration</FONT>
<BR><FONT SIZE=2>&gt; Protocol (BURP)&quot; for the March 2001 meeting of the IETF in </FONT>
<BR><FONT SIZE=2>&gt; Minneapolis.</FONT>
<BR><FONT SIZE=2>&gt; The objective of the BOF will be to</FONT>
<BR><FONT SIZE=2>&gt; -- Detail the scope of the proposal and applicable scenarios</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -- Chart a course and an action plan (including milestones</FONT>
<BR><FONT SIZE=2>&gt; and deliverables) for BURP.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -- Investigate&nbsp; the impact on existing&nbsp; AAA&nbsp; protocols&nbsp; and&nbsp; make it</FONT>
<BR><FONT SIZE=2>&gt; flexible to support various authentication schemes.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The goal will be to define a standard UNI for&nbsp; environments in which</FONT>
<BR><FONT SIZE=2>&gt; neither PPP nor Mobile IP is required but AAA interaction is</FONT>
<BR><FONT SIZE=2>&gt; essential.&nbsp; The basic principle will include:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; -- The solution being a client-server application layer protocol</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; -- Is applicable to both IPv4 and IPv6.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; -- User interacts only with a local Registration Agent (RA), which</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; may reside on any node in the Network Domain.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; -- It should work with any configuration&nbsp; protocol, such as </FONT>
<BR><FONT SIZE=2>&gt; DHCP, IPv6</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; stateless autoconfiguration, and manual configuration.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; -- Protects RA from replay attacks.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; -- Provide information on and control of network usage.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; -- Interacts with routers/policers to limit packets </FONT>
<BR><FONT SIZE=2>&gt; forwarding based on a</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; user's Service Level&nbsp; Specification&nbsp; (may be optional or may</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; interwork with&nbsp; standard policy protocols).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; -- Defines an RA-to-AAA interface</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; --------------------------------------------------------------</FONT>
<BR><FONT SIZE=2>&gt; ---------</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; To subscribe to the mailing list for discussion on this topic, please</FONT>
<BR><FONT SIZE=2>&gt; follow these instructions:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; To subscribe, send mail to urp-request@research.telcordia.com, and</FONT>
<BR><FONT SIZE=2>&gt; use &quot;subscribe&quot; for the subject line.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; To unsubscribe, send mail to urp-request@research.telcordia.com, and</FONT>
<BR><FONT SIZE=2>&gt; use &quot;unsubscribe&quot; for the subject line.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; To contribute to the list, send mail to urp@research.telcordia.com.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; For additional help, send mail to urp-request@research.telcordia.com</FONT>
<BR><FONT SIZE=2>&gt; and use &quot;help&quot; for the subject line.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C083F0.E17C8E00--


From owner-seamoby@diameter.org  Sun Jan 21 20:11:17 2001
Received: from charizard.diameter.org ([24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12288
	for <seamoby-archive@odin.ietf.org>; Sun, 21 Jan 2001 20:11:17 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0M0SYu10810
	for seamoby-list; Sun, 21 Jan 2001 16:28:34 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zrtps06s.us.nortel.com (h50s48a140n47.user.nortelnetworks.com [47.140.48.50])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0M0SWo10804
	for <seamoby@diameter.org>; Sun, 21 Jan 2001 16:28:32 -0800
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com;
          Sun, 21 Jan 2001 18:27:25 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <DB806YWT>; Sun, 21 Jan 2001 18:27:01 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8B64@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Dave Martin'" <dmartin@kreative.net>,
        Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: Phil_Neumiller <Phil_Neumiller@3Com.com>, seamoby <seamoby@diameter.org>
Subject: RE: [seamoby] More beating my head against the wall....
Date: Sun, 21 Jan 2001 16:34:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C083F1.E00DED60"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C083F1.E00DED60
Content-Type: text/plain;
	charset="iso-8859-1"



> -----Original Message-----
> From: Dave Martin [mailto:dmartin@kreative.net]
> Sent: Sunday, January 21, 2001 4:07 PM
> To: Pat Calhoun
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Phil_Neumiller; seamoby
> Subject: Re: [seamoby] More beating my head against the wall....
> 
> 
*more snipping*
> 
> Micro/edge mobility is already solved in most large wireless 
> networks, it's
> just that there is no global standard, and that the mobility 
> is typically
> done at layer 2.  There is value in having a unified standard to rally
> around, and to formally define how layer 2 and layer 3 
> mobility protocols
> should work together.

And most of these solutions are not friendly to packet switched traffic
(I am tempted to say all...)..

Gary

> 
> 

------_=_NextPart_001_01C083F1.E00DED60
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] More beating my head against the wall....</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Dave Martin [<A HREF="mailto:dmartin@kreative.net">mailto:dmartin@kreative.net</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Sunday, January 21, 2001 4:07 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Pat Calhoun</FONT>
<BR><FONT SIZE=2>&gt; Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Phil_Neumiller; seamoby</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: [seamoby] More beating my head against the wall....</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>*more snipping*</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Micro/edge mobility is already solved in most large wireless </FONT>
<BR><FONT SIZE=2>&gt; networks, it's</FONT>
<BR><FONT SIZE=2>&gt; just that there is no global standard, and that the mobility </FONT>
<BR><FONT SIZE=2>&gt; is typically</FONT>
<BR><FONT SIZE=2>&gt; done at layer 2.&nbsp; There is value in having a unified standard to rally</FONT>
<BR><FONT SIZE=2>&gt; around, and to formally define how layer 2 and layer 3 </FONT>
<BR><FONT SIZE=2>&gt; mobility protocols</FONT>
<BR><FONT SIZE=2>&gt; should work together.</FONT>
</P>

<P><FONT SIZE=2>And most of these solutions are not friendly to packet switched traffic</FONT>
<BR><FONT SIZE=2>(I am tempted to say all...)..</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C083F1.E00DED60--


From owner-seamoby@diameter.org  Sun Jan 21 21:38:09 2001
Received: from charizard.diameter.org ([24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13844
	for <seamoby-archive@odin.ietf.org>; Sun, 21 Jan 2001 21:38:08 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0M1tG510871
	for seamoby-list; Sun, 21 Jan 2001 17:55:16 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0M1tDo10866
	for <seamoby@diameter.org>; Sun, 21 Jan 2001 17:55:13 -0800
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id SAA21498 for <seamoby@diameter.org>; Sun, 21 Jan 2001 18:02:44 -0700 (MST)]
Received: [from ilms03.cig.mot.com (ilms03.cig.mot.com [136.182.15.13]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id SAA19078 for <seamoby@diameter.org>; Sun, 21 Jan 2001 18:02:44 -0700 (MST)]
Received: from em.cig.mot.com ([160.44.128.5]) by ilms03.cig.mot.com
          (Netscape Messaging Server 3.01)  with SMTP id AAA22133
          for <seamoby@diameter.org>; Sun, 21 Jan 2001 19:02:43 -0600
Received: from minties.em.cig.mot.com by em.cig.mot.com (SMI-8.6/SMI-SVR4)
	id TAA29281; Sun, 21 Jan 2001 19:02:43 -0600
Date: Sun, 21 Jan 2001 19:02:32 -0600
From: Jonathan Taz Mischo <taz@em.cig.mot.com>
To: seamoby@diameter.org
Subject: RE: [seamoby] micro, schmicro
Message-ID: <20010121190232.F1793@smoke.em.cig.mot.com>
Reply-To: taz@em.cig.mot.com
References: <FC0292EA4D13D34EA2E5FC728D70A8E3078BA7@NEPTUNE.zucotto.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
In-Reply-To: <FC0292EA4D13D34EA2E5FC728D70A8E3078BA7@NEPTUNE.zucotto.com>; from kulwinder.atwal@zucotto.com on Tue, Jan 16, 2001 at 19:12:07 -0600
X-Mailer: Balsa 0.9.0
Sender: owner-seamoby@diameter.org
Precedence: bulk

I know there is much discussion on this that has happened in the last
week...alas, I'm only caught up to here, so I must interject right now...please see my
comments below...(this is gonna hurt)

-Jon

On Tue, 16 Jan 2001 19:12:07 Kulwinder Atwal wrote:
> 
> 
> > -----Original Message-----
> > From: Phil_Neumiller@3com.com [mailto:Phil_Neumiller@3com.com]
> > Sent: Tuesday, January 16, 2001 7:08 PM
> > To: Kulwinder Atwal
> > Cc: seamoby@diameter.org
> > Subject: RE: [seamoby] micro, schmicro
> > 
> > 
> > 
> > 
> > 
> > I think I disagree.  Why would the FAs necessarily find these routes?
> > You could have situations like the following:
> > 
> >  FA1                    FA2
> >   |                      |
> > (net 1)---------------(net 2)
> >   |                      |
> > (net 3)---------------(net 4)
> >   |                      |
> > (AP 1)                (AP 2)
> >   |
> >  MN  --> handing over to ^
> > 
> > Here net 1 is a subnet of FA1, and net 3 is a subnet of
> > net 1.  The OSPF or RIP path between AP 2 and FA 1, may
> > be different that that between AP 1 and AP 2. which may
> > have a mesh link between net 3 and net 4 that is unknown
> > to FA1 and FA2 right?
> > 
> 
> Making your diagram technology neutral:
>  
>   Big I			Big I
>    |                      |
>  (CR 3)------CRL1----- (CR 2)
>    |                      |
>  (OAR)-------ARL1-----  (NAR)
>    |                      |
>  (OAP)                  (NAP)
>    |
>   MN  --> handing over to ^> 
>  
> 
> CR = Core Router
> 
> AR = Access Router 
> 
> OAR = Old Access Router
> 
> NAR = New Access Router
> 
> I think your model in encouraging bad real-time network design.  The ARs
> should have the functionality to resolve MN moves through one link.  If ARs
> agree on one link for passing all MN handover related messages in advance,
> this will cut down on the amount of messaging needed for a handover as
well.

I almost died when I read this.  I think YOUR mental model for good design is
flawed.  I acknowledge that a lot of people are transitioning their thinking
from circuit switched to packet switched, and that there are good ideas for some
things, and bad for others.  However, in this case your logic is flawed. 
 
> Either staticly, or dynamically the Access Routers (OAR/NAR) need to agree
> on one single path for MN moves in advance of the move.  This path may even
> be set once by the Network Administor during network setup.

No, no, NO!  Have you ever worked with a real-world IP network with QoS?  If
you have, you know that there are a lot of things going on, and failures occur
(often uni-directionally on a path), which is precisely why you DON'T do this. 
Why bother with packet switching if you're going to pretend to circuit switch?

> Further, placing the functionality required for the move that many layers
> away from the MN will most likely not result in the real-time behaviour we
> are looking for.

This is true...if you design your network poorly and without QoS, or when
things are severely broken in your network.  At all other times it's false if you
have network engineers/architects who know how to design a network.
 
> This is why I believe the better solution is to place the primary
> functionality for the move in the ARs nearest the MN.   

Why are you so attached to telling everyone how to design a network?  I can
guarantee I can design a network with 5 hops to the decision making body that
still makes the same window, and is more efficient.  Frankly, you are limiting
yourself by keeping this TOO CLOSE to the MN...you're not giving it enough
choices...see more on this below.
 
> Unlike the general Internet, Real-Time network design must consider
> deterministic behaviour as a primary design objective.  

Unlike circuit switching, real-time packet-switched networks must consider NOT
dropping connections when something nasty happens.  That's why good network
engineers and network architects, with years of experience, design networks that
can adapt to changes nearly instantly.  If you let someone tell the network how
to do its business, you break the network when a circuit goes critical.  I
promise you that if you design a network that relies on everything being "just so"
it will crash and burn the first time Joe Blow forgets to get a digging permit
for his backyard.
 
> If the Network Designer wishes Real-Time behaviour to be a primary design
> goal, then deterministic behaviour must be a primary design objective. 
> 
> If we want Real-Time hand-overs then at least:

In review:
 
>  - we must place Real-time bounds on "Routed Clouds"

Wrong, we must use intelligent packet switched clouds (a LOT faster than
routing)

>  - move decision making closer to the MN

Bzzzt.  We want the MN to be able to choose from the APs around it...to do
this efficiently (and cost effectively), we want to move this a few hops from the
AP, so the network can experience some natural aggregation, thus eliminating
the need for every AP to be linked to every possible neighbor, and allowing a
link to die without impeding CT.  Also, we don't want everyone paying tens and
hundreds of thousands of dollars per month for extra bandwidth they don't really
need to be wasting when they decide they don't like this
single-option-only-forever model and the ARs have to act on the behalf of the MNs and query other
ARs.

>  - limit handover messaging to one pre-determined path

Ouch!  And die a miserable death when a backhoe misses?  If we supply multiple
paths (SCTP with very tight tolerances is perfect for this on a QoS bound
network), we can handle hiccups, if we only have one route, we die.  Period.
 
> Also, since the problem space encompasses mobile wireless we must provide
> positive confirmation of every message between the MN and an AR.

Ouch...again, painful.  This is an over-generalization.  See SCTP.  SCTP is
the perfect protocol for this stuff, since that's what it was designed for.  Why
confirm every single message and waste bandwidth and battery, when there's a
better method?

As Phil likes to say...I'm just stirring the pot.  This is not to say you're
not brilliant, Kulwinder, I'm just saying your assumptions are wrong.  FYI, my
background is in operational network engineering and network design, including
real-time packet switching.  I've designed networks that had to deal with these
issues before, and there's more than one way to skin a cat.

Sorry for any burns,
-Jon
 
> - Kulwinder.
> 
> > 
> > 
> > Kulwinder Atwal <kulwinder.atwal@zucotto.com> on 01/16/2001 
> > 05:46:42 PM
> > 
> > Sent by:  Kulwinder Atwal <kulwinder.atwal@zucotto.com>
> > 
> > 
> > To:   Phil Neumiller/MW/US/3Com, Seamoby@diameter.org
> > cc:
> > Subject:  RE: [seamoby] micro, schmicro
> > 
> > 
> > 
> > >
> > >
> > > Um, actually what subnet you are on has an intimate relationship to
> > > what edge router you are using or what core router. The whole point
> > > of having a router is to bridge two subnets, in subnet 
> > based routing.
> > >
> > > James,
> > >
> > > I understand this.  However, it may be the case that useable
> > > routes exist
> > > between
> > > an edge router pair that are unknown to the mobility agents
> > > being used.
> > 
> > If the routes are IP routes then the IP mobility agents will be
> > aware of them, and will find the shortest path.  Otherwise, 
> > there is an
> > error in the implementation.
> > 
> > If the routes are L2 routes then this is an L2 issue.
> > 
> > Unless you are getting at something else.
> > 
> > 
> > 
> > 
> > 

-- 
Jonathan "Taz" Mischo                     ph: +1.847.632.4039
Lead Software Engineer                    mn: +1.815.302.3505
Advanced Systems Technology Department    fx: +1.847.435.9970
Network Sector                            em: taz@em.cig.mot.com
Motorola, Inc.                            hp: http://www.refcode.org/taz/



From owner-seamoby@diameter.org  Sun Jan 21 21:48:11 2001
Received: from charizard.diameter.org ([24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13890
	for <seamoby-archive@odin.ietf.org>; Sun, 21 Jan 2001 21:48:11 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0M2ILE10889
	for seamoby-list; Sun, 21 Jan 2001 18:18:21 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0M2IJo10884
	for <Seamoby@diameter.org>; Sun, 21 Jan 2001 18:18:19 -0800
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id SAA01332 for <Seamoby@diameter.org>; Sun, 21 Jan 2001 18:25:51 -0700 (MST)]
Received: [from ilms03.cig.mot.com (ilms03.cig.mot.com [136.182.15.13]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id SAA25636 for <Seamoby@diameter.org>; Sun, 21 Jan 2001 18:25:51 -0700 (MST)]
Received: from em.cig.mot.com ([160.44.128.5]) by ilms03.cig.mot.com
          (Netscape Messaging Server 3.01)  with SMTP id AAA22446
          for <Seamoby@diameter.org>; Sun, 21 Jan 2001 19:25:51 -0600
Received: from minties.em.cig.mot.com by em.cig.mot.com (SMI-8.6/SMI-SVR4)
	id TAA29357; Sun, 21 Jan 2001 19:25:50 -0600
Date: Sun, 21 Jan 2001 19:25:40 -0600
From: Jonathan Taz Mischo <taz@em.cig.mot.com>
To: Seamoby@diameter.org
Subject: Re: [seamoby] micro, schmicro
Message-ID: <20010121192540.H1793@smoke.em.cig.mot.com>
Reply-To: taz@em.cig.mot.com
References: <3A65C4DA.DBF7BC18@iprg.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
In-Reply-To: <3A65C4DA.DBF7BC18@iprg.nokia.com>; from charliep@iprg.nokia.com on Wed, Jan 17, 2001 at 10:14:18 -0600
X-Mailer: Balsa 0.9.0
Sender: owner-seamoby@diameter.org
Precedence: bulk


On Wed, 17 Jan 2001 10:14:18 Charles E. Perkins wrote:

> >>  ==  Phil
> >   ==  Dana
 
> >> So, as I have stated in every design team message list, I hope we can
> >> convince the list to abandon this terminology and recognize the real
> >> problem which is edge versus core.  Complex behavior enabling seamless
> >> mobility will be best implemented in edge devices of the global
> >> Internet.
> >> This is the ONLY way that it will scale globally.  As Tom Petty said,
> >> "No, I won't back down.." on this one.
> 
> Stand up, Phil, and thanks.  Even if I'm the only other one,
> I do appreciate that someone else is saying that the terminology
> is bad/harmful.

With this I will happily agree.  Too many people on this list are thinking
within the old boxes and are forgetting that we NEED to break the mold here, so
that we can come up with something that truly solves all the problems
gracefully.

Ciao!
-Jon

-- 
Jonathan "Taz" Mischo                     ph: +1.847.632.4039
Lead Software Engineer                    mn: +1.815.302.3505
Advanced Systems Technology Department    fx: +1.847.435.9970
Network Sector                            em: taz@em.cig.mot.com
Motorola, Inc.                            hp: http://www.refcode.org/taz/



From owner-seamoby@diameter.org  Mon Jan 22 04:38:39 2001
Received: from charizard.diameter.org ([24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00946
	for <seamoby-archive@odin.ietf.org>; Mon, 22 Jan 2001 04:38:38 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0M8q7N11088
	for seamoby-list; Mon, 22 Jan 2001 00:52:07 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from sirius.ctr.columbia.edu (sirius.ctr.columbia.edu [128.59.64.60])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0M8q4o11083
	for <seamoby@diameter.org>; Mon, 22 Jan 2001 00:52:04 -0800
Received: from SWEETPEA (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with SMTP id CAA01589; Mon, 22 Jan 2001 02:59:31 -0500 (EST)
From: "Andrew T. Campbell" <campbell@comet.columbia.edu>
To: <john.loughney@nokia.com>, <seamoby@diameter.org>
Cc: "Andrew Campbell \(E-mail\)" <campbell@comet.columbia.edu>
Subject: RE: [seamoby] More beating my head against the wall....
Date: Mon, 22 Jan 2001 02:58:50 -0800
Message-ID: <006801c08462$4e13dd40$3d443b80@SWEETPEA>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680A7CE@eseis04nok>
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


John:

Not sure we need to go down this route but since
you asked.

Significant signaling overhead; therefore air, CN and 
Internet bandwidth. 

We have made MIP go as fast as CIP in the lab but these 
penalties stand undisputed - (I'll apologies to
Charlie and Dave in advance).

Not that anyone has published a thorough set of data
to back up such a claim - its a little like the 'RSVP
doesn't scale' innuendo.

---
Andrew
http://comet.columbia.edu/~campbell


> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Sunday, January 21, 2001 11:43 PM
> To: campbell@comet.columbia.edu; seamoby@diameter.org
> Subject: RE: [seamoby] More beating my head against the wall....
> 
> 
> Hi Andrew,
> 
> > I should of added (to my Nop) that CIP is fast but you can tune MIP 
> > to operate "fast" but there are penalties to doing that; hence the 
> > need for edge mobility. 
> 
> What are the penalties?  
> 
> br,
> John
> 


From owner-seamoby@diameter.org  Mon Jan 22 04:45:07 2001
Received: from charizard.diameter.org ([24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00994
	for <seamoby-archive@odin.ietf.org>; Mon, 22 Jan 2001 04:45:06 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0M8a2u11035
	for seamoby-list; Mon, 22 Jan 2001 00:36:02 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0M8Zxo11030
	for <seamoby@diameter.org>; Mon, 22 Jan 2001 00:35:59 -0800
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0M7hF115180
	for <seamoby@diameter.org>; Mon, 22 Jan 2001 09:43:16 +0200 (EET)
Received: from esebh02nok.ntc.nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T51424bb8aeac158f25117@esvir05nok.ntc.nokia.com>;
 Mon, 22 Jan 2001 09:43:29 +0200
Received: by esebh02nok with Internet Mail Service (5.5.2652.78)
	id <C0KGXBAN>; Mon, 22 Jan 2001 09:43:29 +0200
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680A7CE@eseis04nok>
From: john.loughney@nokia.com
To: campbell@comet.columbia.edu, seamoby@diameter.org
Subject: RE: [seamoby] More beating my head against the wall....
Date: Mon, 22 Jan 2001 09:43:29 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Andrew,

> I should of added (to my Nop) that CIP is fast but you can tune MIP 
> to operate "fast" but there are penalties to doing that; hence the 
> need for edge mobility. 

What are the penalties?  

br,
John


From owner-seamoby@diameter.org  Mon Jan 22 04:45:59 2001
Received: from charizard.diameter.org ([24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01010
	for <seamoby-archive@odin.ietf.org>; Mon, 22 Jan 2001 04:45:59 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0M8sUM11097
	for seamoby-list; Mon, 22 Jan 2001 00:54:30 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0M8sRo11092
	for <seamoby@diameter.org>; Mon, 22 Jan 2001 00:54:27 -0800
Received: from esvir06nok.ntc.nokia.com (esvir06nokt.ntc.nokia.com [172.21.143.38])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0M81xs12026
	for <seamoby@diameter.org>; Mon, 22 Jan 2001 10:01:59 +0200 (EET)
Received: from esebh01nok.ntc.nokia.com (unverified) by esvir06nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T51425c97e4ac158f26115@esvir06nok.ntc.nokia.com>;
 Mon, 22 Jan 2001 10:01:55 +0200
Received: by esebh01nok with Internet Mail Service (5.5.2652.78)
	id <C0KDSY0B>; Mon, 22 Jan 2001 10:01:55 +0200
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680A7D0@eseis04nok>
From: john.loughney@nokia.com
To: campbell@comet.columbia.edu, seamoby@diameter.org
Subject: RE: [seamoby] More beating my head against the wall....
Date: Mon, 22 Jan 2001 10:01:52 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Andrew,

> Not sure we need to go down this route but since
> you asked.

I wasn't challenging your comments, I just wanted 
to get an idea.

> Not that anyone has published a thorough set of data
> to back up such a claim - its a little like the 'RSVP
> doesn't scale' innuendo.

I was really hoping someone did ... Anyhow, thanks for
the comments, I just wanted to get an idea of what 
you were talking about.

thanks,
John


From owner-seamoby@diameter.org  Mon Jan 22 05:39:37 2001
Received: from charizard.diameter.org ([24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01344
	for <seamoby-archive@odin.ietf.org>; Mon, 22 Jan 2001 05:39:36 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0M98Sn11113
	for seamoby-list; Mon, 22 Jan 2001 01:08:28 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0M98Po11108
	for <Seamoby@diameter.org>; Mon, 22 Jan 2001 01:08:26 -0800
Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0M8Fws18868
	for <Seamoby@diameter.org>; Mon, 22 Jan 2001 10:15:58 +0200 (EET)
Received: from esebh01nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T51426961e7ac158f22148@esvir02nok.nokia.com>;
 Mon, 22 Jan 2001 10:15:53 +0200
Received: by esebh01nok with Internet Mail Service (5.5.2652.78)
	id <C0KDS7HB>; Mon, 22 Jan 2001 10:15:53 +0200
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680A7D3@eseis04nok>
From: john.loughney@nokia.com
To: Pat.Calhoun@eng.sun.com
Cc: Seamoby@diameter.org, seamoby-mm@cdma-2000.org
Subject: RE: [seamoby-mm] RE: [seamoby] micro, schmicro
Date: Mon, 22 Jan 2001 10:15:50 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Pat,

> Using statements like complexity is a red-herring. I've 
> implemented Mobile IP,
> and it really isn't that complex. Any piece of code is 
> complex, so I would
> argue that it will be very hard to justify another protocol 
> to solve non edge routing.

I agree and do think that when all is said and done, 
the solution developed in SeaMoby will be fairly 
complex as well.

John


From owner-seamoby@diameter.org  Mon Jan 22 05:54:51 2001
Received: from charizard.diameter.org ([24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01404
	for <seamoby-archive@odin.ietf.org>; Mon, 22 Jan 2001 05:54:51 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0MASYQ11187
	for seamoby-list; Mon, 22 Jan 2001 02:28:34 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (flipper.cisco.com [171.69.25.141])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0MASWo11181
	for <seamoby@diameter.org>; Mon, 22 Jan 2001 02:28:32 -0800
Received: from dblair-pc (ssh-sj1.cisco.com [171.68.225.134])
	by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id BAA07091;
	Mon, 22 Jan 2001 01:35:23 -0800 (PST)
Message-Id: <4.1.20010122042705.043c35e0@flipper.cisco.com>
X-Sender: dblair@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 22 Jan 2001 04:28:44 -0500
To: john.loughney@nokia.com, campbell@comet.columbia.edu, seamoby@diameter.org
From: Dana Blair <dblair@cisco.com>
Subject: RE: [seamoby] More beating my head against the wall....
In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680A7D0@eseis04nok>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-seamoby@diameter.org
Precedence: bulk

At 10:01 AM 1/22/01 +0200, john.loughney@nokia.com wrote:
>Hi Andrew,
>
>> Not sure we need to go down this route but since
>> you asked.
>
>I wasn't challenging your comments, I just wanted 
>to get an idea.
>
>> Not that anyone has published a thorough set of data
>> to back up such a claim - its a little like the 'RSVP
>> doesn't scale' innuendo.
>
>I was really hoping someone did ... Anyhow, thanks for
>the comments, I just wanted to get an idea of what 
>you were talking about.

Once we have a problem statement for our (micro)mobility design
team that is accepted by the IESG, we can create a set of criteria
to judge various mobility solutions.  

thanks,
Dana

>
>thanks,
>John



From owner-seamoby@diameter.org  Mon Jan 22 06:08:13 2001
Received: from charizard.diameter.org ([24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01509
	for <seamoby-archive@odin.ietf.org>; Mon, 22 Jan 2001 06:08:12 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0MAUOG11198
	for seamoby-list; Mon, 22 Jan 2001 02:30:24 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0MAULo11193
	for <seamoby@diameter.org>; Mon, 22 Jan 2001 02:30:21 -0800
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0M9c3J07377
	for <seamoby@diameter.org>; Mon, 22 Jan 2001 11:38:03 +0200 (EET)
Received: from esebh12nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T5142b474b9ac158f2314e@esvir03nok.nokia.com>;
 Mon, 22 Jan 2001 11:37:53 +0200
Received: by esebh12nok with Internet Mail Service (5.5.2652.78)
	id <DH8KKABW>; Mon, 22 Jan 2001 11:37:53 +0200
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680A7DA@eseis04nok>
From: john.loughney@nokia.com
To: dblair@cisco.com, seamoby@diameter.org
Subject: RE: [seamoby] More beating my head against the wall....
Date: Mon, 22 Jan 2001 11:37:52 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Dana,

> Once we have a problem statement for our (micro)mobility design
> team that is accepted by the IESG, we can create a set of criteria
> to judge various mobility solutions.  

Which I am trying to compile, as an alpha-document.  Hopefully,
I will have something out on the MM list today.  As per my
usual mantra, I am trying to keep it simple, and hopefully
stay above the debate ...

John


From owner-seamoby@diameter.org  Mon Jan 22 06:31:55 2001
Received: from charizard.diameter.org ([24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01622
	for <seamoby-archive@odin.ietf.org>; Mon, 22 Jan 2001 06:31:55 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0MB5W011237
	for seamoby-list; Mon, 22 Jan 2001 03:05:32 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mail.northstream.se ([62.20.120.194])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f0MB5To11232
	for <seamoby@diameter.org>; Mon, 22 Jan 2001 03:05:30 -0800
Received: from exchange.northstream.se by mail.northstream.se
          via smtpd (for c900656-a.plstn1.sfba.home.com [24.20.167.220]) with SMTP; 22 Jan 2001 10:13:02 UT
Received: by exchange.northstream.se with Internet Mail Service (5.5.2650.21)
	id <CJ4YQTT7>; Mon, 22 Jan 2001 11:12:30 +0100
Message-ID: <93E299DA8B7DD411904300D0B7D483433EF96F@exchange.northstream.se>
From: Jerome Privat <jerome.privat@northstream.se>
To: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        Phil Neumiller
	 <neumiller@telocity.com>
Cc: seamoby@diameter.org
Subject: RE: [seamoby] Location finding methods versus MIP home agent.
Date: Mon, 22 Jan 2001 11:12:21 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

No, the HLR/VLR is going away in the ALL IP cellular networks, and being
replaced with Mobile IP, for mobility management, and AAA, for
authentication,
authorization and home agent assignment. > 

Pat,

When mentioning the "All IP cellular networks", I guess you are refering to
the work in 3GPP2 and not in 3GPP. As far as I know, in 3GPP (even Release
5), the HLR (or HSS)/VLR does not go away and GTP is used for mobility
management.

Jerome



From owner-seamoby@diameter.org  Mon Jan 22 12:21:01 2001
Received: from charizard.diameter.org ([24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09365
	for <seamoby-archive@odin.ietf.org>; Mon, 22 Jan 2001 12:21:01 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0MG7Gq11820
	for seamoby-list; Mon, 22 Jan 2001 08:07:16 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0MG7Do11815
	for <seamoby@diameter.org>; Mon, 22 Jan 2001 08:07:13 -0800
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03134;
	Mon, 22 Jan 2001 07:14:41 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA04528;
	Mon, 22 Jan 2001 07:14:38 -0800 (PST)
Received: from cinnamon (cinnamon [129.146.122.100])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA12473;
	Mon, 22 Jan 2001 07:14:38 -0800 (PST)
Date: Mon, 22 Jan 2001 07:13:46 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: RE: [seamoby] Location finding methods versus MIP home agent.
To: Jerome Privat <jerome.privat@northstream.se>
Cc: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        Phil Neumiller <neumiller@telocity.com>, seamoby@diameter.org
In-Reply-To: "Your message with ID" <93E299DA8B7DD411904300D0B7D483433EF96F@exchange.northstream.se>
Message-ID: <Roam.SIMC.2.0.6.980176426.29312.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

> No, the HLR/VLR is going away in the ALL IP cellular networks, and being
> replaced with Mobile IP, for mobility management, and AAA, for
> authentication,
> authorization and home agent assignment. > 
> 
> Pat,
> 
> When mentioning the "All IP cellular networks", I guess you are refering to
> the work in 3GPP2 and not in 3GPP. As far as I know, in 3GPP (even Release
> 5), the HLR (or HSS)/VLR does not go away and GTP is used for mobility
> management.
> 
<biased north american hat>
oops, yes. 
</biased north american hat>

Of course 3GPP is different. I am still unsure as to whether 3GPP has even
agreed that AAA is in the HSS.

PatC



From owner-seamoby@diameter.org  Mon Jan 22 15:09:52 2001
Received: from charizard.diameter.org ([24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13349
	for <seamoby-archive@odin.ietf.org>; Mon, 22 Jan 2001 15:09:52 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0MIt4J12496
	for seamoby-list; Mon, 22 Jan 2001 10:55:04 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0MIt1o12491
	for <seamoby@diameter.org>; Mon, 22 Jan 2001 10:55:02 -0800
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1])
	by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA19768
	for <seamoby@diameter.org>; Mon, 22 Jan 2001 13:02:35 -0500 (EST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150])
	by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA19750
	for <seamoby@diameter.org>; Mon, 22 Jan 2001 13:02:34 -0500 (EST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21)
	id <CZ4GCMB7>; Mon, 22 Jan 2001 18:02:30 -0000
Message-ID: <976F7C55E3B2D111A0720008C728549C04877748@en0060exch001u.uk.lucent.com>
From: "Casati, Alessio (Alessio)" <acasati@lucent.com>
To: Jerome Privat <jerome.privat@northstream.se>,
        "'Pat Calhoun'"
	 <Pat.Calhoun@eng.sun.com>
Cc: Phil Neumiller <neumiller@telocity.com>, seamoby@diameter.org
Subject: RE: [seamoby] Location finding methods versus MIP home agent.
Date: Mon, 22 Jan 2001 18:02:25 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-seamoby@diameter.org
Precedence: bulk

3GPP is actually considering using AAA
(DIAMETER) in the HSS (for the Cx interface). 
No choice has already
been taken, though. There has been an agreement
on the fact that much in the same way as MAP allows
for AC (application contexts) upgrades, the
protocol(s) used on the Cx interface need to support
a versioning mechanisms (so that the addition of new
non backward compatible functionality does not 
damage the installed base).

There is currently a pending issue on which part of 3GPP should
own the architectural and system decisions on the Cx interface.

alessio



> > When mentioning the "All IP cellular networks", I guess you are refering
> to
> > the work in 3GPP2 and not in 3GPP. As far as I know, in 3GPP (even
> Release
> > 5), the HLR (or HSS)/VLR does not go away and GTP is used for mobility
> > management.
> > 
> <biased north american hat>
> oops, yes. 
> </biased north american hat>
> 
> Of course 3GPP is different. I am still unsure as to whether 3GPP has even
> agreed that AAA is in the HSS.
> 
> PatC
> 


From owner-seamoby@diameter.org  Tue Jan 23 18:42:36 2001
Received: from charizard.diameter.org ([24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26443
	for <seamoby-archive@odin.ietf.org>; Tue, 23 Jan 2001 18:42:35 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0NNaR814695
	for seamoby-list; Tue, 23 Jan 2001 15:36:27 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0NNaOo14690
	for <seamoby@diameter.org>; Tue, 23 Jan 2001 15:36:25 -0800
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id OAA18645;
	Tue, 23 Jan 2001 14:43:59 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAR00037;
	Tue, 23 Jan 2001 14:43:54 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA26698; Tue, 23 Jan 2001 14:43:49 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14958.2341.253708.222076@thomasm-u1.cisco.com>
Date: Tue, 23 Jan 2001 14:43:49 -0800 (PST)
To: Phil_Neumiller@3Com.com
Cc: seamoby@diameter.org
Subject: [seamoby] [MOBILE-IP] BURP BOF
In-Reply-To: <882569D9.0062F45A.00@hqoutbound.ops.3com.com>
References: <882569D9.0062F45A.00@hqoutbound.ops.3com.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


What I've never been clear on is how -- especially
for MIPv6 -- the leap was made that MIP is the
moral equivalent of PPP/CHAP. _I_ thought that MIP
was intented to affect routing changes, not to be a 
catch all for access control. 

	      Mike

Phil_Neumiller@3Com.com writes:
 > 
 > 
 > According to the description of this new BOF, mobile IP already provides
 > "seamless and continuous connectivity".  Hmm, what in the world
 > is SeaMoby for?
 > 
 > Creating a standardized registration protocol for the  application layer
 > makes a lot of sense.  Perhaps some of the UPnP/SLP work can be
 > useful here.
 > 
 > 
 > ---------------------- Forwarded by Phil Neumiller/MW/US/3Com on 01/19/2001
 > 11:48 AM ---------------------------
 > 
 > Please respond to Basavaraj.Patil@nokia.com
 > 
 > Sent by:  Basavaraj Patil <Basavaraj.Patil@nokia.com>
 > 
 > 
 > A BOF on Basic User Registration Protocol (BURP)
 > 
 > 
 > Charter:
 > 
 > The vision of pervasive computing also includes constantly being
 > connected and the ability to access the Internet or the enterprise
 > over the Internet. Mobile computing solutions based on protocols such
 > as Mobile IP offer seamless and continuous connectivity for
 > users. However a lot of roadwarriors and other types
 > of users access the network from places like airports, hotels, malls
 > and sports complexes. These environments may offer access to the
 > network over wireless LANs or via Ethernet LAN ports or other
 > mediums. In such scenarios,
 > DHCP can provide configuration information  (e.g., giving a valid
 > address etc.), but there is no standard way for service providers to
 > obtain user information to perform AAA functions. For users
 > who do not have Mobile IP clients on their devices but would like to
 > access the network, they need to register and be authenticated by the
 > local network service provider before being authorized to use the
 > resources. The intent of this proposal is to develop an application
 > layer registration protocol that allows a user to register in the
 > local network by providing identity and authentication information
 > to the local network which then uses a AAA infrastructure to validate
 > the user, charge him and, authorize use of resources.
 > 
 > We would like to request a BOF on a "Basic User Registration
 > Protocol (BURP)" for the March 2001 meeting of the IETF in Minneapolis.
 > The objective of the BOF will be to
 > -- Detail the scope of the proposal and applicable scenarios
 > 
 > -- Chart a course and an action plan (including milestones
 > and deliverables) for BURP.
 > 
 > -- Investigate  the impact on existing  AAA  protocols  and  make it
 > flexible to support various authentication schemes.
 > 
 > The goal will be to define a standard UNI for  environments in which
 > neither PPP nor Mobile IP is required but AAA interaction is
 > essential.  The basic principle will include:
 > 
 >   -- The solution being a client-server application layer protocol
 > 
 >   -- Is applicable to both IPv4 and IPv6.
 > 
 >   -- User interacts only with a local Registration Agent (RA), which
 >   may reside on any node in the Network Domain.
 > 
 >   -- It should work with any configuration  protocol, such as DHCP, IPv6
 >   stateless autoconfiguration, and manual configuration.
 > 
 >   -- Protects RA from replay attacks.
 > 
 >   -- Provide information on and control of network usage.
 > 
 >   -- Interacts with routers/policers to limit packets forwarding based on a
 >   user's Service Level  Specification  (may be optional or may
 >   interwork with  standard policy protocols).
 > 
 >   -- Defines an RA-to-AAA interface
 > 
 > -----------------------------------------------------------------------
 > 
 > To subscribe to the mailing list for discussion on this topic, please
 > follow these instructions:
 > 
 > To subscribe, send mail to urp-request@research.telcordia.com, and
 > use "subscribe" for the subject line.
 > 
 > To unsubscribe, send mail to urp-request@research.telcordia.com, and
 > use "unsubscribe" for the subject line.
 > 
 > To contribute to the list, send mail to urp@research.telcordia.com.
 > 
 > For additional help, send mail to urp-request@research.telcordia.com
 > and use "help" for the subject line.
 > 
 > 
 > 
 > 


From owner-seamoby@diameter.org  Tue Jan 23 20:37:22 2001
Received: from charizard.diameter.org ([24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27768
	for <seamoby-archive@odin.ietf.org>; Tue, 23 Jan 2001 20:37:21 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0O1a1S14780
	for seamoby-list; Tue, 23 Jan 2001 17:36:01 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0O1Zwo14775
	for <seamoby@diameter.org>; Tue, 23 Jan 2001 17:35:58 -0800
Received: from agate.ops.3com.com (agate.3com.com [139.87.50.118])
	by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f0O0gN111039;
	Tue, 23 Jan 2001 16:42:23 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104])
	by agate.ops.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f0O0hV223073;
	Tue, 23 Jan 2001 16:43:31 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 882569DE.00042361 ; Tue, 23 Jan 2001 16:45:12 -0800
X-Lotus-FromDomain: 3COM
From: Phil_Neumiller@3Com.com
To: Michael Thomas <mat@cisco.com>
cc: seamoby@diameter.org
Message-ID: <882569DE.00042063.00@hqoutbound.ops.3com.com>
Date: Tue, 23 Jan 2001 18:51:06 -0600
Subject: [seamoby] Was BURP BOF, now a dark revelation...
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-seamoby@diameter.org
Precedence: bulk




Michael,

Yes, that is the party line.  I am not happy with it.  So a (growing)
number of us have decided that SeaMoby has been more-or-less
deprived of its original spirit, and sadly, we are going to re-double,
our new contributions in the MIP WG.   Oh well,  we did try to make
a go of it here.  I hope we can sustain the amount of interest and
high quality creative ideas that have been flowing in to the SeaMoby
lists when we get over there.  I have a sneaking  suspicion that we
are just going to contribute to the additive white gaussian noise on
those lists....  :-(

Sincerely,

Phil Neumiller



What I've never been clear on is how -- especially
for MIPv6 -- the leap was made that MIP is the
moral equivalent of PPP/CHAP. _I_ thought that MIP
was intented to affect routing changes, not to be a
catch all for access control.

           Mike






From owner-seamoby@diameter.org  Tue Jan 23 20:47:18 2001
Received: from charizard.diameter.org ([24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27844
	for <seamoby-archive@odin.ietf.org>; Tue, 23 Jan 2001 20:47:17 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0O1jFH14791
	for seamoby-list; Tue, 23 Jan 2001 17:45:15 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0O1jDo14786
	for <seamoby@diameter.org>; Tue, 23 Jan 2001 17:45:13 -0800
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA21737;
	Tue, 23 Jan 2001 16:52:48 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA23436;
	Tue, 23 Jan 2001 16:52:46 -0800 (PST)
Received: from cinnamon (cinnamon [129.146.122.100])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA07387;
	Tue, 23 Jan 2001 16:52:39 -0800 (PST)
Date: Tue, 23 Jan 2001 16:51:39 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [seamoby] Was BURP BOF, now a dark revelation...
To: Phil_Neumiller@3Com.com
Cc: Michael Thomas <mat@cisco.com>, seamoby@diameter.org
In-Reply-To: "Your message with ID" <882569DE.00042063.00@hqoutbound.ops.3com.com>
Message-ID: <Roam.SIMC.2.0.6.980297499.11452.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

I'm assuming that Phil here is refering to Micro-Mobility, and not context
transfer or paging. However, the Micro-Mobility folks have a working draft,
and are under the assumption that there is work to be done.

That said, is MIP the equivalent of PPP? Well the question that I would ask
you is why impose a circuit switched model on next generation wireless
technologies that are actually moving AWAY from circuit switched models? In
CDMA, some services ONLY use PPP for its HDLC framing, not good protocol use,
IMHO.

So, MIP provides user authentication for network access. Is this replicating
PPP? Well, not any more than RSVP does user authentication. So, perhaps I am
misunderstanding your comment. Could you clarify?

PatC
> 
> 
> 
> Michael,
> 
> Yes, that is the party line.  I am not happy with it.  So a (growing)
> number of us have decided that SeaMoby has been more-or-less
> deprived of its original spirit, and sadly, we are going to re-double,
> our new contributions in the MIP WG.   Oh well,  we did try to make
> a go of it here.  I hope we can sustain the amount of interest and
> high quality creative ideas that have been flowing in to the SeaMoby
> lists when we get over there.  I have a sneaking  suspicion that we
> are just going to contribute to the additive white gaussian noise on
> those lists....  :-(
> 
> Sincerely,
> 
> Phil Neumiller
> 
> 
> 
> What I've never been clear on is how -- especially
> for MIPv6 -- the leap was made that MIP is the
> moral equivalent of PPP/CHAP. _I_ thought that MIP
> was intented to affect routing changes, not to be a
> catch all for access control.
> 
>            Mike
> 
> 
> 
> 




From owner-seamoby@diameter.org  Tue Jan 23 21:31:09 2001
Received: from charizard.diameter.org ([24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28315
	for <seamoby-archive@odin.ietf.org>; Tue, 23 Jan 2001 21:31:08 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0O2AnB14811
	for seamoby-list; Tue, 23 Jan 2001 18:10:49 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0O2Alo14806
	for <seamoby@diameter.org>; Tue, 23 Jan 2001 18:10:47 -0800
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA06549;
	Tue, 23 Jan 2001 17:18:31 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAR00040;
	Tue, 23 Jan 2001 17:18:20 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA26764; Tue, 23 Jan 2001 17:18:20 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14958.11611.851416.550235@thomasm-u1.cisco.com>
Date: Tue, 23 Jan 2001 17:18:19 -0800 (PST)
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: Phil_Neumiller@3Com.com, Michael Thomas <mat@cisco.com>,
        seamoby@diameter.org
Subject: Re: [seamoby] Was BURP BOF, now a dark revelation...
In-Reply-To: <Roam.SIMC.2.0.6.980297499.11452.pcalhoun@nasnfs>
References: <882569DE.00042063.00@hqoutbound.ops.3com.com>
	<Roam.SIMC.2.0.6.980297499.11452.pcalhoun@nasnfs>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat Calhoun writes:
 > That said, is MIP the equivalent of PPP? Well the question that I would ask
 > you is why impose a circuit switched model on next generation wireless
 > technologies that are actually moving AWAY from circuit switched models? In
 > CDMA, some services ONLY use PPP for its HDLC framing, not good protocol use,
 > IMHO.

   I said moral equivalent. PPP/CHAP/RADIUS ~= MIP/IPSEC/DIAMETER(?)

   And I'm not imposing any circuits on anybody.
 
 > So, MIP provides user authentication for network access. Is this replicating
 > PPP? Well, not any more than RSVP does user authentication. So, perhaps I am
 > misunderstanding your comment. Could you clarify?

   So does RSVP. So does L2TP. So does (somewhat more tenuously)
   IKE...

   The charter of the BOF specifically states that when MIP
   is present, it should be used as the access mechanism. The
   same can be said of all of the above too, so I wonder why
   there is a reason why MIP was effectively given a preferential
   status in the charter over other methods of filling the PPP/CHAP
   vacuum, especially when it's not in MIP's charter  -- as far as
   I know -- to be a network access mechanism. That and it is seemingly
   at odds with the way that v6 MIP works (which doesn't have a
   FA at all). 

   Either the BOF should say that it wants to make MIP into the
   new access protocol, or it should remove any preferential
   status to MIP so that we can go back to first principles.
   The mix as stated is either setting itself up for a conflict,
   or is presupposing the outcome, both of which seem like a bad
   idea.

			Mike


From owner-seamoby@diameter.org  Tue Jan 23 23:06:05 2001
Received: from charizard.diameter.org ([24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01213
	for <seamoby-archive@odin.ietf.org>; Tue, 23 Jan 2001 23:06:04 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0O3d2C14861
	for seamoby-list; Tue, 23 Jan 2001 19:39:02 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from c007.snv.cp.net (c007-h008.c007.snv.cp.net [209.228.33.214])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f0O3cxo14856
	for <seamoby@diameter.org>; Tue, 23 Jan 2001 19:39:00 -0800
Received: (cpmta 10633 invoked from network); 23 Jan 2001 18:35:17 -0800
Received: from dsl-64-193-0-129.telocity.com (HELO telocity.com) (64.193.0.129)
  by smtp.telocity.com (209.228.33.214) with SMTP; 23 Jan 2001 18:35:17 -0800
X-Sent: 24 Jan 2001 02:35:17 GMT
Message-ID: <3A6E3FD9.6747584F@telocity.com>
Date: Tue, 23 Jan 2001 20:37:13 -0600
From: Phil Neumiller <neumiller@telocity.com>
Organization: 3Com
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
CC: Phil_Neumiller@3Com.com, Michael Thomas <mat@cisco.com>,
        seamoby@diameter.org
Subject: Re: [seamoby] Was BURP BOF, now a dark revelation...
References: <Roam.SIMC.2.0.6.980297499.11452.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat Calhoun wrote:
> 
> I'm assuming that Phil here is refering to Micro-Mobility, and not context
> transfer or paging. However, the Micro-Mobility folks have a working draft,
> and are under the assumption that there is work to be done.
> 

I don't want to get off on a rant here...

No, Phil is saying this about the whole schebang from his somewhat biased,
perverse, and obviously medicated (little blue pills) point of view. 

Context transfer SHOULD be inextricably linked to handover, which MUST be
inextricably linked to tunneling/routing (in the general case), which MUST
be inextricably linked to the MIP WG.  Thus, by transitive closure, the
work must move to the MIP WG.  Paging becomes irrelevant, if MIP is assumed,
since the location of the MN is always known and there is no longer a need
to "find" it.

...but then again I could be wrong!

-pdn


From owner-seamoby@diameter.org  Tue Jan 23 23:30:26 2001
Received: from charizard.diameter.org ([24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01566
	for <seamoby-archive@odin.ietf.org>; Tue, 23 Jan 2001 23:30:24 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0O4Gqm14905
	for seamoby-list; Tue, 23 Jan 2001 20:16:52 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from c007.snv.cp.net (c007-h008.c007.snv.cp.net [209.228.33.214])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f0O4Gno14900
	for <seamoby@diameter.org>; Tue, 23 Jan 2001 20:16:50 -0800
Received: (cpmta 21992 invoked from network); 23 Jan 2001 19:00:51 -0800
Received: from dsl-64-193-0-129.telocity.com (HELO telocity.com) (64.193.0.129)
  by smtp.telocity.com (209.228.33.214) with SMTP; 23 Jan 2001 19:00:51 -0800
X-Sent: 24 Jan 2001 03:00:51 GMT
Message-ID: <3A6E45D8.CA2F5AD3@telocity.com>
Date: Tue, 23 Jan 2001 21:02:48 -0600
From: Phil Neumiller <neumiller@telocity.com>
Organization: 3Com
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Dave Martin <dmartin@kreative.net>, seamoby@diameter.org
Subject: [seamoby] Was Dave Martin's comments, now echos of OBAST
References: <Roam.SIMC.2.0.6.980100261.11059.pcalhoun@nasnfs> <011201c083ee$179268a0$0100000a@david>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Dave,

> 
> Micro/edge mobility is already solved in most large wireless networks, it's
> just that there is no global standard, and that the mobility is typically
> done at layer 2.  There is value in having a unified standard to rally
> around, and to formally define how layer 2 and layer 3 mobility protocols
> should work together.

This is a great observation.  When we started the OBAST work, open base
station transport, we observed LOTS (upto 90%), commonality between all
the worlds cellular systems (in what they actually do).  We thought that
a single bearer and signalling transport format (augmented by SCTP) could
be defined and absolutely hide any radio specific technology thus facilitating 
macro-diversity and handoff between heterogenous radio technologies.

This original OBAST concept has been lost in the formulation of the
SeaMoby charter. :-(  Its too bad, since it is something that fits nicely
in the IETF transport work area.  Maybe we can revive this as part of 
SeaMoby.

> 
> Your question does actually raise an interesting point. A HA's purpose is to
> shield the rest of the network from changes in routing topology as a node
> moves from subnet to subnet.  Isn't the intra-domain/micro-mobility problem
> basically the same problem at a finer layer--namely to shield the HA from
> changes in routing topology?

I like this thinking too.  Its sort of like applying a recursive algorithm.
But... then again, isn't this sort of how HMIP works?

Take it easy,

Phil


From owner-seamoby@diameter.org  Wed Jan 24 12:45:45 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26373
	for <seamoby-archive@odin.ietf.org>; Wed, 24 Jan 2001 12:45:45 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0OGXum15809
	for seamoby-list; Wed, 24 Jan 2001 08:33:56 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0OGXqo15789
	for <seamoby@diameter.org>; Wed, 24 Jan 2001 08:33:52 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 24 Jan 2001 10:18:35 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <D33PCYL6>; Wed, 24 Jan 2001 10:18:35 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8B8E@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>, Phil_Neumiller@3Com.com
Cc: Michael Thomas <mat@cisco.com>, seamoby@diameter.org
Subject: RE: [seamoby] Was BURP BOF, now a dark revelation...
Date: Wed, 24 Jan 2001 10:18:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C08618.E5DB8580"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C08618.E5DB8580
Content-Type: text/plain;
	charset="ISO-8859-1"

> -----Original Message-----
> From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com]
> Sent: Tuesday, January 23, 2001 7:52 PM
> To: Phil_Neumiller@3Com.com
> Cc: Michael Thomas; seamoby@diameter.org
> Subject: Re: [seamoby] Was BURP BOF, now a dark revelation...
> 
> 
*snip*

> That said, is MIP the equivalent of PPP? Well the question 
> that I would ask
> you is why impose a circuit switched model on next generation wireless
> technologies that are actually moving AWAY from circuit 
> switched models? In

Really? I'd wait until the actual standard comes out before I would make
this assertion. 95% of all revenues in cellular come from voice, and until 
proven otherwise, the best proven solution for voice remains is circuit
switched.
Packet solutions continue to be layered on top of the voice circuit switched
services, and therein, IMHO, lays the beginning of the problem.

There have been packet over the air networks designed and built - mostly
for private users. They provide high reliability, low handover latency (<
10ms),
and some even support voice. The technology works, it simply does not mesh
well with the circuit switched paradigm.

I know, I digress. But, the wg chair brought it up ;^}.

*snip*

Gary

------_=_NextPart_001_01C08618.E5DB8580
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] Was BURP BOF, now a dark revelation...</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Pat Calhoun [<A HREF="mailto:Pat.Calhoun@eng.sun.com">mailto:Pat.Calhoun@eng.sun.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Tuesday, January 23, 2001 7:52 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Phil_Neumiller@3Com.com</FONT>
<BR><FONT SIZE=2>&gt; Cc: Michael Thomas; seamoby@diameter.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: [seamoby] Was BURP BOF, now a dark revelation...</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>*snip*</FONT>
</P>

<P><FONT SIZE=2>&gt; That said, is MIP the equivalent of PPP? Well the question </FONT>
<BR><FONT SIZE=2>&gt; that I would ask</FONT>
<BR><FONT SIZE=2>&gt; you is why impose a circuit switched model on next generation wireless</FONT>
<BR><FONT SIZE=2>&gt; technologies that are actually moving AWAY from circuit </FONT>
<BR><FONT SIZE=2>&gt; switched models? In</FONT>
</P>

<P><FONT SIZE=2>Really? I'd wait until the actual standard comes out before I would make</FONT>
<BR><FONT SIZE=2>this assertion. 95% of all revenues in cellular come from voice, and until </FONT>
<BR><FONT SIZE=2>proven otherwise, the best proven solution for voice remains is circuit switched.</FONT>
<BR><FONT SIZE=2>Packet solutions continue to be layered on top of the voice circuit switched</FONT>
<BR><FONT SIZE=2>services, and therein, IMHO, lays the beginning of the problem.</FONT>
</P>

<P><FONT SIZE=2>There have been packet over the air networks designed and built - mostly</FONT>
<BR><FONT SIZE=2>for private users. They provide high reliability, low handover latency (&lt; 10ms),</FONT>
<BR><FONT SIZE=2>and some even support voice. The technology works, it simply does not mesh</FONT>
<BR><FONT SIZE=2>well with the circuit switched paradigm.</FONT>
</P>

<P><FONT SIZE=2>I know, I digress. But, the wg chair brought it up ;^}.</FONT>
</P>

<P><FONT SIZE=2>*snip*</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C08618.E5DB8580--


From owner-seamoby@diameter.org  Wed Jan 24 15:55:20 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00548
	for <seamoby-archive@odin.ietf.org>; Wed, 24 Jan 2001 15:55:20 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0OJejN16109
	for seamoby-list; Wed, 24 Jan 2001 11:40:45 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0OJego16104
	for <seamoby@diameter.org>; Wed, 24 Jan 2001 11:40:42 -0800
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA25050;
	Wed, 24 Jan 2001 10:48:12 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f0OImBG11858;
	Wed, 24 Jan 2001 10:48:11 -0800
X-Virus-Scanned:  Wed, 24 Jan 2001 10:48:11 -0800 Nokia Silicon Valley Email Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdY2OHWe; Wed, 24 Jan 2001 10:47:44 PST
Message-ID: <3A6F2351.12C2A241@iprg.nokia.com>
Date: Wed, 24 Jan 2001 10:47:45 -0800
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: john.loughney@nokia.com
CC: seamoby@diameter.org
Subject: [seamoby] Re: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt
References: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hello John,

Thanks for the mention.  I'll just point out that this is
a highly preliminary document.  We are having a two-day
interim design team meeting next week.  That meeting will
almost surely result in significant revisions to the
handover document.  So, please don't shoot us if the
next document looks different!

I'll also mention that [seamoby-context] topics have come
up in our discussions multiple times, generally with two
major themes:

1) We want our work to be useful to [seamoby-context]

2) We do NOT want to crowd the [seamoby-context] design
   space, but insteady to offer something useful in the
   likely case that context transfer will coincide with
   Mobile IPv6-based handovers.  It would be bad to have
   two different protocols for that time-critical operation.

Themes from [seamoby-mm] have also been discussed at length.
We want to be compatible with whatever such protocols are
eventually standardized.

Regards,
Charlie P.


From owner-seamoby@diameter.org  Wed Jan 24 15:56:50 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00616
	for <seamoby-archive@odin.ietf.org>; Wed, 24 Jan 2001 15:56:49 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0OJuu316122
	for seamoby-list; Wed, 24 Jan 2001 11:56:56 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0OJuro16117
	for <seamoby@diameter.org>; Wed, 24 Jan 2001 11:56:53 -0800
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id LAA01166;
	Wed, 24 Jan 2001 11:04:32 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAR00048;
	Wed, 24 Jan 2001 11:04:28 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA27015; Wed, 24 Jan 2001 11:04:28 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14959.10043.930142.584182@thomasm-u1.cisco.com>
Date: Wed, 24 Jan 2001 11:04:27 -0800 (PST)
To: "Charles E. Perkins" <charliep@iprg.nokia.com>
Cc: john.loughney@nokia.com, seamoby@diameter.org
Subject: [seamoby] Re: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt
In-Reply-To: <3A6F2351.12C2A241@iprg.nokia.com>
References: <01D91AFB08B6D211BFD00008C7EABAE10680A839@eseis04nok>
	<3A6F2351.12C2A241@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


One thing that I can see that may be headed for a
conflict here is that it seems that there is some
assumption in the micro-mobility design team that
mobile IP for the same IP address case might be
optional. There also seems (?) to be an assumption
that context transfer is only expected in the
change of CoA case -- the so called macro mobility
(ick ptui).

I've been working on an analysis of mobile IP,
fast handoffs, seamless mobility (context transfer
mainly) and their effect on RSVP reservations, and
in particular whether they'd benefit from context
transfer/fast handoff. I'm still working on this,
but I'll say preliminarily that the answer looks
like yes, and probably significantly. This is the
case with same address/different address (though
the details differ).

So, without trying to put a spin on which is right
or wrong, it seems likely that one of the
assumptions above may conflict with the other if
mobile IP provides the base mechanisms for context
transfer, especially if MIP is required from the
MN to initiate the transfer.

			Mike

Charles E. Perkins writes:
 > 
 > Hello John,
 > 
 > Thanks for the mention.  I'll just point out that this is
 > a highly preliminary document.  We are having a two-day
 > interim design team meeting next week.  That meeting will
 > almost surely result in significant revisions to the
 > handover document.  So, please don't shoot us if the
 > next document looks different!
 > 
 > I'll also mention that [seamoby-context] topics have come
 > up in our discussions multiple times, generally with two
 > major themes:
 > 
 > 1) We want our work to be useful to [seamoby-context]
 > 
 > 2) We do NOT want to crowd the [seamoby-context] design
 >    space, but insteady to offer something useful in the
 >    likely case that context transfer will coincide with
 >    Mobile IPv6-based handovers.  It would be bad to have
 >    two different protocols for that time-critical operation.
 > 
 > Themes from [seamoby-mm] have also been discussed at length.
 > We want to be compatible with whatever such protocols are
 > eventually standardized.
 > 
 > Regards,
 > Charlie P.
 > 


From owner-seamoby@diameter.org  Thu Jan 25 03:24:30 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22052
	for <seamoby-archive@odin.ietf.org>; Thu, 25 Jan 2001 03:24:29 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0P7b4f17004
	for seamoby-list; Wed, 24 Jan 2001 23:37:04 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from c007.snv.cp.net (c007-h008.c007.snv.cp.net [209.228.33.214])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f0P7aho16999
	for <seamoby@diameter.org>; Wed, 24 Jan 2001 23:36:47 -0800
Received: (cpmta 2365 invoked from network); 24 Jan 2001 20:08:10 -0800
Received: from dsl-64-193-0-129.telocity.com (HELO telocity.com) (64.193.0.129)
  by smtp.telocity.com (209.228.33.214) with SMTP; 24 Jan 2001 20:08:10 -0800
X-Sent: 25 Jan 2001 04:08:10 GMT
Message-ID: <3A6FA715.B856B7D0@telocity.com>
Date: Wed, 24 Jan 2001 22:09:57 -0600
From: Phil Neumiller <neumiller@telocity.com>
Organization: 3Com
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Andrew T. Campbell" <campbell@comet.columbia.edu>
CC: "'James Kempf'" <kempf@heliopolis.Eng.Sun.COM>, seamoby@diameter.org,
        Pat.Calhoun@eng.sun.com
Subject: [seamoby] Was Paging update.  Now the next mobile BOF name.
References: <006a01c08654$8334bbe0$3d443b80@SWEETPEA>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Andrew T. Campbell" wrote:
> 
> Like that Phil ;-)
> 
> Try this one for size:
> 
> http://www.comet.columbia.edu/~campbell/andrew/publications/papers/paging.pd
> f
> 
> Might give you indigestion...
> 

Not only indigestion but BURP's too.  Let's see with CRAPS and BURPS
we have covered only two bodily functions in BOFs.  Can somebody make
it a triple?  Please choose a different orifice.  Maybe ear goo?

 goo (g) 
 n. Informal 

        1.A sticky, wet, viscous substance. 
        2.Sentimental drivel. 


 [Perhaps short for burgoo.]


From owner-seamoby@diameter.org  Thu Jan 25 13:36:09 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05666
	for <seamoby-archive@odin.ietf.org>; Thu, 25 Jan 2001 13:36:07 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0PGrmR17826
	for seamoby-list; Thu, 25 Jan 2001 08:53:48 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0PGrko17821
	for <seamoby@diameter.org>; Thu, 25 Jan 2001 08:53:46 -0800
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id IAA29576;
	Thu, 25 Jan 2001 08:01:27 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAR00554;
	Thu, 25 Jan 2001 08:01:22 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA27347; Thu, 25 Jan 2001 08:01:22 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14960.19922.686515.133112@thomasm-u1.cisco.com>
Date: Thu, 25 Jan 2001 08:01:22 -0800 (PST)
To: Phil Neumiller <neumiller@telocity.com>
Cc: "Andrew T. Campbell" <campbell@comet.columbia.edu>,
        "'James Kempf'" <kempf@heliopolis.Eng.Sun.COM>, seamoby@diameter.org,
        Pat.Calhoun@eng.sun.com
Subject: [seamoby] Was Paging update.  Now the next mobile BOF name.
In-Reply-To: <3A6FA715.B856B7D0@telocity.com>
References: <006a01c08654$8334bbe0$3d443b80@SWEETPEA>
	<3A6FA715.B856B7D0@telocity.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Phil Neumiller writes:
 > "Andrew T. Campbell" wrote:
 > > 
 > > Like that Phil ;-)
 > > 
 > > Try this one for size:
 > > 
 > > http://www.comet.columbia.edu/~campbell/andrew/publications/papers/paging.pd
 > > f
 > > 
 > > Might give you indigestion...
 > > 
 > 
 > Not only indigestion but BURP's too.  Let's see with CRAPS and BURPS
 > we have covered only two bodily functions in BOFs.  Can somebody make
 > it a triple? 

   I dunno, is KINK a bodily function? :-)

	    Mike


From owner-seamoby@diameter.org  Thu Jan 25 14:48:20 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07346
	for <seamoby-archive@odin.ietf.org>; Thu, 25 Jan 2001 14:48:13 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0PI3am17922
	for seamoby-list; Thu, 25 Jan 2001 10:03:36 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0PI3Yo17917
	for <seamoby@diameter.org>; Thu, 25 Jan 2001 10:03:34 -0800
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f0PHA3127192;
	Thu, 25 Jan 2001 09:10:03 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104])
	by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f0PHBCA08603;
	Thu, 25 Jan 2001 09:11:12 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 882569DF.005E8F9F ; Thu, 25 Jan 2001 09:12:51 -0800
X-Lotus-FromDomain: 3COM
From: Phil_Neumiller@3Com.com
To: "Dana L. Blair" <dblair@cisco.com>
cc: charliep@iprg.nokia.com, pcalhoun@eng.sun.com, seamoby@diameter.org
Message-ID: <882569DF.005E8A96.00@hqoutbound.ops.3com.com>
Date: Thu, 25 Jan 2001 11:18:13 -0600
Subject: [seamoby] I also apologize...
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-seamoby@diameter.org
Precedence: bulk




My mouth has runneth over too.

Dana your flippancy has been orders of magnitude lower than mine.  I also
want to apologize to the list and to any other birds that I may have ruffled the
feathers of.   I take this stuff very seriously and my emotions sometimes run
high, and then I forget to take a  breather before hitting the send button.

Sincerely,

Phil Neumiller




From owner-seamoby@diameter.org  Thu Jan 25 18:09:10 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10785
	for <seamoby-archive@odin.ietf.org>; Thu, 25 Jan 2001 18:09:09 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0PMECi18194
	for seamoby-list; Thu, 25 Jan 2001 14:14:12 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0PME9o18189
	for <seamoby@diameter.org>; Thu, 25 Jan 2001 14:14:09 -0800
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0PLLsR12773
	for <seamoby@diameter.org>; Thu, 25 Jan 2001 15:21:54 -0600 (CST)
Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T5152f4779eac12f255115@davir02nok.americas.nokia.com>;
 Thu, 25 Jan 2001 15:21:44 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <ZRZX37YP>; Thu, 25 Jan 2001 15:21:43 -0600
Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213333@daeis07nok>
From: Basavaraj.Patil@nokia.com
To: gkenward@nortelnetworks.com, Phil_Neumiller@3Com.com, seamoby@diameter.org
Cc: urp@research.telcordia.com
Subject: RE: [seamoby] [MOBILE-IP] BURP BOF
Date: Thu, 25 Jan 2001 15:17:08 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C08714.2C8B8290"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C08714.2C8B8290
Content-Type: text/plain;
	charset="iso-8859-1"

 
Hi Gary,
 
I guess I need to clarify the statement in the charter for the proposed BOF.
"Mobile computing solutions based on protocols such as Mobile IP offer
seamless and continuous connectivity for users"........
I definitley did not mean to say that Mobile IP is THE only solution for
seamless
mobility. I should have mentioned the fact that there are other groups in
the IETF
also defining protocols for seamless mobility (SeaMoby). But the focus of
the
BOF is far removed from the mobility domain. The only reason for mentioning
Mobile IP in the proposed charter was to clarify the intent of the proposal.
 
So if I ruffled any feathers by failing to mention Seamoby as another WG
defining protocols for seamless mobility, I apologize. 
 
-Basavaraj
 

-----Original Message-----
From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Sunday, January 21, 2001 3:27 PM
To: 'Phil_Neumiller@3Com.com'; seamoby@diameter.org
Subject: RE: [seamoby] [MOBILE-IP] BURP BOF



Maybe someone should ask Raj Patil, seeing as he supported the 
creation of SeaMoby. Perhaps he simply lumped SeaMoby in with 
MIP for simplicities sake. 

gary 

> -----Original Message----- 
> From: Phil_Neumiller@3Com.com [ mailto:Phil_Neumiller@3Com.com
<mailto:Phil_Neumiller@3Com.com> ] 
> Sent: Friday, January 19, 2001 1:05 PM 
> To: seamoby@diameter.org 
> Subject: [seamoby] [MOBILE-IP] BURP BOF 
> 
> 
> 
> 
> According to the description of this new BOF, mobile IP 
> already provides 
> "seamless and continuous connectivity".  Hmm, what in the world 
> is SeaMoby for? 
> 
> Creating a standardized registration protocol for the  
> application layer 
> makes a lot of sense.  Perhaps some of the UPnP/SLP work can be 
> useful here. 
> 
> 
> ---------------------- Forwarded by Phil Neumiller/MW/US/3Com 
> on 01/19/2001 
> 11:48 AM --------------------------- 
> 
> Please respond to Basavaraj.Patil@nokia.com 
> 
> Sent by:  Basavaraj Patil <Basavaraj.Patil@nokia.com> 
> 
> 
> A BOF on Basic User Registration Protocol (BURP) 
> 
> 
> Charter: 
> 
> The vision of pervasive computing also includes constantly being 
> connected and the ability to access the Internet or the enterprise 
> over the Internet. Mobile computing solutions based on protocols such 
> as Mobile IP offer seamless and continuous connectivity for 
> users. However a lot of roadwarriors and other types 
> of users access the network from places like airports, hotels, malls 
> and sports complexes. These environments may offer access to the 
> network over wireless LANs or via Ethernet LAN ports or other 
> mediums. In such scenarios, 
> DHCP can provide configuration information  (e.g., giving a valid 
> address etc.), but there is no standard way for service providers to 
> obtain user information to perform AAA functions. For users 
> who do not have Mobile IP clients on their devices but would like to 
> access the network, they need to register and be authenticated by the 
> local network service provider before being authorized to use the 
> resources. The intent of this proposal is to develop an application 
> layer registration protocol that allows a user to register in the 
> local network by providing identity and authentication information 
> to the local network which then uses a AAA infrastructure to validate 
> the user, charge him and, authorize use of resources. 
> 
> We would like to request a BOF on a "Basic User Registration 
> Protocol (BURP)" for the March 2001 meeting of the IETF in 
> Minneapolis. 
> The objective of the BOF will be to 
> -- Detail the scope of the proposal and applicable scenarios 
> 
> -- Chart a course and an action plan (including milestones 
> and deliverables) for BURP. 
> 
> -- Investigate  the impact on existing  AAA  protocols  and  make it 
> flexible to support various authentication schemes. 
> 
> The goal will be to define a standard UNI for  environments in which 
> neither PPP nor Mobile IP is required but AAA interaction is 
> essential.  The basic principle will include: 
> 
>   -- The solution being a client-server application layer protocol 
> 
>   -- Is applicable to both IPv4 and IPv6. 
> 
>   -- User interacts only with a local Registration Agent (RA), which 
>   may reside on any node in the Network Domain. 
> 
>   -- It should work with any configuration  protocol, such as 
> DHCP, IPv6 
>   stateless autoconfiguration, and manual configuration. 
> 
>   -- Protects RA from replay attacks. 
> 
>   -- Provide information on and control of network usage. 
> 
>   -- Interacts with routers/policers to limit packets 
> forwarding based on a 
>   user's Service Level  Specification  (may be optional or may 
>   interwork with  standard policy protocols). 
> 
>   -- Defines an RA-to-AAA interface 
> 
> -------------------------------------------------------------- 
> --------- 
> 
> To subscribe to the mailing list for discussion on this topic, please 
> follow these instructions: 
> 
> To subscribe, send mail to urp-request@research.telcordia.com, and 
> use "subscribe" for the subject line. 
> 
> To unsubscribe, send mail to urp-request@research.telcordia.com, and 
> use "unsubscribe" for the subject line. 
> 
> To contribute to the list, send mail to urp@research.telcordia.com. 
> 
> For additional help, send mail to urp-request@research.telcordia.com 
> and use "help" for the subject line. 
> 
> 
> 
> 


------_=_NextPart_001_01C08714.2C8B8290
Content-Type: text/html;
	charset="iso-8859-1"

<!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] [MOBILE-IP] BURP BOF</TITLE>

<META content="MSHTML 5.50.4134.600" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV><SPAN class=848250921-25012001><FONT face=Arial color=#0000ff size=2>Hi 
Gary,</FONT></SPAN></DIV>
<DIV><SPAN class=848250921-25012001></SPAN>&nbsp;</DIV>
<DIV><SPAN class=848250921-25012001><FONT face=Arial color=#0000ff size=2>I 
guess I need to clarify the statement in the charter for the proposed 
BOF.</FONT></SPAN></DIV>
<DIV><SPAN class=848250921-25012001><FONT face=Arial color=#0000ff 
size=2>"Mobile computing solutions based on protocols such as Mobile IP 
offer</FONT></SPAN></DIV>
<DIV><SPAN class=848250921-25012001><FONT face=Arial color=#0000ff 
size=2>seamless and continuous connectivity for 
users"........</FONT></SPAN></DIV>
<DIV><SPAN class=848250921-25012001><FONT face=Arial color=#0000ff size=2>I 
definitley did not mean to say that Mobile IP is THE only solution for 
seamless</FONT></SPAN></DIV>
<DIV><SPAN class=848250921-25012001><FONT face=Arial color=#0000ff 
size=2>mobility. I should have mentioned the fact that there are other groups in 
the IETF</FONT></SPAN></DIV>
<DIV><SPAN class=848250921-25012001><FONT face=Arial color=#0000ff size=2>also 
defining protocols for seamless mobility (SeaMoby). But the focus of 
the</FONT></SPAN></DIV>
<DIV><SPAN class=848250921-25012001><FONT face=Arial color=#0000ff size=2>BOF is 
far removed from the mobility domain. The only reason for 
mentioning</FONT></SPAN></DIV>
<DIV><SPAN class=848250921-25012001><FONT face=Arial color=#0000ff size=2>Mobile 
IP in the proposed charter was to clarify the intent of the 
proposal.</FONT></SPAN></DIV>
<DIV><SPAN class=848250921-25012001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=848250921-25012001><FONT face=Arial color=#0000ff size=2>So if 
I ruffled any feathers by failing to mention Seamoby as another 
WG</FONT></SPAN></DIV>
<DIV><SPAN class=848250921-25012001><FONT face=Arial color=#0000ff 
size=2>defining protocols for seamless mobility, I apologize. 
</FONT></SPAN></DIV>
<DIV><SPAN class=848250921-25012001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=848250921-25012001><FONT face=Arial color=#0000ff 
size=2>-Basavaraj</FONT></SPAN></DIV>
<DIV><SPAN class=848250921-25012001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN><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> ext Gary Kenward 
  [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Sunday, January 21, 2001 
  3:27 PM<BR><B>To:</B> 'Phil_Neumiller@3Com.com'; 
  seamoby@diameter.org<BR><B>Subject:</B> RE: [seamoby] [MOBILE-IP] BURP 
  BOF<BR><BR></FONT></DIV>
  <P><FONT size=2>Maybe someone should ask Raj Patil, seeing as he supported 
  the</FONT> <BR><FONT size=2>creation of SeaMoby. Perhaps he simply lumped 
  SeaMoby in with </FONT><BR><FONT size=2>MIP for simplicities sake.</FONT> </P>
  <P><FONT size=2>gary</FONT> </P>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  From: Phil_Neumiller@3Com.com [<A 
  href="mailto:Phil_Neumiller@3Com.com">mailto:Phil_Neumiller@3Com.com</A>]</FONT> 
  <BR><FONT size=2>&gt; Sent: Friday, January 19, 2001 1:05 PM</FONT> <BR><FONT 
  size=2>&gt; To: seamoby@diameter.org</FONT> <BR><FONT size=2>&gt; Subject: 
  [seamoby] [MOBILE-IP] BURP BOF</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; According to the description of this new BOF, 
  mobile IP </FONT><BR><FONT size=2>&gt; already provides</FONT> <BR><FONT 
  size=2>&gt; "seamless and continuous connectivity".&nbsp; Hmm, what in the 
  world</FONT> <BR><FONT size=2>&gt; is SeaMoby for?</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; Creating a standardized registration 
  protocol for the&nbsp; </FONT><BR><FONT size=2>&gt; application layer</FONT> 
  <BR><FONT size=2>&gt; makes a lot of sense.&nbsp; Perhaps some of the UPnP/SLP 
  work can be</FONT> <BR><FONT size=2>&gt; useful here.</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  ---------------------- Forwarded by Phil Neumiller/MW/US/3Com </FONT><BR><FONT 
  size=2>&gt; on 01/19/2001</FONT> <BR><FONT size=2>&gt; 11:48 AM 
  ---------------------------</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; Please respond to Basavaraj.Patil@nokia.com</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; Sent by:&nbsp; Basavaraj Patil 
  &lt;Basavaraj.Patil@nokia.com&gt;</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; A BOF on Basic User 
  Registration Protocol (BURP)</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; Charter:</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; The vision of pervasive computing also includes 
  constantly being</FONT> <BR><FONT size=2>&gt; connected and the ability to 
  access the Internet or the enterprise</FONT> <BR><FONT size=2>&gt; over the 
  Internet. Mobile computing solutions based on protocols such</FONT> <BR><FONT 
  size=2>&gt; as Mobile IP offer seamless and continuous connectivity for</FONT> 
  <BR><FONT size=2>&gt; users. However a lot of roadwarriors and other 
  types</FONT> <BR><FONT size=2>&gt; of users access the network from places 
  like airports, hotels, malls</FONT> <BR><FONT size=2>&gt; and sports 
  complexes. These environments may offer access to the</FONT> <BR><FONT 
  size=2>&gt; network over wireless LANs or via Ethernet LAN ports or 
  other</FONT> <BR><FONT size=2>&gt; mediums. In such scenarios,</FONT> 
  <BR><FONT size=2>&gt; DHCP can provide configuration information&nbsp; (e.g., 
  giving a valid</FONT> <BR><FONT size=2>&gt; address etc.), but there is no 
  standard way for service providers to</FONT> <BR><FONT size=2>&gt; obtain user 
  information to perform AAA functions. For users</FONT> <BR><FONT size=2>&gt; 
  who do not have Mobile IP clients on their devices but would like to</FONT> 
  <BR><FONT size=2>&gt; access the network, they need to register and be 
  authenticated by the</FONT> <BR><FONT size=2>&gt; local network service 
  provider before being authorized to use the</FONT> <BR><FONT size=2>&gt; 
  resources. The intent of this proposal is to develop an application</FONT> 
  <BR><FONT size=2>&gt; layer registration protocol that allows a user to 
  register in the</FONT> <BR><FONT size=2>&gt; local network by providing 
  identity and authentication information</FONT> <BR><FONT size=2>&gt; to the 
  local network which then uses a AAA infrastructure to validate</FONT> 
  <BR><FONT size=2>&gt; the user, charge him and, authorize use of 
  resources.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; We would 
  like to request a BOF on a "Basic User Registration</FONT> <BR><FONT 
  size=2>&gt; Protocol (BURP)" for the March 2001 meeting of the IETF in 
  </FONT><BR><FONT size=2>&gt; Minneapolis.</FONT> <BR><FONT size=2>&gt; The 
  objective of the BOF will be to</FONT> <BR><FONT size=2>&gt; -- Detail the 
  scope of the proposal and applicable scenarios</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; -- Chart a course and an action plan (including 
  milestones</FONT> <BR><FONT size=2>&gt; and deliverables) for BURP.</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; -- Investigate&nbsp; the 
  impact on existing&nbsp; AAA&nbsp; protocols&nbsp; and&nbsp; make it</FONT> 
  <BR><FONT size=2>&gt; flexible to support various authentication 
  schemes.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; The goal 
  will be to define a standard UNI for&nbsp; environments in which</FONT> 
  <BR><FONT size=2>&gt; neither PPP nor Mobile IP is required but AAA 
  interaction is</FONT> <BR><FONT size=2>&gt; essential.&nbsp; The basic 
  principle will include:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt;&nbsp;&nbsp; -- The solution being a client-server application 
  layer protocol</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt;&nbsp;&nbsp; -- Is applicable to both IPv4 and IPv6.</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp;&nbsp; -- User 
  interacts only with a local Registration Agent (RA), which</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp; may reside on any node in the Network Domain.</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp;&nbsp; -- It should 
  work with any configuration&nbsp; protocol, such as </FONT><BR><FONT 
  size=2>&gt; DHCP, IPv6</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp; stateless 
  autoconfiguration, and manual configuration.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt;&nbsp;&nbsp; -- Protects RA from replay 
  attacks.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp;&nbsp; 
  -- Provide information on and control of network usage.</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp;&nbsp; -- Interacts with 
  routers/policers to limit packets </FONT><BR><FONT size=2>&gt; forwarding 
  based on a</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp; user's Service Level&nbsp; 
  Specification&nbsp; (may be optional or may</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp; interwork with&nbsp; standard policy 
  protocols).</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt;&nbsp;&nbsp; -- Defines an RA-to-AAA interface</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  --------------------------------------------------------------</FONT> 
  <BR><FONT size=2>&gt; ---------</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; To subscribe to the mailing list for discussion on this topic, 
  please</FONT> <BR><FONT size=2>&gt; follow these instructions:</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; To subscribe, send mail to 
  urp-request@research.telcordia.com, and</FONT> <BR><FONT size=2>&gt; use 
  "subscribe" for the subject line.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; To unsubscribe, send mail to 
  urp-request@research.telcordia.com, and</FONT> <BR><FONT size=2>&gt; use 
  "unsubscribe" for the subject line.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; To contribute to the list, send mail to 
  urp@research.telcordia.com.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; For additional help, send mail to 
  urp-request@research.telcordia.com</FONT> <BR><FONT size=2>&gt; and use "help" 
  for the subject line.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C08714.2C8B8290--


From owner-seamoby@diameter.org  Thu Jan 25 18:50:29 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11781
	for <seamoby-archive@odin.ietf.org>; Thu, 25 Jan 2001 18:50:29 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0PMNm018207
	for seamoby-list; Thu, 25 Jan 2001 14:23:48 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0PMNjo18202
	for <seamoby@diameter.org>; Thu, 25 Jan 2001 14:23:45 -0800
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0PLVWR13845
	for <seamoby@diameter.org>; Thu, 25 Jan 2001 15:31:32 -0600 (CST)
Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T5152fd3991ac12f2570b1@davir04nok.americas.nokia.com>;
 Thu, 25 Jan 2001 15:31:18 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <ZRZX3765>; Thu, 25 Jan 2001 15:31:17 -0600
Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213334@daeis07nok>
From: Basavaraj.Patil@nokia.com
To: mat@cisco.com, Pat.Calhoun@eng.sun.com
Cc: Phil_Neumiller@3Com.com, seamoby@diameter.org, urp@research.telcordia.com
Subject: RE: [seamoby] Was BURP BOF, now a dark revelation...
Date: Thu, 25 Jan 2001 15:26:43 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk


Mike,

I am just surprised that this BOF (BURP) proposal has generated
more interest/criticism in the seamoby WG than in the list that
was created to discuss it.

The BOF proposes to develop a protocol that has absolutely nothing to
do with mobility. The only reason for mentioning Mobile IP and a  mobile
IP client was to differentiate the problem space. There was no intent
of any preferential status to MIP. For whatever reason, it seems to be
have been construed as such. 

And please do remember, that the proposal is only a first cut at the
problem space. It will undergo revisions and modifications. 

-Basavaraj

> 
>    The charter of the BOF specifically states that when MIP
>    is present, it should be used as the access mechanism. The
>    same can be said of all of the above too, so I wonder why
>    there is a reason why MIP was effectively given a preferential
>    status in the charter over other methods of filling the PPP/CHAP
>    vacuum, especially when it's not in MIP's charter  -- as far as
>    I know -- to be a network access mechanism. That and it is 
> seemingly
>    at odds with the way that v6 MIP works (which doesn't have a
>    FA at all). 
> 
>    Either the BOF should say that it wants to make MIP into the
>    new access protocol, or it should remove any preferential
>    status to MIP so that we can go back to first principles.
>    The mix as stated is either setting itself up for a conflict,
>    or is presupposing the outcome, both of which seem like a bad
>    idea.
> 
> 			Mike
> 


From owner-seamoby@diameter.org  Fri Jan 26 08:51:49 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07186
	for <seamoby-archive@odin.ietf.org>; Fri, 26 Jan 2001 08:51:49 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0QCcuY20394
	for seamoby-list; Fri, 26 Jan 2001 04:38:56 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0QCbpo20389
	for <seamoby@diameter.org>; Fri, 26 Jan 2001 04:37:52 -0800
Received: from glandon.inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id MAA07129
	for <seamoby@diameter.org>; Fri, 26 Jan 2001 12:45:35 +0100 (MET)
Received: from inrialpes.fr (localhost [127.0.0.1])
	by glandon.inrialpes.fr (8.8.7/8.8.5) with ESMTP id MAA23338
	for <seamoby@diameter.org>; Fri, 26 Jan 2001 12:45:34 +0100 (MET)
Message-ID: <3A71635E.AE2093F0@inrialpes.fr>
Date: Fri, 26 Jan 2001 12:45:34 +0100
From: Claude Castelluccia <claude.castelluccia@inrialpes.fr>
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: seamoby@diameter.org
Subject: [seamoby] -IPCN01-
Content-Type: multipart/alternative;
 boundary="------------2481B9D0BAC37A77D2F81559"
Sender: owner-seamoby@diameter.org
Precedence: bulk


--------------2481B9D0BAC37A77D2F81559
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Dear all,

IPCN01  (http://www.upperside.fr/baipcn2001.htm) submission deadline is
approaching.
IPCN01 is a great opportunities to have technical
discussions/presentations about  Seamboby topics:
paging, micro-mobility, context tranfert...

I would therefore suggest you to submit a short abstract to this
conference...

IPCN01 will be held in Paris, France end of May....This is a
great time to visit la tour eiffel, notre dame, le louvre, champs
elysee,
moulin rouge, montmartre,  versailles, pigalle,....
don't miss it ;-)

regards,

Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------2481B9D0BAC37A77D2F81559
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>Dear all,
<p>IPCN01&nbsp; (<A HREF="http://www.upperside.fr/baipcn2001.htm">http://www.upperside.fr/baipcn2001.htm</A>)&nbsp;submission
deadline is approaching.
<br>IPCN01 is a great opportunities to have technical
<br>discussions/presentations about &nbsp;Seamboby topics:
<br>paging, micro-mobility, context tranfert...
<p>I&nbsp;would therefore suggest you to submit a short abstract to this
<br>conference...
<p>IPCN01 will be held in Paris, France end of May....This is a
<br>great time to visit la tour eiffel, notre dame, le louvre, champs elysee,
<br>moulin rouge, montmartre,&nbsp; versailles, pigalle,....
<br>don't miss it ;-)
<p>regards,
<p>Claude.
<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------2481B9D0BAC37A77D2F81559--



From owner-seamoby@diameter.org  Fri Jan 26 12:46:17 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16111
	for <seamoby-archive@odin.ietf.org>; Fri, 26 Jan 2001 12:46:16 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0QGjio21057
	for seamoby-list; Fri, 26 Jan 2001 08:45:44 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0QGjgo21052
	for <seamoby@diameter.org>; Fri, 26 Jan 2001 08:45:42 -0800
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Fri, 26 Jan 2001 10:45:23 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <D33P1J59>; Fri, 26 Jan 2001 10:45:25 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8BAB@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'seamoby'" <seamoby@diameter.org>
Subject: [seamoby] Seamoby context transfer email list server
Date: Fri, 26 Jan 2001 10:45:20 -0500
Sensitivity: Company-Confidential
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: text/plain; charset="ISO-8859-1"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hello everyone.

It is probably apparent to those on the context transfer design team that
the list server has not been working.
There has been a problem with network access, and even though the server is
up and running, no one, including
myself, can get access to it through the internet.

This situation will be resolved today. I am hoping to move the list to
another server, one not on the current network.

I apologize for all the grief this has caused. It is an unexpected and
unfortunate situation.

Regards,
Gary Kenward




From owner-seamoby@diameter.org  Fri Jan 26 15:06:20 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20160
	for <seamoby-archive@odin.ietf.org>; Fri, 26 Jan 2001 15:06:00 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0QHn0w21188
	for seamoby-list; Fri, 26 Jan 2001 09:49:00 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from homerun.comdev.cc (adsl-63-194-99-36.dsl.snlo01.pacbell.net [63.194.99.36])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f0QHmto21181
	for <seamoby@diameter.org>; Fri, 26 Jan 2001 09:48:55 -0800
Received: (qmail 11889 invoked from network); 26 Jan 2001 16:56:36 -0000
Received: from soldout.comdev.cc (HELO soldout) (192.168.67.89)
  by homerun.comdev.cc with SMTP; 26 Jan 2001 16:56:36 -0000
From: "Mat Horan" <Mat.Horan@comdev.cc>
To: <seamoby@diameter.org>
Subject: [seamoby] Context example/ requirement for L2 PPP+
Date: Fri, 26 Jan 2001 08:58:32 -0800
Message-ID: <007101c087b9$374e9410$5943a8c0@soldout>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0072_01C08776.292B5410"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <3A71635E.AE2093F0@inrialpes.fr>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0072_01C08776.292B5410
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0073_01C08776.292B5410"


------=_NextPart_001_0073_01C08776.292B5410
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

In our view of L2 context requirements I'd like to submit the following
items for consideration.  We understand this could broach on the edge of
solution space and definitely in the requirements space, but would like to
put this out there in the interest of defining what some L2 context needs to
consist of.  Since we are attempting to more thoroughly define some of the
context types (Sect. 3.2) we wanted to discuss this one.  Comments?



Mat Horan, Network Engineer
COM DEV Wireless Group
805.544.1089 x2244 (v), 805.544.2055 (f)
http://www.comdev.cc



------=_NextPart_001_0073_01C08776.292B5410
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C08776.28619B70">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p
	{margin-right:0in;
	mso-margin-top-alt:auto;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	tab-stops:45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt =
412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732.8pt;
	font-size:10.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:"Courier New";}
span.EmailStyle19
	{mso-style-type:personal-reply;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>In=
 our
view of L2 context requirements I&#8217;d like to submit the following =
items for
consideration.<span style=3D"mso-spacerun: yes">&nbsp; </span>We =
understand this
could broach on the edge of solution space and definitely in the =
requirements
space, but would like to put this out there in the interest of defining =
what
some L2 context needs to consist of.<span style=3D"mso-spacerun: =
yes">&nbsp;
</span>Since we are attempting to more thoroughly define some of the =
context
types (Sect. 3.2) we wanted to discuss this one.<span =
style=3D"mso-spacerun:
yes">&nbsp; </span>Comments?<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><!=
[if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><!=
[if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle19><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><!=
[if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoAutoSig><!--[if supportFields]><span =
class=3DEmailStyle19><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-begin'></span><span=20
style=3D"mso-spacerun: yes">&nbsp;</span>AUTOTEXTLIST \s &quot;E-mail=20
Signature&quot; <span =
style=3D'mso-element:field-separator'></span></span></font></span><![endi=
f]--><font
color=3Dnavy><span style=3D'color:navy'>Mat Horan, Network =
Engineer</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font></=
p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>COM DEV Wireless =
Group</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font></=
p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>805.544.1089 x2244 (v), =
805.544.2055 (f)</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font></=
p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>http://www.comdev.cc</span></font><=
font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font></=
p>

<p class=3DMsoNormal><!--[if supportFields]><span =
class=3DEmailStyle19><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-end'></span></span></font></span><![endif]--><=
span
class=3DEmailStyle19><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

</div>

</body>

</html>

------=_NextPart_001_0073_01C08776.292B5410--

------=_NextPart_000_0072_01C08776.292B5410
Content-Type: text/plain;
	name="handoff-data.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="handoff-data.txt"
Content-Transfer-Encoding: 7bit


RFC 1661

PPP
{
   BYTE state;
   LONG magicNumber;
   BOOL interfaceActive;

   FiniteStateMachine
   {
      BYTE maxTerminateCounter;
      BYTE maxConfigureCounter;
      BYTE maxFailureCounter;
   
      LONG timeoutValue;
   }
}

LCP
{
   LOCAL_SIDE
   {
      FiniteStateMachine
      {
         TIMER
         {
            LONG ticks;
            BYTE restartCount;
            BOOL running;
         }
   
         BYTE state;
      }
   
      BOOL nakRequired;
      BOOL rejRequired;
   
      MaximumReceiveUnit
      {
         BOOL include;
         BOOL rejected;
         BOOL sequence;
         BOOL action;

         LONG mru;
      }

      AuthenticationProtocol
      {
         BOOL include;
         BOOL rejected;
         BOOL sequence;
         BOOL action;

         SHORT protocol;
         BYTE algorithm;
      }

      MagicNumber
      {
         BOOL include;
         BOOL rejected;
         BOOL sequence;
         BOOL action;

         LONG mn;
      }

      ProtocolFieldCompression
      {
         BOOL include;
         BOOL rejected;
         BOOL sequence;
         BOOL action;
      }
   
      AddressAndControlFieldCompression
      {
         BOOL include;
         BOOL rejected;
         BOOL sequence;
         BOOL action;
      }

      SHORT sequenceNumber;
      BYTE sequenceIdentifier;
      BYTE currentIdentifier;
   
      BOOL isActive;
   }

   REMOTE_SIDE
   {
      MaximunmReceiveUnit
      {
         BOOL include;
         BOOL rejected;
         BOOL sequence;
         BOOL action;

         LONG mru;
      }

      AuthenticationProtocol
      {
         BOOL include;
         BOOL rejected;
         BOOL sequence;
         BOOL action;

         SHORT protocol;
         BYTE algorithm;
      }

      MagicNumber
      {
         BOOL include;
         BOOL rejected;
         BOOL sequence;
         BOOL action;

         LONG mn;
      }

      ProtocolFieldCompression
      {
         BOOL include;
         BOOL rejected;
         BOOL sequence;
         BOOL action;
      }
   
      AddressAndControlFieldCompression
      {
         BOOL include;
         BOOL rejected;
         BOOL sequence;
         BOOL action;
      }

      SHORT sequenceNumber;
      BYTE sequenceIdentifier;
      BYTE currentIdentifier;
   
      BOOL isActive;
   }
}

RFC 1332

IPCP
{
   FiniteStateMachine
   {
      TIMER
      {
         ULONG ticks;
         BYTE restartCount;
         BOOL running;
      }

      BYTE state;
   }

   BOOL nakRequired;
   BOOL rejRequired;

   LOCAL_SIDE
   {
      IPCompressionProtocol
      {
         BOOL include;
         BOOL rejected;
         BOOL sequence;
         BOOL action;

         SHORT protocol;
         BYTE maxSlotId;
         BYTE compSlotId;
      }

      IPAddress
      {
         BOOL include;
         BOOL rejected;
         BOOL sequence;
         BOOL action;

         LONG ipAddress;
      }

      PrimaryDNSAddress
      {
         BOOL include;
         BOOL rejected;
         BOOL sequence;
         BOOL action;

         LONG ipAddress;
      }

      SecondaryDNSAddress
      {
         BOOL include;
         BOOL rejected;
         BOOL sequence;
         BOOL action;

         LONG ipAddress;
      }

      BYTE currentIdentifier;
      BOOL isActive;
   }

   REMOTE_SIDE
   {
      IPCompressionProtocol
      {
         BOOL include;
         BOOL rejected;
         BOOL sequence;
         BOOL action;

         SHORT protocol;
         BYTE maxSlotId;
         BYTE compSlotId;
      }

      IPAddress
      {
         BOOL include;
         BOOL rejected;
         BOOL sequence;
         BOOL action;

         LONG ipAddress;
      }

      BYTE currentIdentifier;
      BOOL isActive;
   }
}

RFC 1994

CHAP
{
   TIMER
   {
      BYTE restartCount;
      BOOL running;
   }

   BYTE state;
   BYTE currentIdentifier;

   STRING userName;
   BYTE userNameLength;

   STRING challenge;
   BYTE challengeLength;

   STRING response;
   BYTE responseLength;

   BYTE maxChallengeCounter;
   BYTE maxResponseCounter;
   LONG timeoutValue;
}



@

------=_NextPart_000_0072_01C08776.292B5410--



From owner-seamoby@diameter.org  Fri Jan 26 15:16:53 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20320
	for <seamoby-archive@odin.ietf.org>; Fri, 26 Jan 2001 15:16:52 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0QIlGJ21345
	for seamoby-list; Fri, 26 Jan 2001 10:47:16 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0QIlDo21340
	for <seamoby@diameter.org>; Fri, 26 Jan 2001 10:47:13 -0800
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f0QHrj108369;
	Fri, 26 Jan 2001 09:53:46 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104])
	by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f0QHstA18949;
	Fri, 26 Jan 2001 09:54:55 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 882569E0.00629000 ; Fri, 26 Jan 2001 09:56:33 -0800
X-Lotus-FromDomain: 3COM
From: Phil_Neumiller@3Com.com
To: "Gary Kenward" <gkenward@nortelnetworks.com>
cc: seamoby@diameter.org
Message-ID: <882569E0.00628CFC.00@hqoutbound.ops.3com.com>
Date: Fri, 26 Jan 2001 12:01:09 -0600
Subject: [seamoby] Concise Context Transfer Problem Statement
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=71xIET9pZglgMsMt3NvsMxlnhg6WOXW0YqcoWyfrrg5vhvSC5lt4fPFo"
Content-Disposition: inline
Sender: owner-seamoby@diameter.org
Precedence: bulk

--0__=71xIET9pZglgMsMt3NvsMxlnhg6WOXW0YqcoWyfrrg5vhvSC5lt4fPFo
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Gary,

Here is my best shot a "concise" problem statement.  Please hack on it.

Service discovery may indeed overlap with context transfer in many ways.
To avoid future problems we should cooperate with the service discovery
SDOs like UPnP, SLP (IETF WG), and Jini/Java folks.  I believe there
 is also interest in the OSGi SDO.

All these competing SDOs (we currently have "discovery Babylon", kind of like
wireless hey?) recognize a need for context transfer and context discovery.
I think the discovery portion of this problem can be mentioned in the draft but
should be stated to be out of scope.

CONCISE PROBLEM STATEMENT
--------------------------------------------
Mobile and portable devices will encounter each other and different access
networks as they move.  To allow seamless service mobility, these devices
need to negotiate transport paths for their anchored services as they move.
In addition to services, the mobile nodes have trust relationships, AAA
requirements, link compression  transport requirements and QoS
Requirements.  A protocol capable of transporting the state of the  mobile's
current service transport states is needed.   This same protocol will also be
used for transferring and negotiation of state during handovers between edge
mobility access equipment.  This protocol MUST also have the ability to
negotiate these parameters so that maximal connectivity is acheivable.

The SeaMoby context transfer working area is responsible for creating
a robust context transfer and negotiation protocol to facility seamless service
mobility.  This protocol may also prove useful for use in UPnP, SLP, and other
discovery related work in other SDOs.

Thanks,

Phil







Sent by:  "Gary Kenward" <gkenward@nortelnetworks.com>


To:   "'john.loughney @nokia.com'" <john.loughney@nokia.com>,
      imaginitall@excite.com, seamoby_context@standards.nortelnetworks.com,
      "Hongyi Li" <hyli@nortelnetworks.com>, seamoby-mm@cdma-2000.org
cc:    (Phil Neumiller/MW/US/3Com)
Subject:  RE: [seamoby-mm] Negotiation & plug 'n play



John:

  We are in agreement. It would seem that knowing the capability
of the neighbouring ARs would be useful to context transfer,
however, as we haven't had much discussion around the context
transfer solution, it is unclear as how it would be used, nor how
useful it would be.

  Capability discovery is a new capability, and different from
context negotiation. It is not clear to me that you need capability
discovery if you have context negotiation (or even if you need
context negotiation if you have capability discovery).

  The only question at this point is whether we need to include both
of these approaches in the problem statement, or if there is a high
level description of the problem that covers both approaches?
I believe there is, and it concerns the difficult of sustaining the
communications service to a mobile node when the context includes
the support for N microflows, each requiring different network
resources.

Gary

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Friday, January 26, 2001 2:45 AM
> To: imaginitall@excite.com;
> seamoby_context@standards.nortelnetworks.com; Li, Hongyi
> [WDLN2:AN22:EXCH]; seamoby-mm@cdma-2000.org
> Subject: [seamoby-mm] Negotiation & plug 'n play
>
>
> Hi Gary,
>
> > The need for negotiation is not so much an issue concerning
> > capabilities (at the very least, capabitilies are static and
> > IMHO, should be provisioned), as it is a requirement for proper
> > resource management. An AR may have the
> > capabitility to support set of microflows and the requisite
> > context, but it may not have the resources to support each
> > and every microflow.
>
> I'm (context) transfering from the MM design team, to the CT
> design team.
>
> Hongyi has stated a requirement:
>
>   Mobile location aware nodes (MLAN) in an edge mobility
> domain should be
> able
>   to learn of their neighbors (and their neighbors
> capability). The access
> points,
>   routers, and mobile agents (e.g., foreign agent) could be
> potential MLAN
> in an
>   edge mobility domain.
>
> This is more CT than MM, in my opinion.  This is something additional
> to CT, however.  Should we consider this?  Henrik has given a
> micromobility
> example, where such plug and play functionality would be useful.
>
> In my opinion, I think that there will less network planning with
> WLAN & Bluetooth than there is with cellular networks, so I think
> that we may want to have this functionality.
>
> best regards,
> John
>


--0__=71xIET9pZglgMsMt3NvsMxlnhg6WOXW0YqcoWyfrrg5vhvSC5lt4fPFo
Content-type: text/html; 
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PUlTTy04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U
PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1Mi4zNSI+DQo8VElUTEU+UkU6IFtz
ZWFtb2J5LW1tXSBOZWdvdGlhdGlvbiAmYW1wOyBwbHVnICduIHBsYXk8L1RJVExFPg0KPC9IRUFE
Pg0KPEJPRFk+DQoNCjxQPjxGT05UIFNJWkU9Mj5Kb2huOjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZP
TlQgU0laRT0yPiZuYnNwOyBXZSBhcmUgaW4gYWdyZWVtZW50LiBJdCB3b3VsZCBzZWVtIHRoYXQg
a25vd2luZyB0aGUgY2FwYWJpbGl0eTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+b2YgdGhlIG5l
aWdoYm91cmluZyBBUnMgd291bGQgYmUgdXNlZnVsIHRvIGNvbnRleHQgdHJhbnNmZXIsIDwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTI+aG93ZXZlciwgYXMgd2UgaGF2ZW4ndCBoYWQgbXVjaCBkaXNj
dXNzaW9uIGFyb3VuZCB0aGUgY29udGV4dDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dHJhbnNm
ZXIgc29sdXRpb24sIGl0IGlzIHVuY2xlYXIgYXMgaG93IGl0IHdvdWxkIGJlIHVzZWQsIG5vciBo
b3c8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnVzZWZ1bCBpdCB3b3VsZCBiZS4gPC9GT05UPg0K
PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Jm5ic3A7IENhcGFiaWxpdHkgZGlzY292ZXJ5IGlzIGEg
bmV3IGNhcGFiaWxpdHksIGFuZCBkaWZmZXJlbnQgZnJvbSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yPmNvbnRleHQgbmVnb3RpYXRpb24uIEl0IGlzIG5vdCBjbGVhciB0byBtZSB0aGF0IHlvdSBu
ZWVkIGNhcGFiaWxpdHk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmRpc2NvdmVyeSBpZiB5b3Ug
aGF2ZSBjb250ZXh0IG5lZ290aWF0aW9uIChvciBldmVuIGlmIHlvdSBuZWVkIDwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTI+Y29udGV4dCBuZWdvdGlhdGlvbiBpZiB5b3UgaGF2ZSBjYXBhYmlsaXR5
IGRpc2NvdmVyeSkuIDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPiZuYnNwOyBUaGUg
b25seSBxdWVzdGlvbiBhdCB0aGlzIHBvaW50IGlzIHdoZXRoZXIgd2UgbmVlZCB0byBpbmNsdWRl
IGJvdGg8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPm9mIHRoZXNlIGFwcHJvYWNoZXMgaW4gdGhl
IHByb2JsZW0gc3RhdGVtZW50LCBvciBpZiB0aGVyZSBpcyBhIGhpZ2g8L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yPmxldmVsIGRlc2NyaXB0aW9uIG9mIHRoZSBwcm9ibGVtIHRoYXQgY292ZXJzIGJv
dGggYXBwcm9hY2hlcz88L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkkgYmVsaWV2ZSB0aGVyZSBp
cywgYW5kIGl0IGNvbmNlcm5zIHRoZSBkaWZmaWN1bHQgb2Ygc3VzdGFpbmluZyB0aGU8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPmNvbW11bmljYXRpb25zIHNlcnZpY2UgdG8gYSBtb2JpbGUgbm9k
ZSB3aGVuIHRoZSBjb250ZXh0IGluY2x1ZGVzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj50aGUg
c3VwcG9ydCBmb3IgTiBtaWNyb2Zsb3dzLCBlYWNoIHJlcXVpcmluZyBkaWZmZXJlbnQgbmV0d29y
ayA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnJlc291cmNlcy48L0ZPTlQ+DQo8L1A+DQoNCjxQ
PjxGT05UIFNJWkU9Mj5HYXJ5PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Jmd0OyAt
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBG
cm9tOiBqb2huLmxvdWdobmV5QG5va2lhLmNvbSBbPEEgSFJFRj0ibWFpbHRvOmpvaG4ubG91Z2hu
ZXlAbm9raWEuY29tIj5tYWlsdG86am9obi5sb3VnaG5leUBub2tpYS5jb208L0E+XTwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBTZW50OiBGcmlkYXksIEphbnVhcnkgMjYsIDIwMDEgMjo0
NSBBTTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBUbzogaW1hZ2luaXRhbGxAZXhjaXRl
LmNvbTs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgc2VhbW9ieV9jb250ZXh0QHN0YW5k
YXJkcy5ub3J0ZWxuZXR3b3Jrcy5jb207IExpLCBIb25neWk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yPiZndDsgW1dETE4yOkFOMjI6RVhDSF07IHNlYW1vYnktbW1AY2RtYS0yMDAwLm9yZzwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBTdWJqZWN0OiBbc2VhbW9ieS1tbV0gTmVnb3RpYXRp
b24gJmFtcDsgcGx1ZyAnbiBwbGF5PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg
SGkgR2FyeSw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IFRoZSBuZWVk
IGZvciBuZWdvdGlhdGlvbiBpcyBub3Qgc28gbXVjaCBhbiBpc3N1ZSBjb25jZXJuaW5nIDwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IGNhcGFiaWxpdGllcyAoYXQgdGhlIHZlcnkg
bGVhc3QsIGNhcGFiaXRpbGllcyBhcmUgc3RhdGljIGFuZCA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yPiZndDsgJmd0OyBJTUhPLCBzaG91bGQgYmUgcHJvdmlzaW9uZWQpLCBhcyBpdCBpcyBhIHJl
cXVpcmVtZW50IGZvciBwcm9wZXIgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsg
cmVzb3VyY2UgbWFuYWdlbWVudC4gQW4gQVIgbWF5IGhhdmUgdGhlPC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9Mj4mZ3Q7ICZndDsgY2FwYWJpdGlsaXR5IHRvIHN1cHBvcnQgc2V0IG9mIG1pY3JvZmxv
d3MgYW5kIHRoZSByZXF1aXNpdGUgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsg
Y29udGV4dCwgYnV0IGl0IG1heSBub3QgaGF2ZSB0aGUgcmVzb3VyY2VzIHRvIHN1cHBvcnQgZWFj
aCA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBhbmQgZXZlcnkgbWljcm9mbG93
LjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
PiZndDsgSSdtIChjb250ZXh0KSB0cmFuc2ZlcmluZyBmcm9tIHRoZSBNTSBkZXNpZ24gdGVhbSwg
dG8gdGhlIENUIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBkZXNpZ24gdGVhbS4gPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0
OyBIb25neWkgaGFzIHN0YXRlZCBhIHJlcXVpcmVtZW50OjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsmbmJzcDsgTW9iaWxl
IGxvY2F0aW9uIGF3YXJlIG5vZGVzIChNTEFOKSBpbiBhbiBlZGdlIG1vYmlsaXR5IDwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBkb21haW4gc2hvdWxkIGJlPC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9Mj4mZ3Q7IGFibGUgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7Jm5i
c3A7IHRvIGxlYXJuIG9mIHRoZWlyIG5laWdoYm9ycyAoYW5kIHRoZWlyIG5laWdoYm9ycyA8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgY2FwYWJpbGl0eSkuIFRoZSBhY2Nlc3M8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgcG9pbnRzLCA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
PiZndDsmbmJzcDsmbmJzcDsgcm91dGVycywgYW5kIG1vYmlsZSBhZ2VudHMgKGUuZy4sIGZvcmVp
Z24gYWdlbnQpIGNvdWxkIGJlIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBwb3RlbnRp
YWwgTUxBTjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBpbiBhbiA8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yPiZndDsmbmJzcDsmbmJzcDsgZWRnZSBtb2JpbGl0eSBkb21haW4uIDwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg
VGhpcyBpcyBtb3JlIENUIHRoYW4gTU0sIGluIG15IG9waW5pb24uJm5ic3A7IFRoaXMgaXMgc29t
ZXRoaW5nIGFkZGl0aW9uYWw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgdG8gQ1QsIGhv
d2V2ZXIuJm5ic3A7IFNob3VsZCB3ZSBjb25zaWRlciB0aGlzPyZuYnNwOyBIZW5yaWsgaGFzIGdp
dmVuIGEgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IG1pY3JvbW9iaWxpdHk8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgZXhhbXBsZSwgd2hlcmUgc3VjaCBwbHVnIGFuZCBwbGF5
IGZ1bmN0aW9uYWxpdHkgd291bGQgYmUgdXNlZnVsLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+
Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgSW4gbXkgb3BpbmlvbiwgSSB0aGlu
ayB0aGF0IHRoZXJlIHdpbGwgbGVzcyBuZXR3b3JrIHBsYW5uaW5nIHdpdGggPC9GT05UPg0KPEJS
PjxGT05UIFNJWkU9Mj4mZ3Q7IFdMQU4gJmFtcDsgQmx1ZXRvb3RoIHRoYW4gdGhlcmUgaXMgd2l0
aCBjZWxsdWxhciBuZXR3b3Jrcywgc28gSSB0aGluazwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+
Jmd0OyB0aGF0IHdlIG1heSB3YW50IHRvIGhhdmUgdGhpcyBmdW5jdGlvbmFsaXR5LjwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgYmVz
dCByZWdhcmRzLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBKb2huPC9GT05UPg0KPEJS
PjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg0K

--0__=71xIET9pZglgMsMt3NvsMxlnhg6WOXW0YqcoWyfrrg5vhvSC5lt4fPFo--



From owner-seamoby@diameter.org  Fri Jan 26 16:06:34 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21830
	for <seamoby-archive@odin.ietf.org>; Fri, 26 Jan 2001 16:06:22 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0QJR4i21440
	for seamoby-list; Fri, 26 Jan 2001 11:27:04 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0QJQoo21434
	for <seamoby@diameter.org>; Fri, 26 Jan 2001 11:26:53 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 26 Jan 2001 13:30:54 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <D33P1P4N>; Fri, 26 Jan 2001 13:30:57 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8BB5@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Mat Horan'" <Mat.Horan@comdev.cc>, seamoby <seamoby@diameter.org>
Subject: RE: [seamoby] Context example/ requirement for L2 PPP+
Date: Fri, 26 Jan 2001 13:30:50 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C087C6.1BDEBB30"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C087C6.1BDEBB30
Content-Type: text/plain;
	charset="ISO-8859-1"

Look fine with me. Perhaps we could include this kind of information
as an appendix to the draft.
 
My only comment is that I wouldn't call this "L2 state", I would call it
sub-network convergence layer state, or L3- state.
 
Semantics, I know, but important semantics. We already have a layer 2,
and it's outside of our charter.
 
Gary
-----Original Message-----
From: Mat Horan [mailto:Mat.Horan@comdev.cc]
Sent: Friday, January 26, 2001 11:59 AM
To: seamoby
Subject: [seamoby] Context example/ requirement for L2 PPP+


In our view of L2 context requirements I'd like to submit the following
items for consideration.  We understand this could broach on the edge of
solution space and definitely in the requirements space, but would like to
put this out there in the interest of defining what some L2 context needs to
consist of.  Since we are attempting to more thoroughly define some of the
context types (Sect. 3.2) we wanted to discuss this one.  Comments?
 
 
 
Mat Horan, Network Engineer
COM DEV Wireless Group
805.544.1089 x2244 (v), 805.544.2055 (f)
http://www.comdev.cc
 
 

------_=_NextPart_001_01C087C6.1BDEBB30
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:w = 
"urn:schemas-microsoft-com:office:word"><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">


<META content=Word.Document name=ProgId>
<META content="MSHTML 5.00.2314.1000" name=GENERATOR>
<META content="Microsoft Word 9" name=Originator><LINK 
href="cid:filelist.xml@01C08776.28619B70" rel=File-List><!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<STYLE>
<!--
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p
	{margin-right:0in;
	mso-margin-top-alt:auto;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	tab-stops:45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732.8pt;
	font-size:10.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:"Courier New";}
span.EmailStyle19
	{mso-style-type:personal-reply;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</STYLE>
</HEAD>
<BODY lang=EN-US link=blue style="tab-interval: .5in" vLink=blue>
<DIV><FONT face="Comic Sans MS"><SPAN class=210581518-26012001>Look fine with 
me. Perhaps we could include this kind of information</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=210581518-26012001>as an appendix to 
the draft.</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=210581518-26012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=210581518-26012001>My only comment 
is that I wouldn't call this "L2 state", I would call it</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=210581518-26012001>sub-network 
convergence layer state, or L3- state.</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=210581518-26012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=210581518-26012001>Semantics, I 
know, but important semantics. We already have a layer 2,</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=210581518-26012001>and it's outside 
of our charter.</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=210581518-26012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=210581518-26012001>Gary</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Mat Horan 
  [mailto:Mat.Horan@comdev.cc]<BR><B>Sent:</B> Friday, January 26, 2001 11:59 
  AM<BR><B>To:</B> seamoby<BR><B>Subject:</B> [seamoby] Context example/ 
  requirement for L2 PPP+<BR><BR></DIV></FONT>
  <DIV class=Section1>
  <P class=MsoNormal><SPAN class=EmailStyle19><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt">In our 
  view of L2 context requirements I&#8217;d like to submit the following items for 
  consideration.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>We understand this 
  could broach on the edge of solution space and definitely in the requirements 
  space, but would like to put this out there in the interest of defining what 
  some L2 context needs to consist of.<SPAN style="mso-spacerun: yes">&nbsp; 
  </SPAN>Since we are attempting to more thoroughly define some of the context 
  types (Sect. 3.2) we wanted to discuss this one.<SPAN 
  style="mso-spacerun: yes">&nbsp; 
  </SPAN>Comments?<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=MsoNormal><SPAN class=EmailStyle19><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=MsoNormal><SPAN class=EmailStyle19><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=MsoNormal><SPAN class=EmailStyle19><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=MsoAutoSig><!--[if supportFields]><span class=EmailStyle19><font 
size=2 color=navy face=Arial><span style='font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span style='mso-element:field-begin'></span><span 
style="mso-spacerun: yes">&nbsp;</span>AUTOTEXTLIST \s &quot;E-mail 
Signature&quot; <span style='mso-element:field-separator'></span></span></font></span><![endif]--><SPAN 
  style="COLOR: navy">Mat Horan, Network Engineer</SPAN><SPAN 
  style="COLOR: navy; mso-color-alt: windowtext"><o:p></o:p></SPAN></P>
  <P class=MsoAutoSig><FONT face="Times New Roman" size=3><SPAN 
  style="COLOR: navy; FONT-SIZE: 12pt">COM DEV Wireless Group</SPAN></FONT><SPAN 
  style="COLOR: navy; mso-color-alt: windowtext"><o:p></o:p></SPAN></P>
  <P class=MsoAutoSig><FONT face="Times New Roman" size=3><SPAN 
  style="COLOR: navy; FONT-SIZE: 12pt">805.544.1089 x2244 (v), 805.544.2055 
  (f)</SPAN></FONT><SPAN 
  style="COLOR: navy; mso-color-alt: windowtext"><o:p></o:p></SPAN></P>
  <P class=MsoAutoSig><FONT face="Times New Roman" size=3><SPAN 
  style="COLOR: navy; FONT-SIZE: 12pt">http://www.comdev.cc</SPAN></FONT><SPAN 
  style="COLOR: navy; mso-color-alt: windowtext"><o:p></o:p></SPAN></P>
  <P class=MsoNormal><!--[if supportFields]><span class=EmailStyle19><font 
size=2 color=navy face=Arial><span style='font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span style='mso-element:field-end'></span></span></font></span><![endif]--><SPAN 
  class=EmailStyle19><FONT face=Arial size=2><SPAN 
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT color=black 
  face="Times New Roman" size=3><SPAN 
  style="COLOR: black; FONT-SIZE: 12pt">&nbsp;</SPAN></FONT><FONT 
  color=black><SPAN 
  style="COLOR: black; mso-color-alt: windowtext"><o:p></o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C087C6.1BDEBB30--


From owner-seamoby@diameter.org  Fri Jan 26 16:10:36 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21936
	for <seamoby-archive@odin.ietf.org>; Fri, 26 Jan 2001 16:10:28 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0QJE5421402
	for seamoby-list; Fri, 26 Jan 2001 11:14:05 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0QJCjo21395
	for <seamoby@diameter.org>; Fri, 26 Jan 2001 11:12:45 -0800
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Fri, 26 Jan 2001 13:18:11 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <D33P1PDJ>; Fri, 26 Jan 2001 13:18:13 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8BB1@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Phil_Neumiller@3com.com'" <Phil_Neumiller@3Com.com>
Cc: seamoby@diameter.org
Subject: [seamoby] RE: Concise Context Transfer Problem Statement
Date: Fri, 26 Jan 2001 13:18:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C087C4.53132FC0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C087C4.53132FC0
Content-Type: text/plain;
	charset="ISO-8859-1"

Thanks Phil. Hopefully we can integrate this into the problem
definition ID that Henrik is working on. I do have some questions,
inserted below....

> -----Original Message-----
> From: Phil_Neumiller@3com.com [mailto:Phil_Neumiller@3com.com]
> Sent: Friday, January 26, 2001 1:01 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@diameter.org
> Subject: Concise Context Transfer Problem Statement
> 
> Gary,
> 
> Here is my best shot a "concise" problem statement.  Please 
> hack on it.
> 
> Service discovery may indeed overlap with context transfer in 
> many ways.
> To avoid future problems we should cooperate with the service 
> discovery
> SDOs like UPnP, SLP (IETF WG), and Jini/Java folks.  I believe there
>  is also interest in the OSGi SDO.
> 
> All these competing SDOs (we currently have "discovery 
> Babylon", kind of like
> wireless hey?) recognize a need for context transfer and 
> context discovery.
> I think the discovery portion of this problem can be 
> mentioned in the draft but
> should be stated to be out of scope.

While I can see the dependency of service discovery on
capability discovery, I do not see them overlapping. I guess
it all depends on what one defines as being the service to
be discovered. Nonetheless, I see capability discovery as
focussed upon one type of node, at the edge of the network.
One node does not constitute a service.

> 
> CONCISE PROBLEM STATEMENT
> --------------------------------------------
> Mobile and portable devices will encounter each other and 
> different access
> networks as they move.  To allow seamless service mobility, 
> these devices
> need to negotiate transport paths for their anchored services 
> as they move.
> In addition to services, the mobile nodes have trust 
> relationships, AAA
> requirements, link compression  transport requirements and QoS
> Requirements.  A protocol capable of transporting the state 
> of the  mobile's
> current service transport states is needed.   This same 
> protocol will also be
> used for transferring and negotiation of state during 
> handovers between edge
> mobility access equipment.  This protocol MUST also have the 

I don't understand the "also": I do not see the differentiation between
these two statements, unless it is between mobile held state and network
held state. I do not understand the purpose of transferring mobile held
state.

> ability to
> negotiate these parameters so that maximal connectivity is achievable.

"maximal connectivity"? the purpose of negotiation for context transfer is
to ensure that the service is sustained to some degree when the new node
has insufficient resources to support the full context.  

To me, connectivity is a binary condition.

> 
> The SeaMoby context transfer working area is responsible for creating
> a robust context transfer and negotiation protocol to 
> facility seamless service
> mobility.  This protocol may also prove useful for use in 
> UPnP, SLP, and other
> discovery related work in other SDOs.

I do not believe that this latter statement belongs in the problem
statement,
for two reasons:
	1. the possibility for spin off applications of a protocol always
exists, and
	    is unpredictable (look at the various strange proposals for
RSVP). 
	2. CT is not about discovery. I remain unconvinced that capability
discovery
                is required, but regardless, capability discovery is not the
problem that
                needs to be solve; service sustainment through a mobile
handoff is the
                problem, and the mitigating factor is the inability to
ensure that a given
                node can support the context being transferred.

Cheers,
Gary

> 
> Thanks,
> 
> Phil
> 
> 
> 
> 
> 
> 
> 
> Sent by:  "Gary Kenward" <gkenward@nortelnetworks.com>
> 
> 
> To:   "'john.loughney @nokia.com'" <john.loughney@nokia.com>,
>       imaginitall@excite.com, 
> seamoby_context@standards.nortelnetworks.com,
>       "Hongyi Li" <hyli@nortelnetworks.com>, seamoby-mm@cdma-2000.org
> cc:    (Phil Neumiller/MW/US/3Com)
> Subject:  RE: [seamoby-mm] Negotiation & plug 'n play
> 
> 
> 
> John:
> 
>   We are in agreement. It would seem that knowing the capability
> of the neighbouring ARs would be useful to context transfer,
> however, as we haven't had much discussion around the context
> transfer solution, it is unclear as how it would be used, nor how
> useful it would be.
> 
>   Capability discovery is a new capability, and different from
> context negotiation. It is not clear to me that you need capability
> discovery if you have context negotiation (or even if you need
> context negotiation if you have capability discovery).
> 
>   The only question at this point is whether we need to include both
> of these approaches in the problem statement, or if there is a high
> level description of the problem that covers both approaches?
> I believe there is, and it concerns the difficult of sustaining the
> communications service to a mobile node when the context includes
> the support for N microflows, each requiring different network
> resources.
> 
> Gary
> 
> > -----Original Message-----
> > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> > Sent: Friday, January 26, 2001 2:45 AM
> > To: imaginitall@excite.com;
> > seamoby_context@standards.nortelnetworks.com; Li, Hongyi
> > [WDLN2:AN22:EXCH]; seamoby-mm@cdma-2000.org
> > Subject: [seamoby-mm] Negotiation & plug 'n play
> >
> >
> > Hi Gary,
> >
> > > The need for negotiation is not so much an issue concerning
> > > capabilities (at the very least, capabitilies are static and
> > > IMHO, should be provisioned), as it is a requirement for proper
> > > resource management. An AR may have the
> > > capabitility to support set of microflows and the requisite
> > > context, but it may not have the resources to support each
> > > and every microflow.
> >
> > I'm (context) transfering from the MM design team, to the CT
> > design team.
> >
> > Hongyi has stated a requirement:
> >
> >   Mobile location aware nodes (MLAN) in an edge mobility
> > domain should be
> > able
> >   to learn of their neighbors (and their neighbors
> > capability). The access
> > points,
> >   routers, and mobile agents (e.g., foreign agent) could be
> > potential MLAN
> > in an
> >   edge mobility domain.
> >
> > This is more CT than MM, in my opinion.  This is something 
> additional
> > to CT, however.  Should we consider this?  Henrik has given a
> > micromobility
> > example, where such plug and play functionality would be useful.
> >
> > In my opinion, I think that there will less network planning with
> > WLAN & Bluetooth than there is with cellular networks, so I think
> > that we may want to have this functionality.
> >
> > best regards,
> > John
> >
> 
> 

------_=_NextPart_001_01C087C4.53132FC0
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: Concise Context Transfer Problem Statement</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Thanks Phil. Hopefully we can integrate this into the problem</FONT>
<BR><FONT SIZE=2>definition ID that Henrik is working on. I do have some questions,</FONT>
<BR><FONT SIZE=2>inserted below....</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Phil_Neumiller@3com.com [<A HREF="mailto:Phil_Neumiller@3com.com">mailto:Phil_Neumiller@3com.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Friday, January 26, 2001 1:01 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Cc: seamoby@diameter.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: Concise Context Transfer Problem Statement</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Gary,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Here is my best shot a &quot;concise&quot; problem statement.&nbsp; Please </FONT>
<BR><FONT SIZE=2>&gt; hack on it.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Service discovery may indeed overlap with context transfer in </FONT>
<BR><FONT SIZE=2>&gt; many ways.</FONT>
<BR><FONT SIZE=2>&gt; To avoid future problems we should cooperate with the service </FONT>
<BR><FONT SIZE=2>&gt; discovery</FONT>
<BR><FONT SIZE=2>&gt; SDOs like UPnP, SLP (IETF WG), and Jini/Java folks.&nbsp; I believe there</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; is also interest in the OSGi SDO.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; All these competing SDOs (we currently have &quot;discovery </FONT>
<BR><FONT SIZE=2>&gt; Babylon&quot;, kind of like</FONT>
<BR><FONT SIZE=2>&gt; wireless hey?) recognize a need for context transfer and </FONT>
<BR><FONT SIZE=2>&gt; context discovery.</FONT>
<BR><FONT SIZE=2>&gt; I think the discovery portion of this problem can be </FONT>
<BR><FONT SIZE=2>&gt; mentioned in the draft but</FONT>
<BR><FONT SIZE=2>&gt; should be stated to be out of scope.</FONT>
</P>

<P><FONT SIZE=2>While I can see the dependency of service discovery on</FONT>
<BR><FONT SIZE=2>capability discovery, I do not see them overlapping. I guess</FONT>
<BR><FONT SIZE=2>it all depends on what one defines as being the service to</FONT>
<BR><FONT SIZE=2>be discovered. Nonetheless, I see capability discovery as</FONT>
<BR><FONT SIZE=2>focussed upon one type of node, at the edge of the network.</FONT>
<BR><FONT SIZE=2>One node does not constitute a service.</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; CONCISE PROBLEM STATEMENT</FONT>
<BR><FONT SIZE=2>&gt; --------------------------------------------</FONT>
<BR><FONT SIZE=2>&gt; Mobile and portable devices will encounter each other and </FONT>
<BR><FONT SIZE=2>&gt; different access</FONT>
<BR><FONT SIZE=2>&gt; networks as they move.&nbsp; To allow seamless service mobility, </FONT>
<BR><FONT SIZE=2>&gt; these devices</FONT>
<BR><FONT SIZE=2>&gt; need to negotiate transport paths for their anchored services </FONT>
<BR><FONT SIZE=2>&gt; as they move.</FONT>
<BR><FONT SIZE=2>&gt; In addition to services, the mobile nodes have trust </FONT>
<BR><FONT SIZE=2>&gt; relationships, AAA</FONT>
<BR><FONT SIZE=2>&gt; requirements, link compression&nbsp; transport requirements and QoS</FONT>
<BR><FONT SIZE=2>&gt; Requirements.&nbsp; A protocol capable of transporting the state </FONT>
<BR><FONT SIZE=2>&gt; of the&nbsp; mobile's</FONT>
<BR><FONT SIZE=2>&gt; current service transport states is needed.&nbsp;&nbsp; This same </FONT>
<BR><FONT SIZE=2>&gt; protocol will also be</FONT>
<BR><FONT SIZE=2>&gt; used for transferring and negotiation of state during </FONT>
<BR><FONT SIZE=2>&gt; handovers between edge</FONT>
<BR><FONT SIZE=2>&gt; mobility access equipment.&nbsp; This protocol MUST also have the </FONT>
</P>

<P><FONT SIZE=2>I don't understand the &quot;also&quot;: I do not see the differentiation between</FONT>
<BR><FONT SIZE=2>these two statements, unless it is between mobile held state and network</FONT>
<BR><FONT SIZE=2>held state. I do not understand the purpose of transferring mobile held</FONT>
<BR><FONT SIZE=2>state.</FONT>
</P>

<P><FONT SIZE=2>&gt; ability to</FONT>
<BR><FONT SIZE=2>&gt; negotiate these parameters so that maximal connectivity is achievable.</FONT>
</P>

<P><FONT SIZE=2>&quot;maximal connectivity&quot;? the purpose of negotiation for context transfer is</FONT>
<BR><FONT SIZE=2>to ensure that the service is sustained to some degree when the new node</FONT>
<BR><FONT SIZE=2>has insufficient resources to support the full context.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>To me, connectivity is a binary condition.</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The SeaMoby context transfer working area is responsible for creating</FONT>
<BR><FONT SIZE=2>&gt; a robust context transfer and negotiation protocol to </FONT>
<BR><FONT SIZE=2>&gt; facility seamless service</FONT>
<BR><FONT SIZE=2>&gt; mobility.&nbsp; This protocol may also prove useful for use in </FONT>
<BR><FONT SIZE=2>&gt; UPnP, SLP, and other</FONT>
<BR><FONT SIZE=2>&gt; discovery related work in other SDOs.</FONT>
</P>

<P><FONT SIZE=2>I do not believe that this latter statement belongs in the problem statement,</FONT>
<BR><FONT SIZE=2>for two reasons:</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>1. the possibility for spin off applications of a protocol always exists, and</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>&nbsp;&nbsp;&nbsp; is unpredictable (look at the various strange proposals for RSVP). </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>2. CT is not about discovery. I remain unconvinced that capability discovery</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is required, but regardless, capability discovery is not the problem that</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; needs to be solve; service sustainment through a mobile handoff is the</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; problem, and the mitigating factor is the inability to ensure that a given</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; node can support the context being transferred.</FONT>
</P>

<P><FONT SIZE=2>Cheers,</FONT>
<BR><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thanks,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Phil</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Sent by:&nbsp; &quot;Gary Kenward&quot; &lt;gkenward@nortelnetworks.com&gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; To:&nbsp;&nbsp; &quot;'john.loughney @nokia.com'&quot; &lt;john.loughney@nokia.com&gt;,</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; imaginitall@excite.com, </FONT>
<BR><FONT SIZE=2>&gt; seamoby_context@standards.nortelnetworks.com,</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;Hongyi Li&quot; &lt;hyli@nortelnetworks.com&gt;, seamoby-mm@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; cc:&nbsp;&nbsp;&nbsp; (Phil Neumiller/MW/US/3Com)</FONT>
<BR><FONT SIZE=2>&gt; Subject:&nbsp; RE: [seamoby-mm] Negotiation &amp; plug 'n play</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; John:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; We are in agreement. It would seem that knowing the capability</FONT>
<BR><FONT SIZE=2>&gt; of the neighbouring ARs would be useful to context transfer,</FONT>
<BR><FONT SIZE=2>&gt; however, as we haven't had much discussion around the context</FONT>
<BR><FONT SIZE=2>&gt; transfer solution, it is unclear as how it would be used, nor how</FONT>
<BR><FONT SIZE=2>&gt; useful it would be.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; Capability discovery is a new capability, and different from</FONT>
<BR><FONT SIZE=2>&gt; context negotiation. It is not clear to me that you need capability</FONT>
<BR><FONT SIZE=2>&gt; discovery if you have context negotiation (or even if you need</FONT>
<BR><FONT SIZE=2>&gt; context negotiation if you have capability discovery).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; The only question at this point is whether we need to include both</FONT>
<BR><FONT SIZE=2>&gt; of these approaches in the problem statement, or if there is a high</FONT>
<BR><FONT SIZE=2>&gt; level description of the problem that covers both approaches?</FONT>
<BR><FONT SIZE=2>&gt; I believe there is, and it concerns the difficult of sustaining the</FONT>
<BR><FONT SIZE=2>&gt; communications service to a mobile node when the context includes</FONT>
<BR><FONT SIZE=2>&gt; the support for N microflows, each requiring different network</FONT>
<BR><FONT SIZE=2>&gt; resources.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Gary</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; &gt; From: john.loughney@nokia.com [<A HREF="mailto:john.loughney@nokia.com">mailto:john.loughney@nokia.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; &gt; Sent: Friday, January 26, 2001 2:45 AM</FONT>
<BR><FONT SIZE=2>&gt; &gt; To: imaginitall@excite.com;</FONT>
<BR><FONT SIZE=2>&gt; &gt; seamoby_context@standards.nortelnetworks.com; Li, Hongyi</FONT>
<BR><FONT SIZE=2>&gt; &gt; [WDLN2:AN22:EXCH]; seamoby-mm@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; &gt; Subject: [seamoby-mm] Negotiation &amp; plug 'n play</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Hi Gary,</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; The need for negotiation is not so much an issue concerning</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; capabilities (at the very least, capabitilies are static and</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; IMHO, should be provisioned), as it is a requirement for proper</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; resource management. An AR may have the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; capabitility to support set of microflows and the requisite</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; context, but it may not have the resources to support each</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; and every microflow.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; I'm (context) transfering from the MM design team, to the CT</FONT>
<BR><FONT SIZE=2>&gt; &gt; design team.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Hongyi has stated a requirement:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp; Mobile location aware nodes (MLAN) in an edge mobility</FONT>
<BR><FONT SIZE=2>&gt; &gt; domain should be</FONT>
<BR><FONT SIZE=2>&gt; &gt; able</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp; to learn of their neighbors (and their neighbors</FONT>
<BR><FONT SIZE=2>&gt; &gt; capability). The access</FONT>
<BR><FONT SIZE=2>&gt; &gt; points,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp; routers, and mobile agents (e.g., foreign agent) could be</FONT>
<BR><FONT SIZE=2>&gt; &gt; potential MLAN</FONT>
<BR><FONT SIZE=2>&gt; &gt; in an</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp; edge mobility domain.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; This is more CT than MM, in my opinion.&nbsp; This is something </FONT>
<BR><FONT SIZE=2>&gt; additional</FONT>
<BR><FONT SIZE=2>&gt; &gt; to CT, however.&nbsp; Should we consider this?&nbsp; Henrik has given a</FONT>
<BR><FONT SIZE=2>&gt; &gt; micromobility</FONT>
<BR><FONT SIZE=2>&gt; &gt; example, where such plug and play functionality would be useful.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; In my opinion, I think that there will less network planning with</FONT>
<BR><FONT SIZE=2>&gt; &gt; WLAN &amp; Bluetooth than there is with cellular networks, so I think</FONT>
<BR><FONT SIZE=2>&gt; &gt; that we may want to have this functionality.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; best regards,</FONT>
<BR><FONT SIZE=2>&gt; &gt; John</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C087C4.53132FC0--


From owner-seamoby@diameter.org  Fri Jan 26 16:12:57 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22037
	for <seamoby-archive@odin.ietf.org>; Fri, 26 Jan 2001 16:12:52 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0QJnFw21523
	for seamoby-list; Fri, 26 Jan 2001 11:49:15 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0QJn6o21518
	for <seamoby@diameter.org>; Fri, 26 Jan 2001 11:49:08 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 26 Jan 2001 13:56:27 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <D33P1QVF>; Fri, 26 Jan 2001 13:56:22 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8BB9@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'seamoby'" <seamoby@diameter.org>
Cc: seamoby_context@standards.nortelnetworks.com
Subject: [seamoby] SeaMoby Context Transfer design team conference call, Monday Janu ary 
         29, 2001, 11 am EST
Date: Fri, 26 Jan 2001 13:56:12 -0500
Sensitivity: Company-Confidential
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: text/plain; charset="ISO-8859-1"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

The North American phone number for the conference call is 

613 765-3171 

and the passcode is

691493#

(please remember the "#" sign).

The agenda will be to review the latest release (-02?) of the problem
statement draft.
Hopefully, it will be posted to the seamoby list sometime today 

Gary


From owner-seamoby@diameter.org  Fri Jan 26 19:59:07 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26379
	for <seamoby-archive@odin.ietf.org>; Fri, 26 Jan 2001 19:59:06 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0R03Eq22605
	for seamoby-list; Fri, 26 Jan 2001 16:03:14 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0R033o22600
	for <seamoby@diameter.org>; Fri, 26 Jan 2001 16:03:05 -0800
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f0QN9W107810;
	Fri, 26 Jan 2001 15:09:32 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104])
	by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f0QNAfA26345;
	Fri, 26 Jan 2001 15:10:41 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 882569E0.007F794D ; Fri, 26 Jan 2001 15:12:21 -0800
X-Lotus-FromDomain: 3COM
From: Phil_Neumiller@3Com.com
To: "Muhammad Jaseemuddin" <jaseem@nortelnetworks.com>
cc: seamoby@diameter.org
Message-ID: <882569E0.007F7773.00@hqoutbound.ops.3com.com>
Date: Fri, 26 Jan 2001 17:18:20 -0600
Subject: [seamoby] RE: [seamoby-mm] Thwap... that's my head hitting the wall...
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=LMfRvn0sgiQBjRHUonW2vL7D59pm6kHfkCl3pqmfteEgfQhWz22Op6lh"
Content-Disposition: inline
Sender: owner-seamoby@diameter.org
Precedence: bulk

--0__=LMfRvn0sgiQBjRHUonW2vL7D59pm6kHfkCl3pqmfteEgfQhWz22Op6lh
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline





> If I remember correctly you claim that
>you have a single solution that makes later distinction transparent. It will
>be interesting to see what that solution looks like.
>
>    - Muhammad Jaseemuddin

The solution removes the distinction between macro and micro, and employs the
same handover method universally (i.e. the same edge mobility code always
runs).

Since this idea of making the distinction transparent seems to generate lots of
heat in the MIP and SeaMoby WGs, I will be taking this in draft form to the
MIP group where the chairs feel it belongs.  End of story for SeaMoby.  If you
want some more details, read the rest of my raving below (NOTE: The section
below contains flame bait,  so folks, you probably should hit that delete button
 now!).  Thanks.

 - - - BIG WARNING  - - -

The following is NOT SeaMoby material and has only been posted to this list
as a courtesy to those following the "thwap" thread.

Well your still with me.  The method for doing this involves doing make-before-
break in many respects all the time.  It involves logically meshing of
neighbouring
(cells/coverage areas).  It involves using a common inter-BS/AP signalling and
bearer transport that allows heterogeneous radio types to work as peers.   It
involves using  SCTP to create semi-permanent logically named fault tolerant
tunnels between adjacent meshed bases stations on the edge of the global
Internet.
Bearer and  signalling traffic will be reliably transported between neighbouring
cells and access points independent of radio type.  The AP/BS itself is a router
and the core is just the global Internet in this architecture.  All radio
specifics
are hidden behind the "face" of an IP router.

This is really 4G stuff I guess.  The MIP WG is MUCH more focused on 3G stuff
at this time so I expect this work to be sort of back-burnered in the MIP WG
until the 3G stuff cools off.  Even then it might get shot down, but we will
probably
be deploying by then...

- - - DANGER TURN BACK NOW ---

<flame bait>
3GPP and 3GPP2 are NOT Internet architectures.  They took their legacy
stovepipe architectures and spray-painted them with IP and called them next
generation.   I suspect that after the 3G debacle has been exposed for what it
is (largely a pile of manure), people will be eagerly looking to 4G solutions.
Don't get me wrong, I have been convinced that the 3G systems will work and
that is the important thing.  Having a simple world standard with universal
roaming
does not appear to be that important to the carriers since they still prefer to
"empire build" around individual air interfaces and get vendor lock-in.  The US
government has  "nationalized"  its RF spectrum like the rest of the world so
 they can eventually relinquish its control to the UN along with the rest of US
sovereignty I suppose.

Don't expect much innovation in the 3G spectrum.   Only entrenched players
can overcome the barrier to entry (created by the governments) with their deep
pockets.  The carriers are also able to give certain TLA agencies access to the
data running over the networks as required by the  governments of the world in
their ever increasing need to watch and control our communication.
</flame bait>


--0__=LMfRvn0sgiQBjRHUonW2vL7D59pm6kHfkCl3pqmfteEgfQhWz22Op6lh
Content-type: text/html; 
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i
TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTIuMzUiPg0KPFRJVExFPlJFOiBbc2Vh
bW9ieS1tbV0gVGh3YXAuLi4gdGhhdCdzIG15IGhlYWQgaGl0dGluZyB0aGUgd2FsbC4uLjwvVElU
TEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCg0KPFA+PEZPTlQgQ09MT1I9IiMwMDAwRkYiIFNJWkU9MiBG
QUNFPSJBcmlhbCI+bXkgY29tbWVudHMgYXJlIGluLWxpbmUuPC9GT05UPg0KPC9QPg0KPFVMPg0K
PFA+PEZPTlQgU0laRT0xIEZBQ0U9IkFyaWFsIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwv
Rk9OVD4NCjxCUj48Qj48Rk9OVCBTSVpFPTEgRkFDRT0iQXJpYWwiPkZyb206Jm5ic3A7Jm5ic3A7
PC9GT05UPjwvQj4gPEZPTlQgU0laRT0xIEZBQ0U9IkFyaWFsIj5qb2huLmxvdWdobmV5QG5va2lh
LmNvbSBbU01UUDpqb2huLmxvdWdobmV5QG5va2lhLmNvbV08L0ZPTlQ+DQo8QlI+PEI+PEZPTlQg
U0laRT0xIEZBQ0U9IkFyaWFsIj5TZW50OiZuYnNwOyZuYnNwOzwvRk9OVD48L0I+IDxGT05UIFNJ
WkU9MSBGQUNFPSJBcmlhbCI+TW9uZGF5LCBKYW51YXJ5IDIyLCAyMDAxIDM6MjYgQU08L0ZPTlQ+
DQo8QlI+PEI+PEZPTlQgU0laRT0xIEZBQ0U9IkFyaWFsIj5UbzombmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDs8L0ZPTlQ+PC9CPiA8Rk9OVCBTSVpFPTEgRkFDRT0iQXJpYWwiPlBoaWxfTmV1bWlsbGVy
QDNjb20uY29tPC9GT05UPg0KPEJSPjxCPjxGT05UIFNJWkU9MSBGQUNFPSJBcmlhbCI+Q2M6Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9GT05UPjwvQj4gPEZPTlQgU0laRT0xIEZBQ0U9IkFyaWFs
Ij5zZWFtb2J5LW1tQGNkbWEtMjAwMC5vcmc8L0ZPTlQ+DQo8QlI+PEI+PEZPTlQgU0laRT0xIEZB
Q0U9IkFyaWFsIj5TdWJqZWN0OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOzwvRk9OVD48L0I+IDxGT05UIFNJWkU9MSBGQUNFPSJBcmlhbCI+UkU6IFtzZWFtb2J5LW1t
XSBUaHdhcC4uLiB0aGF0J3MgbXkgaGVhZCBoaXR0aW5nIHRoZSB3YWxsLi4uPC9GT05UPg0KPC9Q
Pg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkhpIFBoaWwsPC9GT05UPg0KPC9QPg0K
DQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZndDsgSWYgU2VhTW9ieSBjYW4gb25seSB3
b3JrIG9uIGludHJhLWRvbWFpbiBtb2JpbGl0eSB3ZSB3aWxsIGdldCA8L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mZ3Q7IGEgYnJhaW4gZGVhZCBtaWNyb21vYmlsaXR5IHNv
bHV0aW9uIHRoYXQgZG9lc24ndCBzb2x2ZSB0aGUgUkVBTCA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yIEZBQ0U9IkFyaWFsIj4mZ3Q7IHByb2JsZW0uPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBT
SVpFPTIgRkFDRT0iQXJpYWwiPlNvIGZhciwgSSBoYXZlbid0IHNlZW4gKG9yIGJlZW4gYWJsZSB0
byBkZWNpcGhlcikgeW91ciB0aG91Z2h0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJB
cmlhbCI+YWJvdXQgd2hhdCB0aGUgUkVBTCBwcm9ibGVtIGlzLiZuYnNwOyBJJ3ZlIHNlZW4geW91
IG9iamVjdGluZzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPnRvIGEgbG90
IG9mIG90aGVyIHBlb3BsZXMnIG1haWxzLCBidXQgSU1ITywgeW91IGhhdmVuJ3Q8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5jbGVhcmx5IHN0YXRlZCB3aGF0IHlvdSBzZWUg
dGhlIHByb2JsZW0gdG8gYmUuJm5ic3A7IEl0IG1heSBiZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTIgRkFDRT0iQXJpYWwiPmhlbHBmdWwgaWYgeW91IHN0YXJ0IHdpdGggYSBjbGVhciBzaGVldCBv
ZiBwYXBlciBhbmQgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+d3JpdGUg
ZG93biB0aGUgcHJvYmxlbSAmYW1wOyBnaXZlIGNvbmNyZXRlIHJlYXNvbnMgd2h5IFgsIFk8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5hbmQgWiBkb24ndCBhZGRyZXNzIHRo
ZSB5b3VyIHByb2JsZW0uPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPlRoYW5rcyw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5Kb2huPC9G
T05UPg0KPEJSPjxCPjxJPjxGT05UIENPTE9SPSIjMDAwMEZGIiBTSVpFPTIgRkFDRT0iQXJpYWwi
PltNSl08L0ZPTlQ+PC9JPjwvQj48ST48L0k+Jm5ic3A7PEZPTlQgQ09MT1I9IiMwMDAwRkYiIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+IFBoaWw6IHlvdXIgaWRlYXMgYXJlIHZlcnkgaW50ZXJlc3Rpbmcg
YW5kIEkgYW0gdHJ5aW5nIHRvIGZhdGhvbSB0aGVtIHRvIGFzIG11Y2ggb2YgbXkgY2FwYWJpbGl0
eS4gQnV0LCB3aWxsIHlvdSBlbGlnaHRlbiB1cyB3aXRoIHRoZSByZWFzb24gd2h5IGRvIHlvdSB0
aGluayB0aGF0IGFuIGludHJhLWRvbWFpbiBtb2JpbGl0eSBzb2x1dGlvbiB3aWxsIGJlIGEgYnJh
aW4gZGVhZCBtaWNyb21vYmlsaXR5IHNvbHV0aW9uLiBPbmUgYWR2YW50YWdlIEkgc2VlIG9mIHBh
cnRpdGlvbmluZyBhdCBpbnRyYS1kb21haW4gYW5kIGludGVyLWRvbWFpbiBpcyB0byBnaXZlIGFu
IG9wZXJhdG9yIGZsZXhpYmlsaXR5IHRvIGhhdmUgYSBtb2JpbGl0eSBzb2x1dGlvbiAoYW5kIGFz
IGEgbWF0dGVyIG9mIGZhY3QgdGVjaG9sb2d5IHNvbHV0aW9uKSBvZiBpdHMgb3duIGNob2ljZSBm
b3IgdGhlIGVkZ2Ugb2YgaXRzIG93biBkb21haW4uIEFuZCBJIGFsc28gYXNzdW1lIHRoYXQgdGhl
IHJlcXVpcmVtZW50cyBiZXR3ZWVuIGludHJhLWRvbWFpbiBoYW5kb2ZmIGFuZCBpbnRlci1kb21h
aW4gaGFuZG9mZiB3aWxsIHN1cmVseSBiZSBkaWZmZXJlbnQuIEZvciBleGFtcGxlLCBhIG1vYmls
ZSBtYXkgbmVlZCB0byBiZSByZS1hdXRob3JpemVkL3JlLWF1dGhlbnRpY2F0ZWQgdGhyb3VnaCBB
QUEgc2VydmVycyAobG9jYWwgYW5kIGhvbWUpIHdoZW4gaXQgbW92ZXMgaW50byBhIG5ldyBkb21h
aW4uIEhvd2V2ZXIsIHNvbWUgc3RhbmRhcmQgaGFuZG92ZXIgc2lnbmFsaW5nIGFuZCByb3V0aW5n
L2ZvcndhcmRpbmcgc29sdXRpb24gY291bGQgYmUgZGVmaW5lZCB0byB3b3JrIChhdCB0aGUgZWRn
ZSBvbmx5LCBhbmQgaGVyZSBpbiB5b3VyIGRlZmluaXRpb24gb2YgZWRnZSkgYWNyb3NzIHRoZSBk
b21haW5zIGFuZCB0aGF0IG11c3QgYmUgcmVxdWlyZWQgdG8gYWNoaWV2ZSBmYXN0L3Ntb290aC9z
ZWFtbGVzcyBoYW5kb3Zlci4gSSB0ZW5kIHRvIGFncmVlIHdpdGggeW91ciBwYXJ0aXRpb25pbmcg
b2YgZWRnZS9jb3JlLCBidXQgYXQgbGVhc3QgYXQgdGhpcyBwb2ludCBpbiB0aW1lIEkgYWxzbyBi
ZWxlaXZlIHRoYXQgd2UgbWF5IG5lZWQgdG8gZnVydGhlciBwYXJ0aXRpb24gZWRnZSBpbnRvIGlu
dGVyLWRvbWFpbiBhbmQgaW50cmEtZG9tYWluIGFuZCB3b3JrIG9uIHNvbHV0aW9ucy4gSWYgSSBy
ZW1lbWJlciBjb3JyZWN0bHkgeW91IGNsYWltIHRoYXQgeW91IGhhdmUgYSBzaW5nbGUgc29sdXRp
b24gdGhhdCBtYWtlcyBsYXRlciBkaXN0aW5jdGlvbiB0cmFuc3BhcmVudC4gSXQgd2lsbCBiZSBp
bnRlcmVzdGluZyB0byBzZWUgd2hhdCB0aGF0IHNvbHV0aW9uIGxvb2tzIGxpa2UuPC9GT05UPjwv
UD4NCg0KPFA+PEZPTlQgQ09MT1I9IiMwMDAwRkYiIFNJWkU9MiBGQUNFPSJBcmlhbCI+LSBNdWhh
bW1hZCBKYXNlZW11ZGRpbjwvRk9OVD4gPEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsg
PC9GT05UPg0KPC9QPg0KPC9VTD4NCjwvQk9EWT4NCjwvSFRNTD4NCg==

--0__=LMfRvn0sgiQBjRHUonW2vL7D59pm6kHfkCl3pqmfteEgfQhWz22Op6lh--



From owner-seamoby@diameter.org  Fri Jan 26 23:22:28 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29590
	for <seamoby-archive@odin.ietf.org>; Fri, 26 Jan 2001 23:22:27 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0R2djh23276
	for seamoby-list; Fri, 26 Jan 2001 18:39:45 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0R2deo23265
	for <seamoby@diameter.org>; Fri, 26 Jan 2001 18:39:40 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <CTQSV0WN>; Fri, 26 Jan 2001 20:47:28 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078BC9@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Phil Neumiller'" <neumiller@telocity.com>,
        Hamid Syed
	 <hmsyed@nortelnetworks.com>
Cc: seamoby_context@standards.nortelnetworks.com, seamoby@diameter.org,
        seamoby-mm@cdma-2000.org
Subject: RE: [seamoby-mm] Re: [seamoby] A CNP perspective on context trans
	fer.
Date: Fri, 26 Jan 2001 20:47:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk



> -----Original Message-----
> From: Phil Neumiller [mailto:neumiller@telocity.com]
> Sent: Thursday, January 18, 2001 9:28 PM
> To: Hamid Syed
> Cc: seamoby_context@standards.nortelnetworks.com; 
> seamoby@diameter.org;
> seamoby-mm@cdma-2000.org
> Subject: [seamoby-mm] Re: [seamoby] A CNP perspective on context
> transfer.
> 
> 
> Hello Hamid,
> 
> > Hamid Syed wrote:
> > 
> > Hi Phil,
> > 
> > I guess the main problem is "when" to carry out the actual 
> context transfer and what may happen between the time the context was
> > transfered and the time when the actual handover of bearer 
> resources occur
> > 
> 
> pdn>This is precisely why I ADVOCATE bundling context 
> transfer in the form of a 
> pdn>"contract" with each hand over request sent to handover 
> candidates (contractors).
> 
> > For example, in the proactive approach, the actual transfer 
> of context happens whenever the candidate and the source realizes
> > that the mobile may get connectivity thru the candidate. Of 
> course, the candidate can submit a bid but this bid would be based on
> > its current capabilities, which may change with the time. 
> Again as an example, one of the factors while deciding a bid is
> > resource availability. The candidate can submit a bid with 
> the current available resources at time t1, but the mobile may decide
> > to get connected to it at time t2. Now between this delta 
> time, the situation of the available resources at the candidate may
> > change. This is one example where one of the deciding 
> factor is time-dependent. The whole purpose of context 
> transfer and bidding
> > would fail in this scenario. Not to mention that the 
> situation may become even worst for per packet context information.

This is why (in long forgotten emails) I have suggested a
"point-of-no-return" trigger.
The "point-of-no-return" trigger commits both the MN and AP to following
through 
with the bid.  

Further, we might consider that when making a bid, the contractor will
consider 
the bid to be valid for "X" amount of time.  After, the bid acceptance
deadline 
only best effort can be expected.

- Kulwinder.

> 
> pdn>Yes, and the VERY closest you can tie state transfer to 
> when it is needed
> pdn>(the moment before the handoff decision made) is by 
> bundling the context
> pdn>with the handover request and the reflected and pruned 
> context in the bids
> pdn>that come back.  The bids will come back from each 
> handover candidate, and
> pdn>the manager of the anchor (the microflows bound to the MN 
> that is moving),
> pdn>will decide which candidate should get awarded the 
> contract.  I just don't
> pdn>see a more efficient way to do this.  Of course I AM 
> WORKING in the SOLUTION
> pdn>SPACE here (currently a sin in SeaMoby), but I have the 
> code running, and
> pdn>I have been playing with such a system for several years now. :-)
> 


From owner-seamoby@diameter.org  Fri Jan 26 23:46:46 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00118
	for <seamoby-archive@odin.ietf.org>; Fri, 26 Jan 2001 23:46:44 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0R3rn023639
	for seamoby-list; Fri, 26 Jan 2001 19:53:49 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217])
	by charizard.diameter.org (8.10.0/8.10.0) with SMTP id f0R3rlo23634
	for <seamoby@diameter.org>; Fri, 26 Jan 2001 19:53:47 -0800
Received: (cpmta 29472 invoked from network); 26 Jan 2001 19:01:22 -0800
Received: from dsl-64-193-0-129.telocity.com (HELO telocity.com) (64.193.0.129)
  by smtp.telocity.com (209.228.33.217) with SMTP; 26 Jan 2001 19:01:22 -0800
X-Sent: 27 Jan 2001 03:01:22 GMT
Message-ID: <3A723A69.7BA73F9D@telocity.com>
Date: Fri, 26 Jan 2001 21:03:05 -0600
From: Phil Neumiller <neumiller@telocity.com>
Organization: 3Com
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: seamoby@diameter.org
Subject: [seamoby] Upcoming REAL IP for Bluetooth BOF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello Kulwinder,

I tried to respond to your Email regarding the REAL IP stuff for Bluetooth
but it kept bouncing.  Here are some of my first thoughts on what might be
nice to discuss in that BOF.  I sent this to SeaMoby list since many folks
on the SeaMoby list are also interested in Bluetooth.

1).  REAL SIMPLE ad hoc networking capabilities, i.e. limited it to a few
     hops so you don't have to worry about the scalability of flooding
     algorithms, etc.  The MANET group has been focused on esoteric 
     routing algorithm optimization and is in gridlock.  We need simple
     IP based ad hoc networking.  This is an area that Bluetooth can
     take a leadership role for future local wireless technologies.

2).  A careful analysis of the 802.11 to IP binding, and a good debate on
     why the same exact method would not apply for Bluetooth.

3).  Taking a lot of the profile stuff and generalizing so that it can
     be built on IP protocols and used on ANY wireless link layer like
     802.11b for instance.

4).  A generalized method for sending hints up to the IP/Transport layer.
     This is something that ALL L2s need, and Bluetooth can break new
     ground here and actually take a leadership role in the IETF by 
     setting a standard.

5).  The treatment of Bluetooth nodes that act as access points and 
     mobiles simultaneously (i.e. mobile gateways).  Just a simple
     treatment, kind of related to 1 above (MAYBE the same).

If I think of some more I will send them along. 

Thanks,

Phil


From owner-seamoby@diameter.org  Sun Jan 28 03:03:42 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05957
	for <seamoby-archive@odin.ietf.org>; Sun, 28 Jan 2001 03:03:42 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0S6tMM31296
	for seamoby-list; Sat, 27 Jan 2001 22:55:22 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0S6sZo31291
	for <seamoby@diameter.org>; Sat, 27 Jan 2001 22:54:36 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <CTQSV09J>; Sun, 28 Jan 2001 01:02:27 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078BCD@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'taz@em.cig.mot.com'" <taz@em.cig.mot.com>, seamoby@diameter.org
Subject: RE: [seamoby] micro, schmicro
Date: Sun, 28 Jan 2001 01:02:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

> > This is why I believe the better solution is to place the primary
> > functionality for the move in the ARs nearest the MN.   
> 
> Why are you so attached to telling everyone how to design a 
> network?  I can
> guarantee I can design a network with 5 hops to the decision 
> making body that
> still makes the same window, and is more efficient.  Frankly, 
> you are limiting
> yourself by keeping this TOO CLOSE to the MN...you're not 
> giving it enough
> choices...see more on this below.

The key phrase here is "primary functionality".  I knew the moment that I 
typed it someone would mis-understand.  I fully recognize the 
need for there to be functionality further away.  Such as changing the CoA.
What I was referring to were "shades of gray", not "black and white"
solutions.
I have previously made statements supporting your views (If memory serves).


Choice is my number two concern, after real-time performance.  

> Wrong, we must use intelligent packet switched clouds (a LOT 
> faster than
> routing)

I was trying to limit the solution space to something smaller than the "Oort
Cloud".
The problem I have with drawing a cloud is that I don't know if the new path
is 
significantly shorter, or longer than the old path.  If it is much longer
(ie. geo-synchro satillite)
then seamless hand-off of real-time streams is not possible due to time lag,
and we may opt for reactive handoff.

> 
> >  - move decision making closer to the MN
> 
> Bzzzt.  We want the MN to be able to choose from the APs 
> around it...to do
> this efficiently (and cost effectively), we want to move this 
> a few hops from the
> AP, so the network can experience some natural aggregation, 
> thus eliminating
> the need for every AP to be linked to every possible 
> neighbor, and allowing a
> link to die without impeding CT.

I agree that efficiency is possible by aggregating some functionality.  I
wish you could see the draft.  My concern was over the terminology.  

Also, I think you are assuming that a user with a private Bluetooth or
802.11 network will actually have, or want five hops.  This the Commericial
Cellular, or ISP business model.  If I don't want to pay for ISP bandwidth
to connect with a co-worker in the next room should I be forced to do five
hops for "efficiency" ?  Can I not choose less hops and save some money?  I
suppose it depends if you primary concern is efficient use of ISP resources,
or efficient use of end-user resources (saving money). 

>  
> > Also, since the problem space encompasses mobile wireless 
> we must provide
> > positive confirmation of every message between the MN and an AR.
> 
> Ouch...again, painful.  This is an over-generalization.  See 
> SCTP.  SCTP is
> the perfect protocol for this stuff, since that's what it was 
> designed for.  Why
> confirm every single message and waste bandwidth and battery, 
> when there's a
> better method?

I am NOT saying send a seperate confirmation message for message sent.
Messages in Bluetooth are confirmed using a "piggyback" scheme.  A single
bit (ARQN) is set to one in the header to indicate postive confirmation of
the reception, of the last message during the last Master/Slave time.  It is
set to zero to indicate negative confirmation.  There is no significant
"extra"  bandwidth, or battery life being wasted.  This is done at the L2
level.  

Further, I fully support SCTP. 

Referring to section 6.2 of RFC2960 (SCTP):

"The SCTP endpoint MUST always acknowledge the reception of each valid DATA
chunk." 

Sounds like positive confirmation.  My point is that in mobile wireless
communications it is not unreasonable to lose one packet every one hundred.
Further, if we want successful seamless transfer, some type of confirmation
+ timeout scheme must be considered for the very reasons that you have
stated for the wired side in addition to the wireless reasons.  This is what
I mean by transaction-based mode changes. 

- Kulwinder.
Bluetooth Firmware Design
Zucotto Wireless Inc.


From owner-seamoby@diameter.org  Mon Jan 29 02:27:04 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27916
	for <seamoby-archive@odin.ietf.org>; Mon, 29 Jan 2001 02:27:04 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0T6Sot06209
	for seamoby-list; Sun, 28 Jan 2001 22:28:50 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0T6Sko06198
	for <seamoby@diameter.org>; Sun, 28 Jan 2001 22:28:47 -0800
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <CTQSWAFP>; Mon, 29 Jan 2001 00:36:41 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078BD0@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Pat Calhoun'" <pcalhoun@nasnfs.eng.sun.com>, john.loughney@nokia.com
Cc: Pat.Calhoun@eng.sun.com, charliep@iprg.nokia.com, seamoby-mm@cdma-2000.org,
        "'seamoby@diameter.org'" <seamoby@diameter.org>
Subject: [seamoby] The right protocol       was  RE: [seamoby-mm] ietf-seamoby-mm-pr
	oblem-00-a1.txt
Date: Mon, 29 Jan 2001 00:36:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com]
> Sent: Wednesday, January 24, 2001 10:01 AM
> To: john.loughney@nokia.com
> Cc: Pat.Calhoun@eng.sun.com; charliep@iprg.nokia.com;
> seamoby-mm@cdma-2000.org
> Subject: RE: [seamoby-mm] ietf-seamoby-mm-problem-00-a1.txt
> 
> 
> > Hi Pat,
> > 
> > > Figuring out that Mobile IP DOES solve all of the problems 
> > > *is* success, btw. Success is not measured by the fact that 
> > > we create a protocol only, since reducing the work load in 
> > > IETF working groups is still an IESG concern (and
> > > protocols with duplicate functionality is one of mine).
> > 
> > Just a procedural question.  Would it be in scope of
> > SeaMoby (maybe after rechartering) to specify how MIP
> > can be used to support Seamless Mobility?  There
> > are a lot of options (headers, etc) for MIP and
> > if MIP was suitable for SeaMoby needs, I think some
> > work might still be needed.  
> > 
> Let me preface this e-mail with a statement that I am NOT 
> against work going
> on here. Some people seem to imply that is the fact. I am 
> just waiting to see
> the problem statement to be convinced.
> 
> I believe that if we can identify changes to the Mobile IP 
> protocol that would
> provide requirements that we've identified, then I think it 
> is within our
> scope. What we may need to do, is create a draft, and once we have WG
> concensus, punt it over to the MIP WG for review.
> 
> PatC
>

Pat,

I have some IP network problems.  I want to know what is needed to provide a
solution.


Problem 1:

I have one Bluetooth access point at home and one work.  Is my domain the
entire city?

Do I gain anything meaningful by treating each access point as part of a
single domain, or is it just extra overhead that can be reduced with the
right protocol?


Problem 2:

I have one Bluetooth access point in my office and one one 802.11 access
point in my office.
And no other access points in the building.  Is each access point also a
seperate domain?

Do I gain anything meaningful by giving each access point a seperate domain,
or is it just extra overhead that can be reduced with the right protocol?

Problem 3:

I have one access point in my office and with one Bluetooth interface and
one one 802.11 interface in my office.
And no other access points in the building.  Is each interface also a
seperate domain?

Do I gain anything meaningful by giving each interface a seperate domain, or
is it just extra overhead that can be reduced with the right protocol?

Problem 4:

I have an office cubicle in large room filled with office cubicles.  It just
so happens that each co-worker has decided on a different access technology
such that when I traverse the room with my PDA the following switching
happens every four feet:

Bluetooth
802.11
Bluetooth
802.11
Bluetooth
802.11
Bluetooth
802.11
Bluetooth
802.11
Bluetooth
802.11

Since each is considered an "inter-domain" handoff I suppose I can use
SeaMoby.

But suppose, as I enter a hallway it is completely 802.11 and intra-domain.

So, should I go the IESG and request second handoff protocol?

But, as I enter another hallway it is completely bluetooth and intra-domain.

So, should I go the IESG and request third handoff protocol?

When I step outside and switch to GPRS will I be using a fourth protocol
while I drive home?



What would the IESG think if we could have a single protocol that could
handle all edge handovers and let MIP handle core handovers?
Looking at the SeaMoby roadmap I see that by Mar 01 we must submit a revised
charter.

Can we accommodate the above four problems without a revised charter? 

- Kulwinder.


 


From owner-seamoby@diameter.org  Mon Jan 29 10:45:30 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04160
	for <seamoby-archive@odin.ietf.org>; Mon, 29 Jan 2001 10:45:29 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0TEOL707085
	for seamoby-list; Mon, 29 Jan 2001 06:24:21 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0TENgo07077
	for <seamoby@diameter.org>; Mon, 29 Jan 2001 06:23:42 -0800
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA07499;
	Mon, 29 Jan 2001 05:30:41 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA20765;
	Mon, 29 Jan 2001 05:30:40 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id FAA06817;
	Mon, 29 Jan 2001 05:30:37 -0800 (PST)
Date: Mon, 29 Jan 2001 05:30:38 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: [seamoby] problem statement and rechartering (was: Re: The right protocol was  RE: [seamoby-mm] ietf-seamoby-mm-pr oblem-00-a1.txt)
To: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
Cc: "'Pat Calhoun'" <pcalhoun@nasnfs.eng.sun.com>, john.loughney@nokia.com,
        Pat.Calhoun@eng.sun.com, charliep@iprg.nokia.com,
        seamoby-mm@cdma-2000.org,
        "'seamoby@diameter.org'" <seamoby@diameter.org>
In-Reply-To: "Your message with ID" <FC0292EA4D13D34EA2E5FC728D70A8E3078BD0@NEPTUNE.zucotto.com>
Message-ID: <Roam.SIMC.2.0.6.980775038.3260.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

[lots'a stuff on inter technology handoff and ping pong situations]

> What would the IESG think if we could have a single protocol that could
> handle all edge handovers and let MIP handle core handovers?

Again, how is an edge handoff different from a core handoff? 

Folks, the reason why I am playing the devil's advocate is because I need the
same answers to the questions that will be asked of me when I move our problem
statement to the IESG. If I have no answers to obvious questions, then it
doesn't look good.

The problems you described above are already handled today, and even more so
with the fast handoff work. HOWEVER, some discussions we've had on handoff in
the network (edge) being related to AR/AP capabilities is not a Mobile IP
thing, so there are certainly some differences there.

> Looking at the SeaMoby roadmap I see that by Mar 01 we must submit a revised
> charter.
> 
> Can we accommodate the above four problems without a revised charter? 

no. We need to hand in our problem statements, and the re-charter will provide
the IESG with a go/no-go on each problem. The end result could be that we only
work on a subset of our existing charter, if some problem statements don't
provide the convincing arguments.

Hope this helps,

PatC



From owner-seamoby@diameter.org  Mon Jan 29 11:00:38 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04379
	for <seamoby-archive@odin.ietf.org>; Mon, 29 Jan 2001 11:00:37 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0TEqfS07158
	for seamoby-list; Mon, 29 Jan 2001 06:52:41 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0TEqdo07153
	for <seamoby@diameter.org>; Mon, 29 Jan 2001 06:52:39 -0800
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA15512;
	Mon, 29 Jan 2001 06:00:07 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23074;
	Mon, 29 Jan 2001 06:00:06 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id FAA10647;
	Mon, 29 Jan 2001 05:59:43 -0800 (PST)
From: James Kempf <kempf@heliopolis.Eng.Sun.COM>
Message-Id: <200101291359.FAA10647@heliopolis.Eng.Sun.COM>
Date: Mon, 29 Jan 2001 05:57:46 -0800
To: <Phil_Neumiller@3Com.com>, "Gary Kenward" <gkenward@nortelnetworks.com>
Cc: <seamoby@diameter.org>
Reply-To: <kempf@heliopolis.Eng.Sun.COM>
Subject: Re: [seamoby] Concise Context Transfer Problem Statement
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Gary,

The problem is nobody takes service discovery seriously. It is always
an afterthought. Everbody thinks their discovery problem is unique
and requires a special solution for their protocol. Consequently,
there is a proliferation of specialized discovery solutions. Service
discovery is always an afterthough.

I wouldn't hold my breath until this changes. Until the IESG or some
IETF working group decides
to push for some kind of unified solution, it will probably continue
to be this way.


		jak

PS: I'm just speaking from an IETF perspective here, not including
UpNP (which has its own history) nor Jini.

>
>
>Gary,
>
>Here is my best shot a "concise" problem statement.  Please hack on it.
>
>Service discovery may indeed overlap with context transfer in many ways.
>To avoid future problems we should cooperate with the service discovery
>SDOs like UPnP, SLP (IETF WG), and Jini/Java folks.  I believe there
> is also interest in the OSGi SDO.
>
>All these competing SDOs (we currently have "discovery Babylon", kind of like
>wireless hey?) recognize a need for context transfer and context discovery.
>I think the discovery portion of this problem can be mentioned in the draft but
>should be stated to be out of scope.
>
>CONCISE PROBLEM STATEMENT
>--------------------------------------------
>Mobile and portable devices will encounter each other and different access
>networks as they move.  To allow seamless service mobility, these devices
>need to negotiate transport paths for their anchored services as they move.
>In addition to services, the mobile nodes have trust relationships, AAA
>requirements, link compression  transport requirements and QoS
>Requirements.  A protocol capable of transporting the state of the  mobile's
>current service transport states is needed.   This same protocol will also be
>used for transferring and negotiation of state during handovers between edge
>mobility access equipment.  This protocol MUST also have the ability to
>negotiate these parameters so that maximal connectivity is acheivable.
>
>The SeaMoby context transfer working area is responsible for creating
>a robust context transfer and negotiation protocol to facility seamless service
>mobility.  This protocol may also prove useful for use in UPnP, SLP, and other
>discovery related work in other SDOs.
>
>Thanks,
>
>Phil
>
>
>
>
>
>
>
>Sent by:  "Gary Kenward" <gkenward@nortelnetworks.com>
>
>
>To:   "'john.loughney @nokia.com'" <john.loughney@nokia.com>,
>      imaginitall@excite.com, seamoby_context@standards.nortelnetworks.com,
>      "Hongyi Li" <hyli@nortelnetworks.com>, seamoby-mm@cdma-2000.org
>cc:    (Phil Neumiller/MW/US/3Com)
>Subject:  RE: [seamoby-mm] Negotiation & plug 'n play
>
>
>
>John:
>
>  We are in agreement. It would seem that knowing the capability
>of the neighbouring ARs would be useful to context transfer,
>however, as we haven't had much discussion around the context
>transfer solution, it is unclear as how it would be used, nor how
>useful it would be.
>
>  Capability discovery is a new capability, and different from
>context negotiation. It is not clear to me that you need capability
>discovery if you have context negotiation (or even if you need
>context negotiation if you have capability discovery).
>
>  The only question at this point is whether we need to include both
>of these approaches in the problem statement, or if there is a high
>level description of the problem that covers both approaches?
>I believe there is, and it concerns the difficult of sustaining the
>communications service to a mobile node when the context includes
>the support for N microflows, each requiring different network
>resources.
>
>Gary
>
>> -----Original Message-----
>> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
>> Sent: Friday, January 26, 2001 2:45 AM
>> To: imaginitall@excite.com;
>> seamoby_context@standards.nortelnetworks.com; Li, Hongyi
>> [WDLN2:AN22:EXCH]; seamoby-mm@cdma-2000.org
>> Subject: [seamoby-mm] Negotiation & plug 'n play
>>
>>
>> Hi Gary,
>>
>> > The need for negotiation is not so much an issue concerning
>> > capabilities (at the very least, capabitilies are static and
>> > IMHO, should be provisioned), as it is a requirement for proper
>> > resource management. An AR may have the
>> > capabitility to support set of microflows and the requisite
>> > context, but it may not have the resources to support each
>> > and every microflow.
>>
>> I'm (context) transfering from the MM design team, to the CT
>> design team.
>>
>> Hongyi has stated a requirement:
>>
>>   Mobile location aware nodes (MLAN) in an edge mobility
>> domain should be
>> able
>>   to learn of their neighbors (and their neighbors
>> capability). The access
>> points,
>>   routers, and mobile agents (e.g., foreign agent) could be
>> potential MLAN
>> in an
>>   edge mobility domain.
>>
>> This is more CT than MM, in my opinion.  This is something additional
>> to CT, however.  Should we consider this?  Henrik has given a
>> micromobility
>> example, where such plug and play functionality would be useful.
>>
>> In my opinion, I think that there will less network planning with
>> WLAN & Bluetooth than there is with cellular networks, so I think
>> that we may want to have this functionality.
>>
>> best regards,
>> John
>>
>




From owner-seamoby@diameter.org  Mon Jan 29 11:01:45 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04414
	for <seamoby-archive@odin.ietf.org>; Mon, 29 Jan 2001 11:01:43 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0TEs0U07169
	for seamoby-list; Mon, 29 Jan 2001 06:54:00 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0TErvo07164
	for <seamoby@diameter.org>; Mon, 29 Jan 2001 06:53:57 -0800
Received: from esvir06nok.ntc.nokia.com (esvir06nokt.ntc.nokia.com [172.21.143.38])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0TE1qs04215
	for <seamoby@diameter.org>; Mon, 29 Jan 2001 16:01:52 +0200 (EET)
Received: from esebh02nok.ntc.nokia.com (unverified) by esvir06nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T5167b2a06aac158f26150@esvir06nok.ntc.nokia.com>;
 Mon, 29 Jan 2001 16:01:50 +0200
Received: by esebh02nok with Internet Mail Service (5.5.2652.78)
	id <C0KH174F>; Mon, 29 Jan 2001 16:01:47 +0200
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680A892@eseis04nok>
From: john.loughney@nokia.com
To: pcalhoun@nasnfs.eng.sun.com
Cc: seamoby-mm@cdma-2000.org, seamoby@diameter.org
Subject: [seamoby] RE: problem statement and rechartering (was: Re: The right protoc
	ol was  RE: [seamoby-mm] ietf-seamoby-mm-pr oblem-00-a1.txt)
Date: Mon, 29 Jan 2001 16:01:45 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi all,

> The problems you described above are already handled today, 
> and even more so with the fast handoff work. HOWEVER, some 
> discussions we've had on handoff in the network (edge) being 
> related to AR/AP capabilities is not a Mobile IP
> thing, so there are certainly some differences there.

As the editor of the micromobility problem statement draft, 
I strongly encourage everyone to get to me the problem
statements, which is NOT covered by Mobile IP / Fast Handoffs.

Also, I do believe that there could be room to discuss what
enhancements would be needed to Mobile IP to enable 
Seamless Mobility (if you think Mobile IP would be a
solution).

Anyhow, it would be very helpful if everyone at least 
read the fast handoff draft.

best regards,
John


From owner-seamoby@diameter.org  Mon Jan 29 18:35:52 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12069
	for <seamoby-archive@odin.ietf.org>; Mon, 29 Jan 2001 18:35:50 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0TMQ0P07666
	for seamoby-list; Mon, 29 Jan 2001 14:26:00 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0TMPuo07661
	for <seamoby@diameter.org>; Mon, 29 Jan 2001 14:25:56 -0800
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Mon, 29 Jan 2001 16:29:40 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <D33PFWRH>; Mon, 29 Jan 2001 16:29:41 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8BD0@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'kempf'" <kempf@heliopolis.Eng.Sun.COM>,
        Phil_Neumiller <Phil_Neumiller@3Com.com>
Cc: seamoby <seamoby@diameter.org>
Subject: RE: [seamoby] Concise Context Transfer Problem Statement
Date: Mon, 29 Jan 2001 16:29:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C08A3A.954D47E0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C08A3A.954D47E0
Content-Type: text/plain;
	charset="ISO-8859-1"

James:

   Ok, so no one takes service discovery seriously, and there
are many solutions. Does that make it a SeaMoby problem?

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@heliopolis.Eng.Sun.COM]
> Sent: Monday, January 29, 2001 8:58 AM
> To: Phil_Neumiller; Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby
> Subject: Re: [seamoby] Concise Context Transfer Problem Statement
> 
> 
> Gary,
> 
> The problem is nobody takes service discovery seriously. It is always
> an afterthought. Everbody thinks their discovery problem is unique
> and requires a special solution for their protocol. Consequently,
> there is a proliferation of specialized discovery solutions. Service
> discovery is always an afterthough.
> 
> I wouldn't hold my breath until this changes. Until the IESG or some
> IETF working group decides
> to push for some kind of unified solution, it will probably continue
> to be this way.
> 
> 
> 		jak
> 
> PS: I'm just speaking from an IETF perspective here, not including
> UpNP (which has its own history) nor Jini.
> 
> >
> >
> >Gary,
> >
> >Here is my best shot a "concise" problem statement.  Please 
> hack on it.
> >
> >Service discovery may indeed overlap with context transfer 
> in many ways.
> >To avoid future problems we should cooperate with the 
> service discovery
> >SDOs like UPnP, SLP (IETF WG), and Jini/Java folks.  I believe there
> > is also interest in the OSGi SDO.
> >
> >All these competing SDOs (we currently have "discovery 
> Babylon", kind of like
> >wireless hey?) recognize a need for context transfer and 
> context discovery.
> >I think the discovery portion of this problem can be 
> mentioned in the draft but
> >should be stated to be out of scope.
> >
> >CONCISE PROBLEM STATEMENT
> >--------------------------------------------
> >Mobile and portable devices will encounter each other and 
> different access
> >networks as they move.  To allow seamless service mobility, 
> these devices
> >need to negotiate transport paths for their anchored 
> services as they move.
> >In addition to services, the mobile nodes have trust 
> relationships, AAA
> >requirements, link compression  transport requirements and QoS
> >Requirements.  A protocol capable of transporting the state 
> of the  mobile's
> >current service transport states is needed.   This same 
> protocol will also be
> >used for transferring and negotiation of state during 
> handovers between edge
> >mobility access equipment.  This protocol MUST also have the 
> ability to
> >negotiate these parameters so that maximal connectivity is 
> acheivable.
> >
> >The SeaMoby context transfer working area is responsible for creating
> >a robust context transfer and negotiation protocol to 
> facility seamless service
> >mobility.  This protocol may also prove useful for use in 
> UPnP, SLP, and other
> >discovery related work in other SDOs.
> >
> >Thanks,
> >
> >Phil
> >
> >
> >
> >
> >
> >
> >
> >Sent by:  "Gary Kenward" <gkenward@nortelnetworks.com>
> >
> >
> >To:   "'john.loughney @nokia.com'" <john.loughney@nokia.com>,
> >      imaginitall@excite.com, 
> seamoby_context@standards.nortelnetworks.com,
> >      "Hongyi Li" <hyli@nortelnetworks.com>, seamoby-mm@cdma-2000.org
> >cc:    (Phil Neumiller/MW/US/3Com)
> >Subject:  RE: [seamoby-mm] Negotiation & plug 'n play
> >
> >
> >
> >John:
> >
> >  We are in agreement. It would seem that knowing the capability
> >of the neighbouring ARs would be useful to context transfer,
> >however, as we haven't had much discussion around the context
> >transfer solution, it is unclear as how it would be used, nor how
> >useful it would be.
> >
> >  Capability discovery is a new capability, and different from
> >context negotiation. It is not clear to me that you need capability
> >discovery if you have context negotiation (or even if you need
> >context negotiation if you have capability discovery).
> >
> >  The only question at this point is whether we need to include both
> >of these approaches in the problem statement, or if there is a high
> >level description of the problem that covers both approaches?
> >I believe there is, and it concerns the difficult of sustaining the
> >communications service to a mobile node when the context includes
> >the support for N microflows, each requiring different network
> >resources.
> >
> >Gary
> >
> >> -----Original Message-----
> >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> >> Sent: Friday, January 26, 2001 2:45 AM
> >> To: imaginitall@excite.com;
> >> seamoby_context@standards.nortelnetworks.com; Li, Hongyi
> >> [WDLN2:AN22:EXCH]; seamoby-mm@cdma-2000.org
> >> Subject: [seamoby-mm] Negotiation & plug 'n play
> >>
> >>
> >> Hi Gary,
> >>
> >> > The need for negotiation is not so much an issue concerning
> >> > capabilities (at the very least, capabitilies are static and
> >> > IMHO, should be provisioned), as it is a requirement for proper
> >> > resource management. An AR may have the
> >> > capabitility to support set of microflows and the requisite
> >> > context, but it may not have the resources to support each
> >> > and every microflow.
> >>
> >> I'm (context) transfering from the MM design team, to the CT
> >> design team.
> >>
> >> Hongyi has stated a requirement:
> >>
> >>   Mobile location aware nodes (MLAN) in an edge mobility
> >> domain should be
> >> able
> >>   to learn of their neighbors (and their neighbors
> >> capability). The access
> >> points,
> >>   routers, and mobile agents (e.g., foreign agent) could be
> >> potential MLAN
> >> in an
> >>   edge mobility domain.
> >>
> >> This is more CT than MM, in my opinion.  This is something 
> additional
> >> to CT, however.  Should we consider this?  Henrik has given a
> >> micromobility
> >> example, where such plug and play functionality would be useful.
> >>
> >> In my opinion, I think that there will less network planning with
> >> WLAN & Bluetooth than there is with cellular networks, so I think
> >> that we may want to have this functionality.
> >>
> >> best regards,
> >> John
> >>
> >
> 
> 
> 

------_=_NextPart_001_01C08A3A.954D47E0
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [seamoby] Concise Context Transfer Problem Statement</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>James:</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; Ok, so no one takes service discovery seriously, and there</FONT>
<BR><FONT SIZE=2>are many solutions. Does that make it a SeaMoby problem?</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: James Kempf [<A HREF="mailto:kempf@heliopolis.Eng.Sun.COM">mailto:kempf@heliopolis.Eng.Sun.COM</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Monday, January 29, 2001 8:58 AM</FONT>
<BR><FONT SIZE=2>&gt; To: Phil_Neumiller; Kenward, Gary [WDLN2:AN10:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Cc: seamoby</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: [seamoby] Concise Context Transfer Problem Statement</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Gary,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The problem is nobody takes service discovery seriously. It is always</FONT>
<BR><FONT SIZE=2>&gt; an afterthought. Everbody thinks their discovery problem is unique</FONT>
<BR><FONT SIZE=2>&gt; and requires a special solution for their protocol. Consequently,</FONT>
<BR><FONT SIZE=2>&gt; there is a proliferation of specialized discovery solutions. Service</FONT>
<BR><FONT SIZE=2>&gt; discovery is always an afterthough.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I wouldn't hold my breath until this changes. Until the IESG or some</FONT>
<BR><FONT SIZE=2>&gt; IETF working group decides</FONT>
<BR><FONT SIZE=2>&gt; to push for some kind of unified solution, it will probably continue</FONT>
<BR><FONT SIZE=2>&gt; to be this way.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; jak</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; PS: I'm just speaking from an IETF perspective here, not including</FONT>
<BR><FONT SIZE=2>&gt; UpNP (which has its own history) nor Jini.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;Gary,</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;Here is my best shot a &quot;concise&quot; problem statement.&nbsp; Please </FONT>
<BR><FONT SIZE=2>&gt; hack on it.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;Service discovery may indeed overlap with context transfer </FONT>
<BR><FONT SIZE=2>&gt; in many ways.</FONT>
<BR><FONT SIZE=2>&gt; &gt;To avoid future problems we should cooperate with the </FONT>
<BR><FONT SIZE=2>&gt; service discovery</FONT>
<BR><FONT SIZE=2>&gt; &gt;SDOs like UPnP, SLP (IETF WG), and Jini/Java folks.&nbsp; I believe there</FONT>
<BR><FONT SIZE=2>&gt; &gt; is also interest in the OSGi SDO.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;All these competing SDOs (we currently have &quot;discovery </FONT>
<BR><FONT SIZE=2>&gt; Babylon&quot;, kind of like</FONT>
<BR><FONT SIZE=2>&gt; &gt;wireless hey?) recognize a need for context transfer and </FONT>
<BR><FONT SIZE=2>&gt; context discovery.</FONT>
<BR><FONT SIZE=2>&gt; &gt;I think the discovery portion of this problem can be </FONT>
<BR><FONT SIZE=2>&gt; mentioned in the draft but</FONT>
<BR><FONT SIZE=2>&gt; &gt;should be stated to be out of scope.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;CONCISE PROBLEM STATEMENT</FONT>
<BR><FONT SIZE=2>&gt; &gt;--------------------------------------------</FONT>
<BR><FONT SIZE=2>&gt; &gt;Mobile and portable devices will encounter each other and </FONT>
<BR><FONT SIZE=2>&gt; different access</FONT>
<BR><FONT SIZE=2>&gt; &gt;networks as they move.&nbsp; To allow seamless service mobility, </FONT>
<BR><FONT SIZE=2>&gt; these devices</FONT>
<BR><FONT SIZE=2>&gt; &gt;need to negotiate transport paths for their anchored </FONT>
<BR><FONT SIZE=2>&gt; services as they move.</FONT>
<BR><FONT SIZE=2>&gt; &gt;In addition to services, the mobile nodes have trust </FONT>
<BR><FONT SIZE=2>&gt; relationships, AAA</FONT>
<BR><FONT SIZE=2>&gt; &gt;requirements, link compression&nbsp; transport requirements and QoS</FONT>
<BR><FONT SIZE=2>&gt; &gt;Requirements.&nbsp; A protocol capable of transporting the state </FONT>
<BR><FONT SIZE=2>&gt; of the&nbsp; mobile's</FONT>
<BR><FONT SIZE=2>&gt; &gt;current service transport states is needed.&nbsp;&nbsp; This same </FONT>
<BR><FONT SIZE=2>&gt; protocol will also be</FONT>
<BR><FONT SIZE=2>&gt; &gt;used for transferring and negotiation of state during </FONT>
<BR><FONT SIZE=2>&gt; handovers between edge</FONT>
<BR><FONT SIZE=2>&gt; &gt;mobility access equipment.&nbsp; This protocol MUST also have the </FONT>
<BR><FONT SIZE=2>&gt; ability to</FONT>
<BR><FONT SIZE=2>&gt; &gt;negotiate these parameters so that maximal connectivity is </FONT>
<BR><FONT SIZE=2>&gt; acheivable.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;The SeaMoby context transfer working area is responsible for creating</FONT>
<BR><FONT SIZE=2>&gt; &gt;a robust context transfer and negotiation protocol to </FONT>
<BR><FONT SIZE=2>&gt; facility seamless service</FONT>
<BR><FONT SIZE=2>&gt; &gt;mobility.&nbsp; This protocol may also prove useful for use in </FONT>
<BR><FONT SIZE=2>&gt; UPnP, SLP, and other</FONT>
<BR><FONT SIZE=2>&gt; &gt;discovery related work in other SDOs.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;Thanks,</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;Phil</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;Sent by:&nbsp; &quot;Gary Kenward&quot; &lt;gkenward@nortelnetworks.com&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;To:&nbsp;&nbsp; &quot;'john.loughney @nokia.com'&quot; &lt;john.loughney@nokia.com&gt;,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; imaginitall@excite.com, </FONT>
<BR><FONT SIZE=2>&gt; seamoby_context@standards.nortelnetworks.com,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;Hongyi Li&quot; &lt;hyli@nortelnetworks.com&gt;, seamoby-mm@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; &gt;cc:&nbsp;&nbsp;&nbsp; (Phil Neumiller/MW/US/3Com)</FONT>
<BR><FONT SIZE=2>&gt; &gt;Subject:&nbsp; RE: [seamoby-mm] Negotiation &amp; plug 'n play</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;John:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; We are in agreement. It would seem that knowing the capability</FONT>
<BR><FONT SIZE=2>&gt; &gt;of the neighbouring ARs would be useful to context transfer,</FONT>
<BR><FONT SIZE=2>&gt; &gt;however, as we haven't had much discussion around the context</FONT>
<BR><FONT SIZE=2>&gt; &gt;transfer solution, it is unclear as how it would be used, nor how</FONT>
<BR><FONT SIZE=2>&gt; &gt;useful it would be.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; Capability discovery is a new capability, and different from</FONT>
<BR><FONT SIZE=2>&gt; &gt;context negotiation. It is not clear to me that you need capability</FONT>
<BR><FONT SIZE=2>&gt; &gt;discovery if you have context negotiation (or even if you need</FONT>
<BR><FONT SIZE=2>&gt; &gt;context negotiation if you have capability discovery).</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; The only question at this point is whether we need to include both</FONT>
<BR><FONT SIZE=2>&gt; &gt;of these approaches in the problem statement, or if there is a high</FONT>
<BR><FONT SIZE=2>&gt; &gt;level description of the problem that covers both approaches?</FONT>
<BR><FONT SIZE=2>&gt; &gt;I believe there is, and it concerns the difficult of sustaining the</FONT>
<BR><FONT SIZE=2>&gt; &gt;communications service to a mobile node when the context includes</FONT>
<BR><FONT SIZE=2>&gt; &gt;the support for N microflows, each requiring different network</FONT>
<BR><FONT SIZE=2>&gt; &gt;resources.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;Gary</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; From: john.loughney@nokia.com [<A HREF="mailto:john.loughney@nokia.com">mailto:john.loughney@nokia.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; Sent: Friday, January 26, 2001 2:45 AM</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; To: imaginitall@excite.com;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; seamoby_context@standards.nortelnetworks.com; Li, Hongyi</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; [WDLN2:AN22:EXCH]; seamoby-mm@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; Subject: [seamoby-mm] Negotiation &amp; plug 'n play</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; Hi Gary,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt; The need for negotiation is not so much an issue concerning</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt; capabilities (at the very least, capabitilies are static and</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt; IMHO, should be provisioned), as it is a requirement for proper</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt; resource management. An AR may have the</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt; capabitility to support set of microflows and the requisite</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt; context, but it may not have the resources to support each</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt; and every microflow.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; I'm (context) transfering from the MM design team, to the CT</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; design team.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; Hongyi has stated a requirement:</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;&nbsp;&nbsp; Mobile location aware nodes (MLAN) in an edge mobility</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; domain should be</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; able</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;&nbsp;&nbsp; to learn of their neighbors (and their neighbors</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; capability). The access</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; points,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;&nbsp;&nbsp; routers, and mobile agents (e.g., foreign agent) could be</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; potential MLAN</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; in an</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;&nbsp;&nbsp; edge mobility domain.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; This is more CT than MM, in my opinion.&nbsp; This is something </FONT>
<BR><FONT SIZE=2>&gt; additional</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; to CT, however.&nbsp; Should we consider this?&nbsp; Henrik has given a</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; micromobility</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; example, where such plug and play functionality would be useful.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; In my opinion, I think that there will less network planning with</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; WLAN &amp; Bluetooth than there is with cellular networks, so I think</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; that we may want to have this functionality.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; best regards,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; John</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C08A3A.954D47E0--


From owner-seamoby@diameter.org  Mon Jan 29 19:17:31 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12469
	for <seamoby-archive@odin.ietf.org>; Mon, 29 Jan 2001 19:17:31 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0TMqDn07688
	for seamoby-list; Mon, 29 Jan 2001 14:52:13 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0TMqBo07683
	for <seamoby@diameter.org>; Mon, 29 Jan 2001 14:52:11 -0800
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA14603;
	Mon, 29 Jan 2001 13:59:43 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02974;
	Mon, 29 Jan 2001 13:59:42 -0800 (PST)
Received: from heliopolis.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142])
	by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id NAA22183;
	Mon, 29 Jan 2001 13:59:05 -0800 (PST)
From: James Kempf <kempf@heliopolis.Eng.Sun.COM>
Message-Id: <200101292159.NAA22183@heliopolis.Eng.Sun.COM>
Date: Mon, 29 Jan 2001 13:57:21 -0800
To: "Gary Kenward" <gkenward@nortelnetworks.com>,
        "Phil_Neumiller" <Phil_Neumiller@3Com.com>
Cc: "seamoby" <seamoby@diameter.org>
Reply-To: <kempf@heliopolis.Eng.Sun.COM>
Subject: RE: [seamoby] Concise Context Transfer Problem Statement
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dunno. Probably not, considering that various types of mobile systems
will want to do it differently. Unless you consider some kind of
context transfer.

		jak

PS: Sorry for the flame. I've just been somewhat frustrated lately after
having two working groups go off and decide to do their own, custom
service discovery protocol because their problem was soooo unique. And,
Phil's creative flaming served as an inspiration...:-)


>James:
>
>   Ok, so no one takes service discovery seriously, and there
>are many solutions. Does that make it a SeaMoby problem?
>
>Gary
>
>> -----Original Message-----
>> From: James Kempf [mailto:kempf@heliopolis.Eng.Sun.COM]
>> Sent: Monday, January 29, 2001 8:58 AM
>> To: Phil_Neumiller; Kenward, Gary [WDLN2:AN10:EXCH]
>> Cc: seamoby
>> Subject: Re: [seamoby] Concise Context Transfer Problem Statement
>> 
>> 
>> Gary,
>> 
>> The problem is nobody takes service discovery seriously. It is always
>> an afterthought. Everbody thinks their discovery problem is unique
>> and requires a special solution for their protocol. Consequently,
>> there is a proliferation of specialized discovery solutions. Service
>> discovery is always an afterthough.
>> 
>> I wouldn't hold my breath until this changes. Until the IESG or some
>> IETF working group decides
>> to push for some kind of unified solution, it will probably continue
>> to be this way.
>> 
>> 
>> 		jak
>> 
>> PS: I'm just speaking from an IETF perspective here, not including
>> UpNP (which has its own history) nor Jini.
>> 
>> >
>> >
>> >Gary,
>> >
>> >Here is my best shot a "concise" problem statement.  Please 
>> hack on it.
>> >
>> >Service discovery may indeed overlap with context transfer 
>> in many ways.
>> >To avoid future problems we should cooperate with the 
>> service discovery
>> >SDOs like UPnP, SLP (IETF WG), and Jini/Java folks.  I believe there
>> > is also interest in the OSGi SDO.
>> >
>> >All these competing SDOs (we currently have "discovery 
>> Babylon", kind of like
>> >wireless hey?) recognize a need for context transfer and 
>> context discovery.
>> >I think the discovery portion of this problem can be 
>> mentioned in the draft but
>> >should be stated to be out of scope.
>> >
>> >CONCISE PROBLEM STATEMENT
>> >--------------------------------------------
>> >Mobile and portable devices will encounter each other and 
>> different access
>> >networks as they move.  To allow seamless service mobility, 
>> these devices
>> >need to negotiate transport paths for their anchored 
>> services as they move.
>> >In addition to services, the mobile nodes have trust 
>> relationships, AAA
>> >requirements, link compression  transport requirements and QoS
>> >Requirements.  A protocol capable of transporting the state 
>> of the  mobile's
>> >current service transport states is needed.   This same 
>> protocol will also be
>> >used for transferring and negotiation of state during 
>> handovers between edge
>> >mobility access equipment.  This protocol MUST also have the 
>> ability to
>> >negotiate these parameters so that maximal connectivity is 
>> acheivable.
>> >
>> >The SeaMoby context transfer working area is responsible for creating
>> >a robust context transfer and negotiation protocol to 
>> facility seamless service
>> >mobility.  This protocol may also prove useful for use in 
>> UPnP, SLP, and other
>> >discovery related work in other SDOs.
>> >
>> >Thanks,
>> >
>> >Phil
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >Sent by:  "Gary Kenward" <gkenward@nortelnetworks.com>
>> >
>> >
>> >To:   "'john.loughney @nokia.com'" <john.loughney@nokia.com>,
>> >      imaginitall@excite.com, 
>> seamoby_context@standards.nortelnetworks.com,
>> >      "Hongyi Li" <hyli@nortelnetworks.com>, seamoby-mm@cdma-2000.org
>> >cc:    (Phil Neumiller/MW/US/3Com)
>> >Subject:  RE: [seamoby-mm] Negotiation & plug 'n play
>> >
>> >
>> >
>> >John:
>> >
>> >  We are in agreement. It would seem that knowing the capability
>> >of the neighbouring ARs would be useful to context transfer,
>> >however, as we haven't had much discussion around the context
>> >transfer solution, it is unclear as how it would be used, nor how
>> >useful it would be.
>> >
>> >  Capability discovery is a new capability, and different from
>> >context negotiation. It is not clear to me that you need capability
>> >discovery if you have context negotiation (or even if you need
>> >context negotiation if you have capability discovery).
>> >
>> >  The only question at this point is whether we need to include both
>> >of these approaches in the problem statement, or if there is a high
>> >level description of the problem that covers both approaches?
>> >I believe there is, and it concerns the difficult of sustaining the
>> >communications service to a mobile node when the context includes
>> >the support for N microflows, each requiring different network
>> >resources.
>> >
>> >Gary
>> >
>> >> -----Original Message-----
>> >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
>> >> Sent: Friday, January 26, 2001 2:45 AM
>> >> To: imaginitall@excite.com;
>> >> seamoby_context@standards.nortelnetworks.com; Li, Hongyi
>> >> [WDLN2:AN22:EXCH]; seamoby-mm@cdma-2000.org
>> >> Subject: [seamoby-mm] Negotiation & plug 'n play
>> >>
>> >>
>> >> Hi Gary,
>> >>
>> >> > The need for negotiation is not so much an issue concerning
>> >> > capabilities (at the very least, capabitilies are static and
>> >> > IMHO, should be provisioned), as it is a requirement for proper
>> >> > resource management. An AR may have the
>> >> > capabitility to support set of microflows and the requisite
>> >> > context, but it may not have the resources to support each
>> >> > and every microflow.
>> >>
>> >> I'm (context) transfering from the MM design team, to the CT
>> >> design team.
>> >>
>> >> Hongyi has stated a requirement:
>> >>
>> >>   Mobile location aware nodes (MLAN) in an edge mobility
>> >> domain should be
>> >> able
>> >>   to learn of their neighbors (and their neighbors
>> >> capability). The access
>> >> points,
>> >>   routers, and mobile agents (e.g., foreign agent) could be
>> >> potential MLAN
>> >> in an
>> >>   edge mobility domain.
>> >>
>> >> This is more CT than MM, in my opinion.  This is something 
>> additional
>> >> to CT, however.  Should we consider this?  Henrik has given a
>> >> micromobility
>> >> example, where such plug and play functionality would be useful.
>> >>
>> >> In my opinion, I think that there will less network planning with
>> >> WLAN & Bluetooth than there is with cellular networks, so I think
>> >> that we may want to have this functionality.
>> >>
>> >> best regards,
>> >> John
>> >>
>> >
>> 
>> 
>> 




From owner-seamoby@diameter.org  Mon Jan 29 20:20:55 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13388
	for <seamoby-archive@odin.ietf.org>; Mon, 29 Jan 2001 20:20:54 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0U0KKF07806
	for seamoby-list; Mon, 29 Jan 2001 16:20:20 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0U0KHo07798
	for <seamoby@diameter.org>; Mon, 29 Jan 2001 16:20:17 -0800
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23676;
	Mon, 29 Jan 2001 15:28:04 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21294;
	Mon, 29 Jan 2001 15:28:03 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA16651;
	Mon, 29 Jan 2001 15:28:00 -0800 (PST)
Date: Mon, 29 Jan 2001 15:28:01 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: Re: [seamoby] problem statement and rechartering (was: Re: The  right protocol was  RE: [seamoby-mm] ietf-seamoby-mm-pr  oblem-00-a1.txt)
To: "Dana L. Blair" <dblair@cisco.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        Kulwinder Atwal <kulwinder.atwal@zucotto.com>, john.loughney@nokia.com,
        Pat.Calhoun@eng.sun.com, charliep@iprg.nokia.com,
        seamoby-mm@cdma-2000.org,
        "'seamoby@diameter.org'" <seamoby@diameter.org>
In-Reply-To: "Your message with ID" <4.1.20010129172447.009182f0@flipper.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.980810881.15374.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

> We know that Mobile IP requires tunneling and authentication (IPSEC).  Could
> we somehow insert into the problem statement that we need a mobility solution
> where Mobile Device and Server are within the same trusted domain and address
> space, therefore tunneling and IPSEC are not needed.    I don't think Mobile
> IP is addressing mobility solutions that don't require tunnels and
> authentication. The best example I can think of is enterprise mobility.

But we know that IETF doesn't typically work on protocols that don't scale
across the Internet (well, sometimes they do, but shouldn't). I would be
sceptical to create a protocol that does assumes trust in a local subnet (even
more so in the nets that I know need this kind of technology).

> 
> Problem statement text:
> Current mobility standards require tunneling and authentication.  In a
> trusted  domain where both IP endpoints already trust each other and share
> the same address space, tunneling and authentication are not needed.  A good
> example is site local addressing in IPv6.

The problem statement that was made some time back, by yourself, was mobility
within a subnet. I don't know what happened to that one, because that's where
Mobile IP doesn't work. Some comments were made at the last IETF about the
fact that the AP and the AR may be in different boxes, and the fast handoff
work doesn't work well in those scenarios. This same protocol could be used
between the 3G* RAN and core networks. I am sure there are plenty of other
examples where such a protocol would be required.

BTW, some additional information that I've found out today is that the v6 fast
handoff requires a secured binding update between the mobile and the new
access router. I can tell you right now that a full IKE negotiation is far
from what I call fast :(

PatC



From owner-seamoby@diameter.org  Mon Jan 29 20:50:02 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13732
	for <seamoby-archive@odin.ietf.org>; Mon, 29 Jan 2001 20:49:59 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0U0DgL07786
	for seamoby-list; Mon, 29 Jan 2001 16:13:42 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (flipper.cisco.com [171.69.25.141])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0U0Deo07779
	for <seamoby@diameter.org>; Mon, 29 Jan 2001 16:13:40 -0800
Received: from dblair-pc (dhcp-atlanta-220-34.cisco.com [161.44.220.34])
	by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id PAA07610;
	Mon, 29 Jan 2001 15:21:13 -0800 (PST)
Message-Id: <4.1.20010129172447.009182f0@flipper.cisco.com>
X-Sender: dblair@flipper.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 29 Jan 2001 17:57:19 -0500
To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        Kulwinder Atwal <kulwinder.atwal@zucotto.com>
From: "Dana L. Blair" <dblair@cisco.com>
Subject: Re: [seamoby] problem statement and rechartering (was: Re: The
  right protocol was  RE: [seamoby-mm] ietf-seamoby-mm-pr
  oblem-00-a1.txt)
Cc: "'Pat Calhoun'" <pcalhoun@nasnfs.eng.sun.com>, john.loughney@nokia.com,
        Pat.Calhoun@eng.sun.com, charliep@iprg.nokia.com,
        seamoby-mm@cdma-2000.org,
        "'seamoby@diameter.org'" <seamoby@diameter.org>
In-Reply-To: <Roam.SIMC.2.0.6.980775038.3260.pcalhoun@nasnfs>
References: <"Your message with ID" <FC0292EA4D13D34EA2E5FC728D70A8E3078BD0@NEPTUNE.zucotto.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-seamoby@diameter.org
Precedence: bulk

At 05:30 AM 1/29/01 -0800, Patrice Calhoun wrote:
>[lots'a stuff on inter technology handoff and ping pong situations]
>
>> What would the IESG think if we could have a single protocol that could
>> handle all edge handovers and let MIP handle core handovers?
>
>Again, how is an edge handoff different from a core handoff? 
>
>Folks, the reason why I am playing the devil's advocate is because I need the
>same answers to the questions that will be asked of me when I move our problem
>statement to the IESG. If I have no answers to obvious questions, then it
>doesn't look good.

We know that Mobile IP requires tunneling and authentication (IPSEC).  Could
we somehow insert into the problem statement that we need a mobility solution
where Mobile Device and Server are within the same trusted domain and address
space, therefore tunneling and IPSEC are not needed.    I don't think Mobile
IP is addressing mobility solutions that don't require tunnels and authentication.
The best example I can think of is enterprise mobility.

Problem statement text:
Current mobility standards require tunneling and authentication.  In a trusted 
domain where both IP endpoints already trust each other and share the
same address space, tunneling and authentication are not needed.  A good
example is site local addressing in IPv6.

thanks,
Dana

>
>The problems you described above are already handled today, and even more so
>with the fast handoff work. HOWEVER, some discussions we've had on handoff in
>the network (edge) being related to AR/AP capabilities is not a Mobile IP
>thing, so there are certainly some differences there.
>
>> Looking at the SeaMoby roadmap I see that by Mar 01 we must submit a revised
>> charter.
>> 
>> Can we accommodate the above four problems without a revised charter? 
>
>no. We need to hand in our problem statements, and the re-charter will provide
>the IESG with a go/no-go on each problem. The end result could be that we only
>work on a subset of our existing charter, if some problem statements don't
>provide the convincing arguments.

BTW,  I will be somewhat satisfied if this effort simply devolves into a requirements
discussionfor the Mobile IP Working Group (not necessarily the Mobile IP protocol) since
there really is no requirements document for the Mobile IP Working Group.

>
>Hope this helps,
>
>PatC
>



From owner-seamoby@diameter.org  Mon Jan 29 20:50:37 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13755
	for <seamoby-archive@odin.ietf.org>; Mon, 29 Jan 2001 20:50:37 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0U0ZrK07843
	for seamoby-list; Mon, 29 Jan 2001 16:35:53 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0U0Zno07835
	for <seamoby@diameter.org>; Mon, 29 Jan 2001 16:35:49 -0800
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03585;
	Mon, 29 Jan 2001 15:43:40 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23859;
	Mon, 29 Jan 2001 15:43:39 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA18066;
	Mon, 29 Jan 2001 15:43:33 -0800 (PST)
Date: Mon, 29 Jan 2001 15:43:29 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: Re: [seamoby] problem statement and rechartering (was: Re: The   right protocol was  RE: [seamoby-mm] ietf-seamoby-mm-pr   oblem-00-a1.txt)
To: "Dana L. Blair" <dblair@cisco.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        Kulwinder Atwal <kulwinder.atwal@zucotto.com>, john.loughney@nokia.com,
        Pat.Calhoun@eng.sun.com, charliep@iprg.nokia.com,
        seamoby-mm@cdma-2000.org,
        "'seamoby@diameter.org'" <seamoby@diameter.org>
In-Reply-To: "Your message with ID" <4.1.20010129180921.009c4600@flipper.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.980811809.26928.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

> The IPSEC requirement is a big issue in my opinion. 
yup. Somewhere between huge and gigantic.

> I think it would be
> valuable to define a mobility protocol (maybe just changes to Mobile IP)
> which did not require IPSEC.
check. of course, given the way MIPv6 is designed, that will be quite
difficult :(

PatC



From owner-seamoby@diameter.org  Mon Jan 29 21:08:36 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13898
	for <seamoby-archive@odin.ietf.org>; Mon, 29 Jan 2001 21:08:36 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0U0VPS07827
	for seamoby-list; Mon, 29 Jan 2001 16:31:25 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from cisco.com (flipper.cisco.com [171.69.25.141])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0U0VNo07822
	for <seamoby@diameter.org>; Mon, 29 Jan 2001 16:31:23 -0800
Received: from dblair-pc (dhcp-atlanta-220-34.cisco.com [161.44.220.34])
	by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id PAA08165;
	Mon, 29 Jan 2001 15:39:01 -0800 (PST)
Message-Id: <4.1.20010129180921.009c4600@flipper.cisco.com>
X-Sender: dblair@flipper.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 29 Jan 2001 18:13:26 -0500
To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        "Dana L. Blair" <dblair@cisco.com>
From: "Dana L. Blair" <dblair@cisco.com>
Subject: Re: [seamoby] problem statement and rechartering (was: Re: The
   right protocol was  RE: [seamoby-mm] ietf-seamoby-mm-pr 
  oblem-00-a1.txt)
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        Kulwinder Atwal <kulwinder.atwal@zucotto.com>, john.loughney@nokia.com,
        Pat.Calhoun@eng.sun.com, charliep@iprg.nokia.com,
        seamoby-mm@cdma-2000.org,
        "'seamoby@diameter.org'" <seamoby@diameter.org>
In-Reply-To: <Roam.SIMC.2.0.6.980810881.15374.pcalhoun@nasnfs>
References: <"Your message with ID" <4.1.20010129172447.009182f0@flipper.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-seamoby@diameter.org
Precedence: bulk

At 03:28 PM 1/29/01 -0800, Patrice Calhoun wrote:
>> We know that Mobile IP requires tunneling and authentication (IPSEC).  Could
>> we somehow insert into the problem statement that we need a mobility solution
>> where Mobile Device and Server are within the same trusted domain and address
>> space, therefore tunneling and IPSEC are not needed.    I don't think Mobile
>> IP is addressing mobility solutions that don't require tunnels and
>> authentication. The best example I can think of is enterprise mobility.
>
>But we know that IETF doesn't typically work on protocols that don't scale
>across the Internet (well, sometimes they do, but shouldn't). I would be
>sceptical to create a protocol that does assumes trust in a local subnet (even
>more so in the nets that I know need this kind of technology).
>
>> 
>> Problem statement text:
>> Current mobility standards require tunneling and authentication.  In a
>> trusted  domain where both IP endpoints already trust each other and share
>> the same address space, tunneling and authentication are not needed.  A good
>> example is site local addressing in IPv6.
>
>The problem statement that was made some time back, by yourself, was mobility
>within a subnet. I don't know what happened to that one, because that's where
>Mobile IP doesn't work. Some comments were made at the last IETF about the

I think that my previous definition still applies.  At least it is in draft document I believe.
I was just trying to make a stronger case.


>fact that the AP and the AR may be in different boxes, and the fast handoff
>work doesn't work well in those scenarios. This same protocol could be used
>between the 3G* RAN and core networks. I am sure there are plenty of other
>examples where such a protocol would be required.
>
>BTW, some additional information that I've found out today is that the v6 fast
>handoff requires a secured binding update between the mobile and the new
>access router. I can tell you right now that a full IKE negotiation is far
>from what I call fast :(

The IPSEC requirement is a big issue in my opinion.  I think it would be valuable
to define a mobility protocol (maybe just changes to Mobile IP) which did not
require IPSEC.

thanks,
Dana

>
>PatC
>



From owner-seamoby@diameter.org  Mon Jan 29 21:48:17 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15117
	for <seamoby-archive@odin.ietf.org>; Mon, 29 Jan 2001 21:48:16 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0U1OTl07993
	for seamoby-list; Mon, 29 Jan 2001 17:24:29 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0U1ORo07987
	for <seamoby@diameter.org>; Mon, 29 Jan 2001 17:24:27 -0800
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id QAA03340;
	Mon, 29 Jan 2001 16:32:21 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAT03664;
	Mon, 29 Jan 2001 16:32:18 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA28643; Mon, 29 Jan 2001 16:32:17 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14966.2961.846987.801210@thomasm-u1.cisco.com>
Date: Mon, 29 Jan 2001 16:32:17 -0800 (PST)
To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Cc: "Dana L. Blair" <dblair@cisco.com>,
        Kulwinder Atwal <kulwinder.atwal@zucotto.com>, john.loughney@nokia.com,
        Pat.Calhoun@eng.sun.com, charliep@iprg.nokia.com,
        seamoby-mm@cdma-2000.org,
        "'seamoby@diameter.org'" <seamoby@diameter.org>
Subject: Re: [seamoby] problem statement and rechartering (was: Re: The  right protocol was  RE: [seamoby-mm] ietf-seamoby-mm-pr  oblem-00-a1.txt)
In-Reply-To: <Roam.SIMC.2.0.6.980810881.15374.pcalhoun@nasnfs>
References: <4.1.20010129172447.009182f0@flipper.cisco.com>
	<Roam.SIMC.2.0.6.980810881.15374.pcalhoun@nasnfs>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun writes:
 > > We know that Mobile IP requires tunneling and authentication (IPSEC).  Could
 > > we somehow insert into the problem statement that we need a mobility solution
 > > where Mobile Device and Server are within the same trusted domain and address
 > > space, therefore tunneling and IPSEC are not needed.    I don't think Mobile
 > > IP is addressing mobility solutions that don't require tunnels and
 > > authentication. The best example I can think of is enterprise mobility.
 > 
 > But we know that IETF doesn't typically work on protocols that don't scale
 > across the Internet (well, sometimes they do, but shouldn't). I would be
 > sceptical to create a protocol that does assumes trust in a local subnet (even
 > more so in the nets that I know need this kind of technology).

   Binding Updates have such a fundamental
   security hole -- every would-be traffic snooper
   would be given the world's best tool ever -- I
   cannot imagine who in their right mind would
   deploy such a thing, big happy family or not.

 > The problem statement that was made some time back, by yourself, was mobility
 > within a subnet. I don't know what happened to that one, because that's where
 > Mobile IP doesn't work. Some comments were made at the last IETF about the
 > fact that the AP and the AR may be in different boxes, and the fast handoff
 > work doesn't work well in those scenarios.

   I don't understand why it wouldn't? Can
   somebody restate the reason?

 > BTW, some additional information that I've found out today is that the v6 fast
 > handoff requires a secured binding update between the mobile and the new
 > access router. I can tell you right now that a full IKE negotiation is far
 > from what I call fast :(

   Before we become despondent and looking for windows in
   tall buildings, it should be noted that this is a 
   consideration only if key negotiation is in the 
   critical path of a handoff. As far as I can tell, it
   doesn't seem to be in MIP fast handoffs, and I don't
   think that anything we're doing would change that.
   If we end up going down a path leads us that
   direction, we can be pretty sure that it is the
   wrong one.

		Mike


From owner-seamoby@diameter.org  Mon Jan 29 21:50:57 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15146
	for <seamoby-archive@odin.ietf.org>; Mon, 29 Jan 2001 21:50:56 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0U1wEt08025
	for seamoby-list; Mon, 29 Jan 2001 17:58:14 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0U1wCo08019
	for <seamoby@diameter.org>; Mon, 29 Jan 2001 17:58:12 -0800
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA03141;
	Mon, 29 Jan 2001 17:06:15 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAT03775;
	Mon, 29 Jan 2001 17:06:04 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA28652; Mon, 29 Jan 2001 17:06:04 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14966.4987.820692.152021@thomasm-u1.cisco.com>
Date: Mon, 29 Jan 2001 17:06:03 -0800 (PST)
To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Cc: "Dana L. Blair" <dblair@cisco.com>,
        Kulwinder Atwal <kulwinder.atwal@zucotto.com>, john.loughney@nokia.com,
        Pat.Calhoun@eng.sun.com, charliep@iprg.nokia.com,
        seamoby-mm@cdma-2000.org,
        "'seamoby@diameter.org'" <seamoby@diameter.org>
Subject: Re: [seamoby] problem statement and rechartering (was: Re: The   right protocol was  RE: [seamoby-mm] ietf-seamoby-mm-pr   oblem-00-a1.txt)
In-Reply-To: <Roam.SIMC.2.0.6.980811809.26928.pcalhoun@nasnfs>
References: <4.1.20010129180921.009c4600@flipper.cisco.com>
	<Roam.SIMC.2.0.6.980811809.26928.pcalhoun@nasnfs>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun writes:
 > > The IPSEC requirement is a big issue in my opinion. 
 > yup. Somewhere between huge and gigantic.
 > 
 > > I think it would be
 > > valuable to define a mobility protocol (maybe just changes to Mobile IP)
 > > which did not require IPSEC.
 > check. of course, given the way MIPv6 is designed, that will be quite
 > difficult :(

   Actually, that's a feature not a bug. I cannot fathom why
   people think that three dozen application layer crypto 
   schemes is better than one IP layer scheme. Unless they
   think that that means that they can not build crypto 
   into their boxes at all.

   IPsec is a v6 MUST and is being widely back implemented
   into v4. Can we move on?

	    Mike


From owner-seamoby@diameter.org  Mon Jan 29 23:01:07 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16641
	for <seamoby-archive@odin.ietf.org>; Mon, 29 Jan 2001 23:01:06 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0U2pLf08137
	for seamoby-list; Mon, 29 Jan 2001 18:51:21 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2.email.verio.net [129.250.36.42])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0U2pIo08132
	for <seamoby@cdma-2000.org>; Mon, 29 Jan 2001 18:51:18 -0800
Received: from [129.250.38.62] (helo=dfw-mmp2.email.verio.net)
	by dfw-smtpout2.email.verio.net with esmtp
	id 14NQ47-0005Sl-00; Tue, 30 Jan 2001 01:58:39 +0000
Received: from [206.133.83.14] (helo=localhost)
	by dfw-mmp2.email.verio.net with esmtp
	id 14NQ3t-0003o5-00; Tue, 30 Jan 2001 01:58:26 +0000
X-Sender: misterprivacy@hushmail.com
From: Dave <misterprivacy@hushmail.com>
To: "customer" <misterprivacy@hushmail.com>
Date: Mon, 29 Jan 2001 17:14:54 -0500
Subject: [seamoby] I could go to JAIL for selling this CD!
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001__20796735_62094.25"
Message-Id: <E14NQ3t-0003o5-00@dfw-mmp2.email.verio.net>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This is a Multipart MIME message.

------=_NextPart_000_001__20796735_62094.25
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit


------=_NextPart_000_001__20796735_62094.25
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: base64

PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9u
YWwvL2VuIj4NCjxodG1sPg0KPGhlYWQ+DQogICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50
LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4NCiAgIDxt
ZXRhIG5hbWU9IkdFTkVSQVRPUiIgY29udGVudD0iTW96aWxsYS80LjYxIFtlbl0gKFdpbjk4
OyBJKSBbTmV0c2NhcGVdIj4NCiAgIDx0aXRsZT5UaGUgQkFOTkVEIENEITwvdGl0bGU+DQo8
L2hlYWQ+DQo8Ym9keT4NCjxmb250IHNpemU9KzE+SGksPC9mb250Pg0KPHA+PGZvbnQgc2l6
ZT0rMT5JIGhhdmUgYmVlbiByZWNpZXZpbmcgZW1haWxzIHNheWluZyB0aGF0IEknbSBjb250
cmlidXRpbmcNCnRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+dGhlICJtb3JhbCBkZWNh
eSBvZiBzb2NpZXR5IiBieSBzZWxsaW5nIHRoZSBCYW5uZWQgQ0QuJm5ic3A7DQpUaGF0PC9m
b250Pg0KPGJyPjxmb250IHNpemU9KzE+bWF5IGJlLCBidXQgSSBmZWVsIHN0cm9uZ2x5IHRo
YXQgeW91IGhhdmUgYSByaWdodCB0bw0KYmVuZWZpdCBmcm9tPC9mb250Pg0KPGJyPjxmb250
IHNpemU9KzE+dGhpcyBoYXJkLXRvLWZpbmQgaW5mb3JtYXRpb24uPC9mb250Pg0KPHA+PGZv
bnQgY29sb3I9IiNDQzAwMDAiPjxmb250IHNpemU9KzE+U28gSSBhbSBnaXZpbmcgeW91IE9O
RSBMQVNUIENIQU5DRQ0KdG8gb3JkZXI8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9y
PSIjQ0MwMDAwIj48Zm9udCBzaXplPSsxPnRoZSBCYW5uZWQgQ0QhPC9mb250PjwvZm9udD4N
Cjxicj4mbmJzcDsNCjx0YWJsZSBCT1JERVI9MCBDT0xTPTIgV0lEVEg9Ijc1JSIgPg0KPHRy
Pg0KPHRkIFdJRFRIPSIxJSI+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2EuY29tL2lt
YWdlcy9zcHkuanBnIiBoZWlnaHQ9MTI4IHdpZHRoPTg2PjwvdGQ+DQoNCjx0ZD48Zm9udCBz
aXplPSsxPldpdGggdGhpcyBwb3dlcmZ1bCBDRCwgeW91IHdpbGwgYmUgYWJsZSB0byBpbnZl
c3RpZ2F0ZQ0KeW91ciBmcmllbmRzLCBlbmVtaWVzIGFuZCBsb3ZlcnMgaW4ganVzdCBtaW51
dGVzIHVzaW5nIHRoZSBJbnRlcm5ldC4mbmJzcDsNCllvdSBjYW4gdHJhY2sgZG93biBvbGQg
ZmxhbWVzIGZyb20gY29sbGVnZSwgb3IgeW91IGNhbiBkaWcgdXAgc29tZSBkaXJ0DQpvbiB5
b3VyIGJvc3MgdG8gbWFrZSBzdXJlIHlvdSBnZXQgdGhhdCBuZXh0IHByb21vdGlvbiE8L2Zv
bnQ+PC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KDQo8cD48Zm9udCBzaXplPSsxPk9yIG1heWJl
IHlvdSB3YW50IGEgZmFrZSBkaXBsb21hIHRvIGhhbmcgb24geW91ciBiZWRyb29tPC9mb250
Pg0KPGJyPjxmb250IHNpemU9KzE+d2FsbC4mbmJzcDsgWW91J2xsIGZpbmQgYWRkcmVzc2Vz
IGZvciBjb21wYW5pZXMgdGhhdA0KbWFrZSB0aGVzZTwvZm9udD4NCjxicj48Zm9udCBzaXpl
PSsxPmRpcGxvbWFzIG9uIHRoZSBCYW5uZWQgQ0QuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0r
MT5OZWVkIHRvIGRpc2FwcGVhciBmYXN0IGFuZCBuZXZlciBsb29rIGJhY2s/Jm5ic3A7IE5v
IHByb2JsZW0hPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+VXNpbmcgdGhlIEJhbm5lZCBD
RCwgeW91IHdpbGwgbGVhcm4gaG93IHRvIGJ1aWxkIGEgY29tcGxldGVseTwvZm9udD4NCjxi
cj48Zm9udCBzaXplPSsxPm5ldyBpZGVudGl0eS48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSsx
Pk9idmlvdXNseSwgdGhlIFBvd2VycyBUaGF0IEJlIGRvbid0IHdhbnQgeW91IHRvIGhhdmUg
dGhlPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+QmFubmVkIENELiZuYnNwOyBUaGV5IGhh
dmUgdGhyZWF0ZW5lZCBtZSB3aXRoIGxhd3N1aXRzLA0KZmluZXMsPC9mb250Pg0KPGJyPjxm
b250IHNpemU9KzE+YW5kIGV2ZW4gaW1wcmlzb25tZW50IHVubGVzcyBJIHN0b3Agc2VsbGlu
ZyBpdCBpbW1lZGlhdGVseS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5CdXQgSSBmZWVs
IHRoYXQgWU9VIGhhdmUgYSBDb25zdGl0dXRpb25hbCByaWdodCB0byBhY2Nlc3M8L2ZvbnQ+
DQo8YnI+PGZvbnQgc2l6ZT0rMT50aGlzIHR5cGUgb2YgaW5mb3JtYXRpb24sIGFuZCBJIGNh
bid0IGJlIGludGltaWRhdGVkLjwvZm9udD4NCjxicj4mbmJzcDsNCjx0YWJsZSBCT1JERVI9
MCBDT0xTPTIgV0lEVEg9IjUwJSIgPg0KPHRyPg0KPHRkIFdJRFRIPSIxMDAlIj48aT48Zm9u
dCBjb2xvcj0iIzMzMzNGRiI+PGZvbnQgc2l6ZT0rMT5VbmNsZSBTYW0gYW5kIHlvdXINCmNy
ZWRpdG9ycyBhcmUgaG9ycmlmaWVkIHRoYXQgSSBhbSBzdGlsbCBzZWxsaW5nIHRoaXMgcHJv
ZHVjdCEmbmJzcDsgVGhlcmUNCm11c3QgYmUgYSBwcmljZSBvbiBteSBoZWFkITwvZm9udD48
L2ZvbnQ+PC9pPjwvdGQ+DQoNCjx0ZCBXSURUSD0iMSUiPjxpbWcgU1JDPSJodHRwOi8vY29t
cHV6b25ldXNhLmNvbS9pbWFnZXMvb3V0bGF3LmpwZyIgaGVpZ2h0PTEyOCB3aWR0aD05Mz48
L3RkPg0KPC90cj4NCjwvdGFibGU+DQoNCjxwPjxmb250IHNpemU9KzE+V2h5IGFyZSB0aGV5
IHNvIHVwc2V0PyBCZWNhdXNlIHRoaXMgQ0QgZ2l2ZXMgeW91IGZyZWVkb20uPC9mb250Pg0K
PGJyPjxmb250IHNpemU9KzE+QW5kIHlvdSBjYW4ndCBidXkgZnJlZWRvbSBhdCB5b3VyIGxv
Y2FsIFdhbG1hcnQuJm5ic3A7DQpZb3Ugd2lsbDwvZm9udD4NCjxicj48Zm9udCBzaXplPSsx
PmhhdmUgdGhlIGZyZWVkb20gdG8gYXZvaWQgY3JlZGl0b3JzLCBqdWRnbWVudHMsIGxhd3N1
aXRzLA0KSVJTPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+dGF4IGNvbGxlY3RvcnMsIGNy
aW1pbmFsIGluZGljdG1lbnRzLCB5b3VyIGdyZWVkeSBleC13aWZlDQpvcjwvZm9udD4NCjxi
cj48Zm9udCBzaXplPSsxPmV4LWh1c2JhbmQsIGFuZCBNVUNIIG1vcmUhPC9mb250Pg0KPHA+
PGZvbnQgc2l6ZT0rMT5KdXN0IGxvb2sgYXQgc29tZSBvZiB0aGUgdGhpbmdzIHlvdSBjYW4g
ZG8gd2l0aCB0aGlzIENEDQouLi48L2ZvbnQ+DQo8dWw+DQo8bGk+DQo8Yj48Zm9udCBjb2xv
cj0iIzAwMDA5OSI+U2F2ZSBodW5kcmVkcyBvciBldmVuIHRob3VzYW5kcyBvZiBkb2xsYXJz
IG9uDQp5b3VyIHRheGVzIGJ5IHVzaW5nIHRoZSBzZWNyZXQgdGF4IHRpcHMgY29udGFpbmVk
IGluIHRoaXMgcGFja2FnZS4mbmJzcDsNClRoZSBJUlMgZG9lcyBOT1Qgd2FudCB5b3UgdG8g
a25vdyB0aGVzZSBsb29waG9sZXMhPC9mb250PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9u
dCBjb2xvcj0iIzAwMDA5OSI+VHJhY2sgZG93biBmcmllbmRzIGFuZCBvbGQgZmxhbWVzIGZy
b20gdGhlIGNvbWZvcnQNCm9mIHlvdXIgb3duIGhvbWUgd2l0aCBvdXIgSW50ZXJuZXQgaW52
ZXN0aWdhdGlvbiByZXNvdXJjZXMhPC9mb250PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9u
dCBjb2xvcj0iIzAwMDA5OSI+RmluZCBvdXQgd2hlcmUgeW91ciBFWCBpcyBoaWRpbmcgdGhl
aXIgbW9uZXkgdG8NCmF2b2lkIGFsaW1vbnksIGNoaWxkIHN1cHBvcnQsIG9yIGRpdm9yY2Ug
c2V0dGxlbWVudHMuIFRoZW4gZ2V0IHlvdXIgaGFuZHMNCm9uIHRoYXQgbW9uZXkuJm5ic3A7
IEJsZWVkICdlbSBkcnkhJm5ic3A7IFByaXZhdGUgaW52ZXN0aWdhdG9ycyBjaGFyZ2UNCnRo
b3VzYW5kcyBvZiBkb2xsYXJzIGZvciB0aGlzIHNlcnZpY2UsIGJ1dCB5b3UgY2FuIGRvIGl0
IHdpdGggYSBjb21wdXRlcg0KYW5kIGFuIGludGVybmV0IGNvbmVjdGlvbiB3aGVuIHlvdSBi
dXkgdGhlIEJhbm5lZCBDRCE8L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxiPjxmb250IGNv
bG9yPSIjMDAwMDk5Ij5MZWFybiBob3cgdG8gdXNlIG9mZnNob3JlIG1vbmV5IGhhdmVucyBh
bmQgYXNzZXQNCnByb3RlY3Rpb24gdHJ1c3RzIHRvIGF2b2lkIGxhd3N1aXRzLCBqdWRnbWVu
dHMsIGFuZCBmb29sIHRoZSBtb3N0IGFnZ3Jlc3NpdmUNCnRheCBjb2xsZWN0b3IhJm5ic3A7
IElmIHlvdXIgbW9uZXkgaXMgc2l0dGluZyBpbiBhIFVTIGJhbmsgYWNjb3VudCwgeW91cg0K
ZnVuZHMgY2FuIGJlIGxldmllZCBvciBmcm96ZW4gY29tcGxldGVseSBhdCBhbnkgdGltZS4m
bmJzcDsgVGhlIFVTIGdvdmVybm1lbnQNCnVzZXMgImNpdmlsIGFzc2V0IGZvcmZlaXR1cmUi
IHRvIHN0ZWFsIGJpbGxpb25zIG9mIGRvbGxhcnMgZWFjaCB5ZWFyIGZyb20NCmhhcmQtd29y
a2luZywgbGF3IGFiaWRpbmcgY2l0aXplbnMuJm5ic3A7IEdldCB5b3VyIG1vbmV5IG91dCBv
ZiB0aGUgY291bnRyeQ0KYmVmb3JlIFVuY2xlIFNhbSBzbmF0Y2hlcyBpdCBhbGwuPC9mb250
PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+RmluZCBvdXQg
d2hlcmUgdG8gYnV5ICJmb3JiaWRkZW4gcHJvZHVjdHMiIG9uDQp0aGUgSW50ZXJuZXQuIEZ1
cnRoZXIgZWxhYm9yYXRpb24gc2hvdWxkIG5vdCBiZSBuZWNlc3Nhcnk7IGp1c3QgdXNlIHlv
dXINCmltYWdpbmF0aW9uLjwvZm9udD48L2I+PC9saT4NCg0KPGxpPg0KPGI+PGZvbnQgY29s
b3I9IiMwMDAwOTkiPkdldCBhIGJldHRlciBqb2IgYnkgcHVyY2hhc2luZyBhIGNvbGxlZ2Ug
ZGVncmVlDQooaW5jbHVkaW5nIGEgUGhkISkgZm9yIGEgdmVyeSBsb3cgZmVlLiBObyBzdHVk
eSByZXF1aXJlZCE8L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxiPjxmb250IGNvbG9yPSIj
MDAwMDk5Ij5JZiB5b3VyIEVYIGlzIGNvbWluZyBhZnRlciB5b3VyIG1vbmV5LCBzdGF5IG9u
ZQ0Kc3RlcCBhaGVhZCBvZiB0aGUgbGF3eWVycyBhbmQga2VlcCB0aGVpciBncmVlZHkgaGFu
ZHMgb2ZmIHlvdXIgbG9vdC4gRmluZA0Kb3V0IGhvdyB0byBoaWRlIHlvdXIgbW9uZXkgd2hl
cmUgaXQgd2lsbCBuZXZlciBiZSBmb3VuZC48L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxi
Pjxmb250IGNvbG9yPSIjMDAwMDk5Ij5Bdm9pZCBsZWdhbCBwcm9ibGVtcywganVkZ21lbnRz
LCBjb252aWN0aW9ucywNCmFuZCBldmVuIHByaXNvbiBzZW50ZW5jZXMgYnkgb2J0YWluaW5n
IGEgY29tcGxldGVseSBuZXcgaWRlbnRpdHkgYW5kIGRpc2FwcGVhcmluZw0Kd2l0aG91dCBh
IHRyYWNlITwvZm9udD48L2I+PC9saT4NCg0KPGxpPg0KPGI+PGZvbnQgY29sb3I9IiMwMDAw
OTkiPkVyYXNlIHlvdXIgY3JpbWluYWwgcmVjb3JkIGFuZCBvYnRhaW4gYSBjb3B5IG9mDQp5
b3VyIEZCSSBmaWxlIHVzaW5nIHRoZSBGcmVlZG9tIG9mIEluZm9ybWF0aW9uIEFjdC4mbmJz
cDsgRmluZCBvdXQgaWYgdGhlDQpnb3Zlcm5tZW50IGlzIGludmVzdGlnYXRpbmcgeW91IE5P
VyBiZWZvcmUgaXQncyB0b28gTEFURSE8L2ZvbnQ+PC9iPjwvbGk+DQo8L3VsPg0KPGZvbnQg
c2l6ZT0rMT5JZiB5b3UgaGF2ZSBiZWVuIHB1dHRpbmcgb2ZmIGJ1eWluZyBUaGUgQmFubmVk
IENELCB3aGF0IGFyZQ0KeW91PC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+d2FpdGluZyBm
b3I/Jm5ic3A7IEJpZyBCcm90aGVyIGlzIGFscmVhZHkgYnJlYXRoaW5nIGRvd24NCm15IG5l
Y2ssIHNvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+SSBjYW4ndCBrZWVwIHNlbGxpbmcg
aXQgZm9yZXZlci4mbmJzcDsgSWYgeW91IGtlZXAgd2FpdGluZw0KdG8gcGxhY2U8L2ZvbnQ+
DQo8YnI+PGZvbnQgc2l6ZT0rMT55b3VyIG9yZGVyLCB5b3UgbWF5IG5ldmVyIGZpbmQgVGhl
IEJhbm5lZCBDRCBhZ2Fpbi4mbmJzcDsNCkZvciBvbmx5PC9mb250Pg0KPGJyPjxmb250IHNp
emU9KzE+JDE5Ljk5LCB5b3Ugd2lsbCBnYWluIHZhbHVhYmxlIHBlYWNlLW9mLW1pbmQga25v
d2luZw0KaG93IHRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+c2FmZWd1YXJkIHlvdXJz
ZWxmLCB5b3VyIGZhbWlseSwgYW5kIHlvdXIgbW9uZXkuJm5ic3A7DQpXaG8gY2FuIHB1dCBh
PC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+cHJpY2Ugb24gZnJlZWRvbT8hPC9mb250Pg0K
PHA+PGk+PHU+PGZvbnQgc2l6ZT0rMT5IZXJlIGlzIGFub3RoZXIgbG9vayBhdCB0aGUgY29u
dGVudHMgb2YgdGhlIEJBTk5FRA0KQ0Q6PC9mb250PjwvdT48L2k+DQo8cD48aW1nIFNSQz0i
aHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3
aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkZpbmQgY29u
ZmlkZW50aWFsIGluZm8gb24gYW55b25lIGluIDMwIG1pbnV0ZXMgb3I8L2ZvbnQ+PC9mb250
Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmxlc3Mgb24gdGhl
IEludGVybmV0LiBZb3UnbGwgYmUNCmFibGUgdG8gdHJhY2sgZG93biB5b3VyPC9mb250Pjwv
Zm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5vbGQgZmxh
bWUsIGZpbmQgb3V0IGhvdyBtdWNoIG1vbmV5DQp5b3VyIGV4IGlzIGhpZGluZzwvZm9udD48
L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+aW4gdGhl
aXIgYmFuayBhY2NvdW50LCBvciBydW4gYQ0KYmFja2dyb3VuZCBjaGVjayBvbjwvZm9udD48
L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+cHJvZXNw
ZWN0aXZlIGNsaWVudCBvciBlbXBsb3llZS4NCkV2ZW4gZ292ZXJubWVudDwvZm9udD48L2Zv
bnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+YWdlbmNpZXMg
aGF2ZSB0cm91YmxlIG9idGFpbmluZw0KbXVjaCBvZiB0aGlzIGluZm9ybWF0aW9uLjwvZm9u
dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+WW91
IHdpbGwgaGF2ZSBhbGwgdGhlIHJlc291cmNlcw0Kb2YgYW55IHByb2Zlc3Npb25hbDwvZm9u
dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+aW52
ZXN0aWdhdG9yIHJpZ2h0IGF0IHlvdXIgZmluZ2VydGlwcw0KLSBvbiB5b3VyIGhvbWU8L2Zv
bnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmNv
bXB1dGVyITwvZm9udD48L2ZvbnQ+DQo8cD48aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVz
YS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xv
cj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkxpc3Qgb2YgY29tcGFuaWVzIHdobyB3aWxs
IGlzc3VlIHlvdSBhIGNvbGxlZ2U8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIj
NjY2NjY2Ij48Zm9udCBzaXplPSsxPmRlZ3JlZSAoaW5jbHVkaW5nIGEgUGhkLikgZm9yIGEN
CmZlZS4gTm8gc3R1ZHkgcmVxdWlyZWQhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJo
dHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdp
ZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KTGVhcm4gaG93
IHRvIGdldCBGUkVFIGNhYmxlIGFuZCBEU1MgY2hhbm5lbHMsPC9mb250PjwvZm9udD4NCjxi
cj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5pbmNsdWRpbmcgdGhlIGFk
dWx0IHN0YXRpb25zIGFuZA0KUGF5LVBlci1WaWV3ITwvZm9udD48L2ZvbnQ+DQo8cD48aW1n
IFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdo
dD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkhv
dyB0byBPYnRhaW4gTWljcm9zb2Z0IFByb2R1Y3RzIGFic29sdXRlbHk8L2ZvbnQ+PC9mb250
Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPkZSRUUsIHRoZSBz
YWZlIGFuZCBMRUdBTCB3YXkhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8v
Y29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5
Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KTGlzdCBvZiBzdXBwbGll
cnMgb2YgInF1ZXN0aW9uYWJsZSIgaXRlbXMsIHN1Y2g8L2ZvbnQ+PC9mb250Pg0KPGJyPjxm
b250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmFzIGZjYyBiYW5uZWQgY29tbXVu
aWNhdGlvbnMgZGV2aWNlcywNCnNjYW5uZXJzLDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQg
Y29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+bmlnaHQgdmlzaW9uIGdvZ2dsZXMsIHBh
c3Nwb3J0cywNCmZha2UgaWRlbnRpZmljYXRpb24sPC9mb250PjwvZm9udD4NCjxicj48Zm9u
dCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5hbmQgZXZlcnl0aGluZyBlbHNlIHRo
YXQgeW91IHdvbid0DQpmaW5kIGluIHRoZSBiYWNrPC9mb250PjwvZm9udD4NCjxicj48Zm9u
dCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5vZiBTb2xkaWVyIG9mIEZvcnR1bmUg
bWFnYXppbmUhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25l
dXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNv
bG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KRmluZCBwcm9kdWN0cyB0byByZXNlbGwg
b24gdGhlIEludGVybmV0IHdpdGggb3VyPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xv
cj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5XaG9sZXNhbGUgRGlyZWN0b3J5IGNvbnRhaW5p
bmcNCm92ZXIgMSBtaWxsaW9uPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2
NjY2NiI+PGZvbnQgc2l6ZT0rMT4odGhhdCdzIHJpZ2h0LCBvbmUgbWlsbGlvbiEpIHdob2xl
c2FsZQ0Kc291cmNlcyBmb3I8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2
NjY2Ij48Zm9udCBzaXplPSsxPmNvbXB1dGVycywgZWxlY3Ryb25pY3MsIGJlYW5pZXMsDQp0
cmVuZCBpdGVtcyw8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48
Zm9udCBzaXplPSsxPmpld2VscnksIGNhcnMsIGNvbGxlY3RpYmxlcywgYW5kDQpldmVyeXRo
aW5nIGVsc2UhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25l
dXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNv
bG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KT3ZlciAyNSBtaWxsaW9uIGVtYWlsIGFk
ZHJlc3NlcywgZnJlc2ggYW5kPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2
NjY2NiI+PGZvbnQgc2l6ZT0rMT50YXJnZXRlZCEgWW91IGNhbiB1c2UgdGhlc2UgdG8NCmNv
bnRhY3QgdGhlIHBlb3BsZTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2
NjYiPjxmb250IHNpemU9KzE+YW5kIHNlbmQgdGhlbSB5b3VyIGFkdmVydGlzZW1lbnRzLjwv
Zm9udD48L2ZvbnQ+DQo8cD48aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1h
Z2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2
NiI+PGZvbnQgc2l6ZT0rMT4NCkZpbmQgb3V0IGhvdyB0byBnZXQgYSBjb21wbGV0ZWx5IG5l
dyBpZGVudGl0eS48L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48
Zm9udCBzaXplPSsxPkRpc2FwcGVhciB3aXRob3V0IGEgdHJhY2UhPC9mb250PjwvZm9udD4N
CjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdp
ZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXpl
PSsxPg0KRmluZCBvdXQgaG93IHRvIEVSQVNFIGJhZCBjcmVkaXQgYW5kIGV2ZW48L2ZvbnQ+
PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmNyZWF0
ZSBhIHdob2xlIG5ldyBmaWxlIGluIHRoZQ0KY3JlZGl0IGJ1cmVhdSBjb21wdXRlcnMuPC9m
b250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFn
ZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2
Ij48Zm9udCBzaXplPSsxPg0KTGVhcm4gaG93IHRvIGJlYXQgdGhlIElSUy4gVGF4IHRpcHMg
Zm9yIHRoZTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250
IHNpemU9KzE+cmVzdCBvZiB1cy48L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6
Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9
MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpDb21wbGV0ZSBndWlk
ZSBvbiBob3cgdG8gY2xhaW0gcHVibGljIGxhbmQ8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250
IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPm9mZmVyZWQgYnkgdGhlIEdvdmVybm1l
bnQuIFlvdQ0KY2FuIGZpbmQgeW91cjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9
IiM2NjY2NjYiPjxmb250IHNpemU9KzE+ZHJlYW0gaG9tZSBmb3IgYSByaWRpY3Vsb3VzbHkg
bG93DQpwcmljZSBvciBidXk8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2
NjY2Ij48Zm9udCBzaXplPSsxPnByb3BlcnRpZXMgdG8gcmVzZWxsIGZvciBhIGh1Z2UNCnBy
b2ZpdCE8L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2Eu
Y29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9MTk+PGZvbnQgY29sb3I9
IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpBY2NlcHQgY2hlY2tzIGZyb20geW91ciBjdXN0
b21lcnMgYnkgZmF4LDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYi
Pjxmb250IHNpemU9KzE+cGhvbmUgYW5kIGVtYWlsIHdpdGggdGhlIGZ1bGwgd29ya2luZw0K
dmVyc2lvbiBvZjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxm
b250IHNpemU9KzE+Q2hlY2tlciBTb2Z0d2FyZSBpbmNsdWRlZCE8L2ZvbnQ+PC9mb250Pg0K
PHA+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lm
IiBoZWlnaHQ9MTkgd2lkdGg9MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9
KzE+DQpCdXNpbmVzcyBzb2Z0d2FyZSB0byBoZWxwIHlvdSBydW4geW91ciBzbWFsbDwvZm9u
dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+YnVz
aW5lc3MsIGluY2x1ZGluZyBsYWJlbCBtYWtlcg0Kc29mdHdhcmUsIG1vbmV5PC9mb250Pjwv
Zm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5tYW5hZ2Vt
ZW50IHNvZnR3YXJlLCBJUlMgZm9yZ2l2ZW5lc3MNCnByb2dyYW0sPC9mb250PjwvZm9udD4N
Cjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5kYXRhYmFzZSBzb2Z0
d2FyZSwgYW5kIG11Y2ggbW9yZS48L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6
Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9
MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpBIGh1Z2UgY29sbGVj
dGlvbiBvZiBzY3JlZW5zYXZlcnMsIGdyYXBoaWNzLDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZv
bnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+Y2xpcGFydCwgYW5kIGRlc2t0b3Ag
dGhlbWVzIHRvDQpzcGljZSB1cCB5b3VyIGNvbXB1dGVyLjwvZm9udD48L2ZvbnQ+DQo8cD48
aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhl
aWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4N
Ck1VQ0gsIE1VQ0ggTU9SRSB0aGF0IHdlIGRvbid0IGhhdmUgcm9vbSB0byBsaXN0ITwvZm9u
dD48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSsxPldlIGFyZSBzbyBjb25maWRlbnQgdGhhdCB5
b3Ugd2lsbCBsb3ZlIHRoaXMgQ0QgdGhhdCB3ZTwvZm9udD4NCjxicj48Zm9udCBzaXplPSsx
Pm9mZmVyIGEgZnVsbCAzMC1kYXksIG5vIHF1ZXN0aW9ucyBhc2tlZCBtb25leS1iYWNrPC9m
b250Pg0KPGJyPjxmb250IHNpemU9KzE+Z3VhcmFudGVlLiBUbyBvcmRlciB0aGUgIkJhbm5l
ZCBDRCIgcmlnaHQgbm93IGZvciB0aGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5zdXBl
ciBsb3cgcHJpY2Ugb2Ygb25seSAkMTkuOTksIGp1c3QgY2xpY2sgb24gdGhlIGxpbms8L2Zv
bnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5iZWxvdyB0byBwYXkgd2l0aCBhIFZpc2Egb3IgTWFz
dGVyY2FyZDo8L2ZvbnQ+DQo8YnI+Jm5ic3A7DQo8dGFibGUgQk9SREVSPTAgQ09MUz0yIFdJ
RFRIPSI1MCUiID4NCjx0cj4NCjx0ZD48Zm9udCBzaXplPSsyPjxhIGhyZWY9Imh0dHA6Ly93
d3cuY29tcHV6b25ldXNhLmNvbS9jY3BheW1lbnQvYmFubmVkY2Q3Mi5odG0iPk9yZGVyDQpO
b3chPC9hPjwvZm9udD48L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxpbWcgU1JDPSJodHRwOi8v
Y29tcHV6b25ldXNhLmNvbS9pbWFnZXMvZ3VhcmFudGVlLmdpZiIgaGVpZ2h0PTk2IHdpZHRo
PTk1PjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KDQo8cD5PciB5b3UgbWF5
IHBheSB3aXRoIGNhc2gsIGNoZWNrIG9yIG1vbmV5IG9yZGVyIGJ5IHByaW50aW5nIHRoZSBv
cmRlcg0KPGJyPmZvcm0gYmVsb3cgYW5kIHNlbmRpbmcgaXQgd2l0aCB5b3VyIHBheW1lbnQu
DQo8cD48Yj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIENVVCBIRVJFIC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tPC9iPg0KPHA+UHJvZHVjdDogIlRoZSBCYW5uZWQgQ0QiDQo8YnI+UHJp
Y2U6ICQxOS45OSArICQ0LjAxIHNoaXBwaW5nL2hhbmRsaW5nDQo8cD5IT1cgVE8gT1JERVIg
QlkgTUFJTDogUHJpbnQgb3V0IHRoaXMgb3JkZXIgZm9ybSBhbmQgc2VuZCBjYXNoLA0KPGJy
PnBlcnNvbmFsIGNoZWNrLCBtb25leSBvcmRlciBvciBjYXNoaWVyJ3MgY2hlY2sgdG8gdGhl
IGFkZHJlc3MgbGlzdGVkDQpiZWxvdzoNCjxwPlF1aWtzaWx2ZXIgRW50ZXJwcmlzZXMgSW5j
Lg0KPGJyPjM3OTIgQnJvYWR3YXkgIzM5OA0KPGJyPk5ldyBZb3JrLCBOWSAxMDAzMg0KPHA+
WW91ciBTaGlwcGluZyBJbmZvcm1hdGlvbjoNCjxwPllvdXIgTmFtZV9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPllvdXIgQWRkcmVzc19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPllvdXIgQ2l0eV9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPlN0YXRl
IC8gWmlwX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJy
PlBob25lICM6IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KPGJyPihGb3IgcHJvYmxlbXMgd2l0aCB5b3VyIG9yZGVyIG9ubHkuIE5vIHNhbGVzbWVu
IHdpbGwgY2FsbC4pDQo8cD5FbWFpbCBBZGRyZXNzX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KPHA+UGxlYXNlIG5vdGUgdGhhdCBtYWlsLWluIG9yZGVycyBt
YXkgYmUgZGVsYXllZCAyLTQgd2Vla3MuDQo8cD5bIF0gSSBhbSBlbmNsb3NpbmcgYSBjaGVj
ayBvciBtb25leSBvcmRlciBmb3IgJDI0LjAwDQo8cD5bIF0gSSBhbSBtYWlsaW5nIG15IGNy
ZWRpdCBjYXJkIG51bWJlci4gKE5vdGUgeW91ciBjYXJkIHdpbGwgYmUgY2hhcmdlZA0KZm9y
ICQyNC4wMCkNCjxwPklmIHBheWluZyBieSBjcmVkaXQgY2FyZCwgcGxlYXNlIGZpbGwgaW4g
dGhlIGluZm9ybWF0aW9uIGJlbG93Og0KPHA+Q3JlZGl0IENhcmQgTnVtYmVyOl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQo8YnI+RXhwaXJhdGlvbiBEYXRlOl9fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KPGJyPlNpZ25hdHVyZTpfX19fX19fX19fX19fX19fX19f
X19fX19fDQo8YnI+RGF0ZTpfX19fX19fX19fX19fX19fX19fXw0KPHA+Tk9URTogVGhpcyBD
RCBpcyBmb3IgaW5mb3JtYXRpb25hbCwgZWR1Y2F0aW9uYWwsIG9yDQo8YnI+ZW50ZXJ0YWlu
bWVudCBwdXJwb3NlcyBvbmx5LiZuYnNwOyBTb21lIG9mIHRoZSBhY3Rpdml0aWVzDQo8YnI+
ZGVzY3JpYmVkIG9uIHRoaXMgQ0QgbWF5IGJlIGlsbGVnYWwgaWYgY2FycmllZCBvdXQuDQo8
YnI+VGhpcyBDRCBjb250YWlucyBsaW5rcyBhbmQgYWRkcmVzc2VzIG9mIGNvbXBhbmllcw0K
PGJyPmFuZCBpbmRpdmlkdWFscyB3aGljaCBwcm9kdWNlIHZhcmlvdXMgcHJvZHVjdHMsIG9y
DQo8YnI+b2ZmZXIgdmFyaW91cyBzZXJ2aWNlcywgd2hpY2ggbWF5IGJlIGlsbGVnYWwgaW4g
eW91cg0KPGJyPmNvdW50cnksIHN0YXRlLCBvciBjaXR5LiZuYnNwOyBIb3dldmVyLCBpdCBp
cyBwZXJmZWN0bHkNCjxicj5MRUdBTCB0byBwdXJjaGFzZSBhbmQgcG9zc2VzcyB0aGUgQmFu
bmVkIENEIGluIHRoZQ0KPGJyPlVuaXRlZCBTdGF0ZXMgb2YgQW1lcmljYS4mbmJzcDsgQ29u
dGFpbnMgYXBwcm94aW1hdGVseQ0KPGJyPjEwMCBtZWdzIG9mIGluZm9ybWF0aW9uLg0KPHA+
U2hpcHBpbmcgb3V0c2lkZSBVU0EgYWRkICQxMC4wMA0KPHA+KioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCjxicj5Zb3UgYXJl
IHJlY2lldmluZyBhbiB1bnNvbGljaXRlZCBjb21tZXJjaWFsIGVtYWlsIGZyb20NCjxicj5R
dWlrc2lsdmVyIEVudGVycHJpc2VzIEluYy4mbmJzcDsgV2UgcmVjb2duaXplIHRoYXQgeW91
IG1heQ0KPGJyPm5vdCB3aXNoIHRvIHJlY2lldmUgc3VjaCBlbWFpbHMgaW4gdGhlIGZ1dHVy
ZSwgYW5kIHdlDQo8YnI+aGF2ZSBwcm92aWRlZCBhIGxpbmsgdG8gYXV0b21hdGljYWxseSBh
bmQgaW5zdGFudGx5DQo8YnI+cmVtb3ZlIHlvdXJzZWxmOiA8YSBocmVmPSJodHRwOi8vd3d3
LmNvbXB1em9uZXVzYS5jb20vcmVtb3ZlLmh0bSI+UkVNT1ZFPC9hPg0KPGJyPlRoaXMgbWVz
c2FnZSBpcyBiZWluZyBzZW50IHRvIHlvdSBpbiBjb21wbGlhbmNlIHdpdGgNCjxicj5mZWRl
cmFsIGd1aWRlbGluZXMgZ292ZXJuaW5nIHRoZSB0cmFuc21pc3Npb24gb2YNCjxicj51bnNv
bGljaXRlZCBjb21tZXJjaWFsIGVtYWlsLCBpbmNsdWRpbmcgdGhlIHByb3Zpc2lvbiBvZg0K
PGJyPmNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIG91ciBjb21wYW55IHdpdGhpbiB0aGlzIGVt
YWlsLCBhDQo8YnI+dmFsaWQgcmV0dXJuIGVtYWlsIGFkZHJlc3MsIGFuZCBhIHdheSBmb3Ig
Y3VzdG9tZXJzDQo8YnI+dG8gcmVtb3ZlIHRoZW1zZWx2ZXMuJm5ic3A7IFBsZWFzZSBub3Rl
LCBob3dldmVyLCB0aGF0IG91cg0KPGJyPmVtYWlsIGFkZHJlc3Mgd2FzIHZhbGlkIGF0IHRo
ZSB0aW1lIG9mIHNlbmRpbmcsIGJ1dCBtYXkNCjxicj5iZSBjYW5jZWxsZWQgYnkgdGhlIElT
UCBzaG9ydGx5IHRoZXJlYWZ0ZXIgZHVlIHRvIG91cg0KPGJyPnVzZSBvZiB1bnNvbGljaXRl
ZCBlbWFpbC4mbmJzcDsgWW91IGNhbiByZWFkIGFib3V0IHRoZSB2YXJpb3VzDQo8YnI+bGF3
cyBnb3Zlcm5pbmcgdW5zb2xpY2l0ZWQgZW1haWw6IGh0dHA6Ly9zcGFtbGF3cy5jb20NCjxi
cj4iVW5zb2xpY2l0ZWQgY29tbWVyY2lhbCBlbGVjdHJvbmljIG1haWwgY2FuIGJlIGFuIGlt
cG9ydGFudA0KPGJyPm1lY2hhbmlzbSB0aHJvdWdoIHdoaWNoIGJ1c2luZXNzZXMgYWR2ZXJ0
aXNlIGFuZCBhdHRyYWN0DQo8YnI+Y3VzdG9tZXJzIGluIHRoZSBvbmxpbmUgZW52aXJvbm1l
bnQuIiZuYnNwOyAtLSBVLlMuIENvbmdyZXNzLA0KPGJyPkguUi4gMTA2dGggQ09OR1JFU1Mg
MmQgU2Vzc2lvbiBILiBSLiAzMTEzIFNlYy4gMiAoYSkzIEp1bHkNCjxicj4xOSwgMjAwMCBo
dHRwOi8vd3d3LnNwYW1sYXdzLmNvbS9mZWRlcmFsL2hyMzExMy5odG1sDQo8YnI+KioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN
Cjxicj4mbmJzcDsNCjxicj4mbmJzcDsNCjwvYm9keT4NCjwvaHRtbD4NCg==

------=_NextPart_000_001__20796735_62094.25--



From owner-seamoby@diameter.org  Mon Jan 29 23:03:00 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16682
	for <seamoby-archive@odin.ietf.org>; Mon, 29 Jan 2001 23:03:00 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0U2t2Y08155
	for seamoby-list; Mon, 29 Jan 2001 18:55:02 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0U2sxo08145
	for <seamoby@diameter.org>; Mon, 29 Jan 2001 18:54:59 -0800
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20274;
	Mon, 29 Jan 2001 18:02:50 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA18549;
	Mon, 29 Jan 2001 18:02:49 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id SAA22287;
	Mon, 29 Jan 2001 18:02:42 -0800 (PST)
Date: Mon, 29 Jan 2001 18:02:43 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: Re: [seamoby] problem statement and rechartering (was: Re: The   right protocol was  RE: [seamoby-mm] ietf-seamoby-mm-pr   oblem-00-a1.txt)
To: Michael Thomas <mat@cisco.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        "Dana L. Blair" <dblair@cisco.com>,
        Kulwinder Atwal <kulwinder.atwal@zucotto.com>, john.loughney@nokia.com,
        Pat.Calhoun@eng.sun.com, charliep@iprg.nokia.com,
        seamoby-mm@cdma-2000.org,
        "'seamoby@diameter.org'" <seamoby@diameter.org>
In-Reply-To: "Your message with ID" <14966.4987.820692.152021@thomasm-u1.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.980820163.8584.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

>    Actually, that's a feature not a bug. I cannot fathom why
>    people think that three dozen application layer crypto 
>    schemes is better than one IP layer scheme. Unless they
>    think that that means that they can not build crypto 
>    into their boxes at all.

To finish up on our conversation on how IPSec identify a security association
(where I stated it was the combination of both the SPI AND the source IP
address), here is a quote from RFC 2402:

"2.4  Security Parameters Index (SPI)

   The SPI is an arbitrary 32-bit value that, in combination with the
   destination IP address and security protocol (AH), uniquely
   identifies the Security Association for this datagram.  The set of
   SPI values in the range 1 through 255 are reserved by the Internet
   Assigned Numbers Authority (IANA) for future use; a reserved SPI
   value will not normally be assigned by IANA unless the use of the
   assigned SPI value is specified in an RFC.  It is ordinarily selected
   by the destination system upon establishment of an SA (see the
   Security Architecture document for more details)."

So, a move WILL require a full IKE phase 1 AND 2 exchange. Again, far from
fast (especially given that it is over the air).

Now that's said, it certainly makes MM MUCH more attractive in v6 networks,
where a change of care of address could be reduced significantly.

> 
>    IPsec is a v6 MUST and is being widely back implemented
>    into v4. Can we move on?

Sure, but where?

:)

PatC



From owner-seamoby@diameter.org  Mon Jan 29 23:03:46 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16706
	for <seamoby-archive@odin.ietf.org>; Mon, 29 Jan 2001 23:03:46 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0U2wZg08171
	for seamoby-list; Mon, 29 Jan 2001 18:58:35 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0U2wVo08163
	for <seamoby@diameter.org>; Mon, 29 Jan 2001 18:58:31 -0800
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA21985;
	Mon, 29 Jan 2001 18:06:23 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA19077;
	Mon, 29 Jan 2001 18:06:22 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id SAA22377;
	Mon, 29 Jan 2001 18:06:17 -0800 (PST)
Date: Mon, 29 Jan 2001 18:06:18 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: Re: [seamoby] problem statement and rechartering (was: Re: The  right protocol was  RE: [seamoby-mm] ietf-seamoby-mm-pr  oblem-00-a1.txt)
To: Michael Thomas <mat@cisco.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        "Dana L. Blair" <dblair@cisco.com>,
        Kulwinder Atwal <kulwinder.atwal@zucotto.com>, john.loughney@nokia.com,
        Pat.Calhoun@eng.sun.com, charliep@iprg.nokia.com,
        seamoby-mm@cdma-2000.org,
        "'seamoby@diameter.org'" <seamoby@diameter.org>
In-Reply-To: "Your message with ID" <14966.2961.846987.801210@thomasm-u1.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.980820378.28256.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk


>    Binding Updates have such a fundamental
>    security hole -- every would-be traffic snooper
>    would be given the world's best tool ever -- I
>    cannot imagine who in their right mind would
>    deploy such a thing, big happy family or not.

Hence it's reliance on IPSec.

> 
>    I don't understand why it wouldn't? Can
>    somebody restate the reason?

An AP, say running IAPP, does not have a way to signal a foreign agent on the
local subnet about a handoff. One method that was discussed at the IETF was
for the FA to snoop IAPP traffic, but this is ugly. I am sure that a better
mechanism could be created.

>    Before we become despondent and looking for windows in
>    tall buildings, it should be noted that this is a 
>    consideration only if key negotiation is in the 
>    critical path of a handoff. As far as I can tell, it
>    doesn't seem to be in MIP fast handoffs, and I don't
>    think that anything we're doing would change that.
>    If we end up going down a path leads us that
>    direction, we can be pretty sure that it is the
>    wrong one.

See my previous e-mail. Key neg is in the critical path.

Hey, there's a window up in them there buildings....

PatC



From owner-seamoby@diameter.org  Tue Jan 30 05:36:45 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02951
	for <seamoby-archive@odin.ietf.org>; Tue, 30 Jan 2001 05:36:44 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0U9aWq08454
	for seamoby-list; Tue, 30 Jan 2001 01:36:32 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0U9aSo08445
	for <seamoby@diameter.org>; Tue, 30 Jan 2001 01:36:29 -0800
Received: from centralmail1.Central.Sun.COM ([129.147.62.10])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA07516;
	Tue, 30 Jan 2001 00:44:18 -0800 (PST)
Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144])
	by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id BAA28048;
	Tue, 30 Jan 2001 01:44:17 -0700 (MST)
Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4)
	id CAA29678; Tue, 30 Jan 2001 02:02:09 -0700
Message-Id: <5.0.0.25.1.20010130002919.00a6bd50@localhost>
X-Sender: kempf@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 30 Jan 2001 00:41:49 -0800
To: "Dana L. Blair" <dblair@cisco.com>,
        Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        Kulwinder Atwal <kulwinder.atwal@zucotto.com>
From: James Kempf <james.kempf@sun.com>
Subject: Re: [seamoby] problem statement and rechartering (was: Re: The
  right protocol was  RE: [seamoby-mm] ietf-seamoby-mm-pr
  oblem-00-a1.txt)
Cc: "'Pat Calhoun'" <pcalhoun@nasnfs.eng.sun.com>, john.loughney@nokia.com,
        Pat.Calhoun@eng.sun.com, charliep@iprg.nokia.com,
        seamoby-mm@cdma-2000.org,
        "'seamoby@diameter.org'" <seamoby@diameter.org>
In-Reply-To: <4.1.20010129172447.009182f0@flipper.cisco.com>
References: <Roam.SIMC.2.0.6.980775038.3260.pcalhoun@nasnfs>
 <"Your message with ID" <FC0292EA4D13D34EA2E5FC728D70A8E3078BD0@NEPTUNE.zucotto.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-seamoby@diameter.org
Precedence: bulk

Dana,

 >We know that Mobile IP requires tunneling and authentication (IPSEC).  Could
>we somehow insert into the problem statement that we need a mobility solution
>where Mobile Device and Server are within the same trusted domain and address
>space, therefore tunneling and IPSEC are not needed.    I don't think Mobile
>IP is addressing mobility solutions that don't require tunnels and 
>authentication.
>The best example I can think of is enterprise mobility.
>
>Problem statement text:
>Current mobility standards require tunneling and authentication.  In a 
>trusted
>domain where both IP endpoints already trust each other and share the
>same address space, tunneling and authentication are not needed.  A good
>example is site local addressing in IPv6.

I think a more basic assumption made by mobile IP is that the mobile node
has a "home" agent somewhere. This assumption comes out of the historical
IP situation where a wired host is tied down to a plug in the wall. The natural
extension from that is that the mobile has some natural "home" subnet.
Getting rid of this assumption would remove the need for tunnelling and 
authentication, but there are consequences.

There are lots of innovations one could make in this area, but I'm afraid that
mobile IP has a certain amount of deployment momentum at the moment. It
would be really a shame, when mobile IP is right at the cusp of becoming real
after 10 years of hard work, to have energy diverted by a new protocol. 
Maybe the right solution for exploring these new protocol possibilities is 
to start up an IRTF
activity for exploring new mobility protocols. This would give Phil, 
AndrewC, and
others that want to look into these research areas a venue to discuss them, 
with
a recommendation to come to IETF when the implications are clear. I would 
certainly like to be involved in such an effort, but at the same time, I 
want to make sure
that IETF speaks with one voice (as much as that is possible) when we 
confront 3GPP and others that have some reservations about deploying mobile 
IP. I would
rather see energy devoted to fixing the holes in mobile IP that are currently
hindering deployability.

                         jak




From owner-seamoby@diameter.org  Tue Jan 30 05:38:38 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02962
	for <seamoby-archive@odin.ietf.org>; Tue, 30 Jan 2001 05:38:37 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0U9hwP08468
	for seamoby-list; Tue, 30 Jan 2001 01:43:58 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0U9huo08463
	for <seamoby@diameter.org>; Tue, 30 Jan 2001 01:43:56 -0800
Received: from centralmail1.Central.Sun.COM ([129.147.62.10])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAB14241;
	Tue, 30 Jan 2001 00:51:52 -0800 (PST)
Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144])
	by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id BAA29342;
	Tue, 30 Jan 2001 01:51:52 -0700 (MST)
Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4)
	id CAA29716; Tue, 30 Jan 2001 02:09:47 -0700
Message-Id: <5.0.0.25.1.20010130004512.009f0960@localhost>
X-Sender: kempf@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 30 Jan 2001 00:49:28 -0800
To: "Dana L. Blair" <dblair@cisco.com>,
        Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        "Dana L. Blair" <dblair@cisco.com>
From: James Kempf <james.kempf@sun.com>
Subject: Re: [seamoby] problem statement and rechartering (was: Re: The
  right protocol was  RE: [seamoby-mm] ietf-seamoby-mm-pr 
  oblem-00-a1.txt)
Cc: "'seamoby@diameter.org'" <seamoby@diameter.org>
In-Reply-To: <4.1.20010129180921.009c4600@flipper.cisco.com>
References: <Roam.SIMC.2.0.6.980810881.15374.pcalhoun@nasnfs>
 <"Your message with ID" <4.1.20010129172447.009182f0@flipper.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-seamoby@diameter.org
Precedence: bulk

At 06:13 PM 1/29/01 -0500, Dana L. Blair wrote:

> >BTW, some additional information that I've found out today is that the 
> v6 fast
> >handoff requires a secured binding update between the mobile and the new
> >access router. I can tell you right now that a full IKE negotiation is far
> >from what I call fast :(
>
>The IPSEC requirement is a big issue in my opinion.  I think it would be 
>valuable
>to define a mobility protocol (maybe just changes to Mobile IP) which did not
>require IPSEC.

There are other consequences. HMIPv6 exposes the Local Care-of Address for
the same reason. Thus, MIPv6 derives no hierarchy hiding benefits from HMIP.
Also, I suspect that the need for authentication will make network assisted 
handoff
during dormant mode difficult, because the access routers need to do the 
binding
update to the home agent while the mobile is in dormant mode.

                 jak



From owner-seamoby@diameter.org  Tue Jan 30 06:25:14 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03211
	for <seamoby-archive@odin.ietf.org>; Tue, 30 Jan 2001 06:25:14 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0UAOiQ08500
	for seamoby-list; Tue, 30 Jan 2001 02:24:44 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0UAOgo08495
	for <seamoby@diameter.org>; Tue, 30 Jan 2001 02:24:42 -0800
Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0U9Wds18167
	for <seamoby@diameter.org>; Tue, 30 Jan 2001 11:32:39 +0200 (EET)
Received: from esebh01nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T516be28279ac158f22148@esvir02nok.nokia.com>;
 Tue, 30 Jan 2001 11:32:37 +0200
Received: by esebh01nok with Internet Mail Service (5.5.2652.78)
	id <D4C805WX>; Tue, 30 Jan 2001 11:32:37 +0200
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680A8A5@eseis04nok>
From: john.loughney@nokia.com
To: james.kempf@sun.com
Cc: seamoby@diameter.org
Subject: [seamoby] HMIPv6 & regional registrations
Date: Tue, 30 Jan 2001 11:32:36 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

James,

> There are other consequences. HMIPv6 exposes the Local 
> Care-of Address for the same reason. Thus, MIPv6 derives 
> no hierarchy hiding benefits from HMIP. Also, I suspect that 
> the need for authentication will make network assisted 
> handoff during dormant mode difficult, because the access routers 
> need to do the  binding update to the home agent while the mobile 
> is in dormant mode.

Is this the case for both the hierarchical MIPv6 & MIPv6 with
regional registrations?  If so, this could then be part of the
problem we wish to solve would be some sort of localized
mobility which doesn't encounter the same problems.

br,
John


From owner-seamoby@diameter.org  Tue Jan 30 06:50:12 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03356
	for <seamoby-archive@odin.ietf.org>; Tue, 30 Jan 2001 06:50:12 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0UAokL08524
	for seamoby-list; Tue, 30 Jan 2001 02:50:46 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0UAoio08519
	for <seamoby@diameter.org>; Tue, 30 Jan 2001 02:50:44 -0800
Received: from centralmail1.Central.Sun.COM ([129.147.62.10])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA26134;
	Tue, 30 Jan 2001 01:58:36 -0800 (PST)
Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144])
	by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id CAA05090;
	Tue, 30 Jan 2001 02:58:35 -0700 (MST)
Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4)
	id DAA00230; Tue, 30 Jan 2001 03:16:31 -0700
Message-Id: <5.0.0.25.1.20010130015525.00a0a810@localhost>
X-Sender: kempf@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 30 Jan 2001 01:56:07 -0800
To: john.loughney@nokia.com
From: James Kempf <james.kempf@sun.com>
Subject: [seamoby] Re: HMIPv6 & regional registrations
Cc: seamoby@diameter.org
In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680A8A5@eseis04nok>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-seamoby@diameter.org
Precedence: bulk

John,

At 11:32 AM 1/30/01 +0200, john.loughney@nokia.com wrote:
>James,
>
> > There are other consequences. HMIPv6 exposes the Local
> > Care-of Address for the same reason. Thus, MIPv6 derives
> > no hierarchy hiding benefits from HMIP. Also, I suspect that
> > the need for authentication will make network assisted
> > handoff during dormant mode difficult, because the access routers
> > need to do the  binding update to the home agent while the mobile
> > is in dormant mode.
>
>Is this the case for both the hierarchical MIPv6 & MIPv6 with
>regional registrations?  If so, this could then be part of the
>problem we wish to solve would be some sort of localized
>mobility which doesn't encounter the same problems.
>
>br,
>John

I'm not sure about MIPv6 with regional registrations, but it certainly is 
true of
regular mode HMIPv6.

                 jak



From owner-seamoby@diameter.org  Tue Jan 30 07:38:37 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04225
	for <seamoby-archive@odin.ietf.org>; Tue, 30 Jan 2001 07:38:37 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0UBchu08567
	for seamoby-list; Tue, 30 Jan 2001 03:38:43 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0UBbMo08562
	for <seamoby@diameter.org>; Tue, 30 Jan 2001 03:37:22 -0800
Received: from glandon.inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id LAA24301;
	Tue, 30 Jan 2001 11:45:17 +0100 (MET)
Received: from inrialpes.fr (localhost [127.0.0.1])
	by glandon.inrialpes.fr (8.8.7/8.8.5) with ESMTP id LAA19291;
	Tue, 30 Jan 2001 11:45:17 +0100 (MET)
Message-ID: <3A769B3D.4E97EDBE@inrialpes.fr>
Date: Tue, 30 Jan 2001 11:45:17 +0100
From: Claude Castelluccia <claude.castelluccia@inrialpes.fr>
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf <james.kempf@sun.com>
CC: "Dana L. Blair" <dblair@cisco.com>,
        Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        "'seamoby@diameter.org'" <seamoby@diameter.org>
Subject: Re: [seamoby] problem statement and rechartering (was: Re: Theright 
 protocol was  RE: [seamoby-mm] ietf-seamoby-mm-pr oblem-00-a1.txt)
References: <Roam.SIMC.2.0.6.980810881.15374.pcalhoun@nasnfs>
	 <"Your message with ID" <4.1.20010129172447.009182f0@flipper.cisco.com> <5.0.0.25.1.20010130004512.009f0960@localhost>
Content-Type: multipart/alternative;
 boundary="------------5CCBB490D7CDB7D98ABDC6C2"
Sender: owner-seamoby@diameter.org
Precedence: bulk


--------------5CCBB490D7CDB7D98ABDC6C2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



James Kempf wrote:

> At 06:13 PM 1/29/01 -0500, Dana L. Blair wrote:
>
> > >BTW, some additional information that I've found out today is that the
> > v6 fast
> > >handoff requires a secured binding update between the mobile and the new
> > >access router. I can tell you right now that a full IKE negotiation is far
> > >from what I call fast :(
> >
> >The IPSEC requirement is a big issue in my opinion.  I think it would be
> >valuable
> >to define a mobility protocol (maybe just changes to Mobile IP) which did not
> >require IPSEC.
>
> There are other consequences. HMIPv6 exposes the Local Care-of Address for
> the same reason. Thus, MIPv6 derives no hierarchy hiding benefits from HMIP.

this is not true.. in HMIPv6, a MN can hide its Local CoA  from its CNs if
necessary...

Claude.

>
> Also, I suspect that the need for authentication will make network assisted
> handoff
> during dormant mode difficult, because the access routers need to do the
> binding
> update to the home agent while the mobile is in dormant mode.
>
>                  jak

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------5CCBB490D7CDB7D98ABDC6C2
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<p>James Kempf wrote:
<blockquote TYPE=CITE>At 06:13 PM 1/29/01 -0500, Dana L. Blair wrote:
<p>> >BTW, some additional information that I've found out today is that
the
<br>> v6 fast
<br>> >handoff requires a secured binding update between the mobile and
the new
<br>> >access router. I can tell you right now that a full IKE negotiation
is far
<br>> >from what I call fast :(
<br>>
<br>>The IPSEC requirement is a big issue in my opinion.&nbsp; I think
it would be
<br>>valuable
<br>>to define a mobility protocol (maybe just changes to Mobile IP) which
did not
<br>>require IPSEC.
<p>There are other consequences. HMIPv6 exposes the Local Care-of Address
for
<br>the same reason. Thus, MIPv6 derives no hierarchy hiding benefits from
HMIP.</blockquote>

<p><br>this is not true.. in HMIPv6, a MN can hide its Local CoA&nbsp;
from its CNs&nbsp;if necessary...
<p>Claude.
<blockquote TYPE=CITE>&nbsp;
<br>Also, I suspect that the need for authentication will make network
assisted
<br>handoff
<br>during dormant mode difficult, because the access routers need to do
the
<br>binding
<br>update to the home agent while the mobile is in dormant mode.
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
jak</blockquote>

<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------5CCBB490D7CDB7D98ABDC6C2--



From owner-seamoby@diameter.org  Tue Jan 30 08:57:38 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06255
	for <seamoby-archive@odin.ietf.org>; Tue, 30 Jan 2001 08:57:38 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0UChkc08845
	for seamoby-list; Tue, 30 Jan 2001 04:43:46 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0UChgo08840
	for <seamoby@diameter.org>; Tue, 30 Jan 2001 04:43:42 -0800
Received: from glandon.inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id MAA27295;
	Tue, 30 Jan 2001 12:51:39 +0100 (MET)
Received: from inrialpes.fr (localhost [127.0.0.1])
	by glandon.inrialpes.fr (8.8.7/8.8.5) with ESMTP id MAA19333;
	Tue, 30 Jan 2001 12:51:39 +0100 (MET)
Message-ID: <3A76AACB.B3467D45@inrialpes.fr>
Date: Tue, 30 Jan 2001 12:51:39 +0100
From: Claude Castelluccia <claude.castelluccia@inrialpes.fr>
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf <james.kempf@sun.com>
CC: john.loughney@nokia.com, seamoby@diameter.org
Subject: Re: [seamoby] Re: HMIPv6 & regional registrations
References: <5.0.0.25.1.20010130015525.00a0a810@localhost>
Content-Type: multipart/alternative;
 boundary="------------C9BCDB3EDCC9C77BDB6161F1"
Sender: owner-seamoby@diameter.org
Precedence: bulk


--------------C9BCDB3EDCC9C77BDB6161F1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

James Kempf wrote:

> John,
>
> At 11:32 AM 1/30/01 +0200, john.loughney@nokia.com wrote:
> >James,
> >
> > > There are other consequences. HMIPv6 exposes the Local
> > > Care-of Address for the same reason. Thus, MIPv6 derives
> > > no hierarchy hiding benefits from HMIP. Also, I suspect that
> > > the need for authentication will make network assisted
> > > handoff during dormant mode difficult, because the access routers
> > > need to do the  binding update to the home agent while the mobile
> > > is in dormant mode.
> >
> >Is this the case for both the hierarchical MIPv6 & MIPv6 with
> >regional registrations?  If so, this could then be part of the
> >problem we wish to solve would be some sort of localized
> >mobility which doesn't encounter the same problems.
> >
> >br,
> >John
>
> I'm not sure about MIPv6 with regional registrations, but it certainly is
> true of
> regular mode HMIPv6.
>

James,

Could you explain me why this is true for HMIPv6?
I am very interested ;-)....

Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------C9BCDB3EDCC9C77BDB6161F1
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
James Kempf wrote:
<blockquote TYPE=CITE>John,
<p>At 11:32 AM 1/30/01 +0200, john.loughney@nokia.com wrote:
<br>>James,
<br>>
<br>> > There are other consequences. HMIPv6 exposes the Local
<br>> > Care-of Address for the same reason. Thus, MIPv6 derives
<br>> > no hierarchy hiding benefits from HMIP. Also, I suspect that
<br>> > the need for authentication will make network assisted
<br>> > handoff during dormant mode difficult, because the access routers
<br>> > need to do the&nbsp; binding update to the home agent while the
mobile
<br>> > is in dormant mode.
<br>>
<br>>Is this the case for both the hierarchical MIPv6 &amp; MIPv6 with
<br>>regional registrations?&nbsp; If so, this could then be part of the
<br>>problem we wish to solve would be some sort of localized
<br>>mobility which doesn't encounter the same problems.
<br>>
<br>>br,
<br>>John
<p>I'm not sure about MIPv6 with regional registrations, but it certainly
is
<br>true of
<br>regular mode HMIPv6.
<br>&nbsp;</blockquote>

<p><br>James,
<p>Could you explain me why this is true for HMIPv6?
<br>I am very interested ;-)....
<p>Claude.
<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------C9BCDB3EDCC9C77BDB6161F1--



From owner-seamoby@diameter.org  Tue Jan 30 10:20:21 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09986
	for <seamoby-archive@odin.ietf.org>; Tue, 30 Jan 2001 10:20:21 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0UEGOm08898
	for seamoby-list; Tue, 30 Jan 2001 06:16:24 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0UEGLo08893
	for <seamoby@diameter.org>; Tue, 30 Jan 2001 06:16:21 -0800
Received: from centralmail1.Central.Sun.COM ([129.147.62.10])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA10262;
	Tue, 30 Jan 2001 05:24:07 -0800 (PST)
Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144])
	by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id GAA01696;
	Tue, 30 Jan 2001 06:24:05 -0700 (MST)
Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4)
	id GAA02288; Tue, 30 Jan 2001 06:42:01 -0700
Message-Id: <5.0.0.25.1.20010130051911.00a12170@localhost>
X-Sender: kempf@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 30 Jan 2001 05:21:40 -0800
To: Claude Castelluccia <claude.castelluccia@inrialpes.fr>
From: James Kempf <james.kempf@sun.com>
Subject: Re: [seamoby] problem statement and rechartering (was: Re:
  Theright  protocol was  RE: [seamoby-mm] ietf-seamoby-mm-pr
  oblem-00-a1.txt)
Cc: "Dana L. Blair" <dblair@cisco.com>,
        Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        "'seamoby@diameter.org'" <seamoby@diameter.org>
In-Reply-To: <3A769B3D.4E97EDBE@inrialpes.fr>
References: <Roam.SIMC.2.0.6.980810881.15374.pcalhoun@nasnfs>
 <"Your message with ID" <4.1.20010129172447.009182f0@flipper.cisco.com>
 <5.0.0.25.1.20010130004512.009f0960@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-seamoby@diameter.org
Precedence: bulk

Claude,

At 11:45 AM 1/30/01 +0100, Claude Castelluccia wrote:

>>There are other consequences. HMIPv6 exposes the Local Care-of Address for
>>the same reason. Thus, MIPv6 derives no hierarchy hiding benefits from HMIP.
>
>
>this is not true.. in HMIPv6, a MN can hide its Local CoA  from its CNs if 
>necessary...
>

Yes, but isn't that only in extended mode? Btw., the extended mode portion of
the draft is very difficult to understand. It took me several reads to figure
out what it was about. I think it could benefit from an extensive rewrite.

                 jak




From owner-seamoby@diameter.org  Tue Jan 30 10:45:22 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10871
	for <seamoby-archive@odin.ietf.org>; Tue, 30 Jan 2001 10:45:21 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0UENHg08925
	for seamoby-list; Tue, 30 Jan 2001 06:23:17 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0UENDo08919
	for <seamoby@cdma-2000.org>; Tue, 30 Jan 2001 06:23:14 -0800
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA10949
	for <seamoby@cdma-2000.org>; Tue, 30 Jan 2001 05:31:13 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA12198
	for <seamoby@cdma-2000.org>; Tue, 30 Jan 2001 05:31:12 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id FAA01165
	for <seamoby@cdma-2000.org>; Tue, 30 Jan 2001 05:31:11 -0800 (PST)
Date: Tue, 30 Jan 2001 05:31:11 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: [seamoby] Seamoby and SPAM
To: seamoby@cdma-2000.org
Message-ID: <Roam.SIMC.2.0.6.980861471.8162.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

Well, Dave yesterday entertained us with "I could go to JAIL for selling this
CD!", and yes he should (and even for just spamming):) 

In any case, this brings up another point. Some of my lists restrict postings
from list members. This can be quite a pain for people who sent e-mail from an
address that is different from their subscribed address. However, it does
benefit the rest of the community from receiving spam.

Should I implement such a policy on all seamoby related lists?

Thanks,

PatC



From owner-seamoby@diameter.org  Tue Jan 30 11:05:25 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11349
	for <seamoby-archive@odin.ietf.org>; Tue, 30 Jan 2001 11:05:25 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0UEhIG08997
	for seamoby-list; Tue, 30 Jan 2001 06:43:18 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0UEhDo08992
	for <seamoby@diameter.org>; Tue, 30 Jan 2001 06:43:14 -0800
Received: from glandon.inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id OAA00840;
	Tue, 30 Jan 2001 14:51:00 +0100 (MET)
Received: from inrialpes.fr (localhost [127.0.0.1])
	by glandon.inrialpes.fr (8.8.7/8.8.5) with ESMTP id OAA19443;
	Tue, 30 Jan 2001 14:51:00 +0100 (MET)
Message-ID: <3A76C6C4.BE0CD924@inrialpes.fr>
Date: Tue, 30 Jan 2001 14:51:00 +0100
From: Claude Castelluccia <claude.castelluccia@inrialpes.fr>
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf <james.kempf@sun.com>
CC: "Dana L. Blair" <dblair@cisco.com>,
        Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        "'seamoby@diameter.org'" <seamoby@diameter.org>,
        hesham.soliman@era.ericsson.se
Subject: Re: [seamoby] problem statement and rechartering (was: Re:Theright  
 protocol was  RE: [seamoby-mm] ietf-seamoby-mm-problem-00-a1.txt)
References: <Roam.SIMC.2.0.6.980810881.15374.pcalhoun@nasnfs>
	 <"Your message with ID" <4.1.20010129172447.009182f0@flipper.cisco.com>
	 <5.0.0.25.1.20010130004512.009f0960@localhost> <5.0.0.25.1.20010130051911.00a12170@localhost>
Content-Type: multipart/alternative;
 boundary="------------B1196A68DE5FFAA15C5B707E"
Sender: owner-seamoby@diameter.org
Precedence: bulk


--------------B1196A68DE5FFAA15C5B707E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

James Kempf wrote:

> Claude,
>
> At 11:45 AM 1/30/01 +0100, Claude Castelluccia wrote:
>
> >>There are other consequences. HMIPv6 exposes the Local Care-of Address for
> >>the same reason. Thus, MIPv6 derives no hierarchy hiding benefits from HMIP.
> >
> >
> >this is not true.. in HMIPv6, a MN can hide its Local CoA  from its CNs if
> >necessary...
> >
>
> Yes, but isn't that only in extended mode?

no this is possible in both modes...actually this can be used to
provide some kind of mobility privacy...a CN only knows the RCoA
not the actual CoA....

> Btw., the extended mode portion of
> the draft is very difficult to understand. It took me several reads to figure
> out what it was about. I think it could benefit from an extensive rewrite.

ok, thanks. We will work on that....

Claude.

>
>

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------B1196A68DE5FFAA15C5B707E
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
James Kempf wrote:
<blockquote TYPE=CITE>Claude,
<p>At 11:45 AM 1/30/01 +0100, Claude Castelluccia wrote:
<p>>>There are other consequences. HMIPv6 exposes the Local Care-of Address
for
<br>>>the same reason. Thus, MIPv6 derives no hierarchy hiding benefits
from HMIP.
<br>>
<br>>
<br>>this is not true.. in HMIPv6, a MN can hide its Local CoA&nbsp; from
its CNs if
<br>>necessary...
<br>>
<p>Yes, but isn't that only in extended mode?</blockquote>
no this is possible in both modes...actually this can be used to
<br>provide some kind of mobility privacy...a CN only knows the RCoA
<br>not the actual CoA....
<blockquote TYPE=CITE>Btw., the extended mode portion of
<br>the draft is very difficult to understand. It took me several reads
to figure
<br>out what it was about. I think it could benefit from an extensive rewrite.</blockquote>
ok, thanks. We will work on that....
<p>Claude.
<blockquote TYPE=CITE>&nbsp;
<br>&nbsp;</blockquote>

<pre></pre>

<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------B1196A68DE5FFAA15C5B707E--



From owner-seamoby@diameter.org  Tue Jan 30 13:19:27 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14708
	for <seamoby-archive@odin.ietf.org>; Tue, 30 Jan 2001 13:19:26 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0UH1xX09338
	for seamoby-list; Tue, 30 Jan 2001 09:01:59 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0UH1vo09332
	for <seamoby@diameter.org>; Tue, 30 Jan 2001 09:01:57 -0800
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA17473;
	Tue, 30 Jan 2001 08:10:01 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAT05015;
	Tue, 30 Jan 2001 08:09:45 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA28886; Tue, 30 Jan 2001 08:09:45 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14966.59209.581247.972673@thomasm-u1.cisco.com>
Date: Tue, 30 Jan 2001 08:09:45 -0800 (PST)
To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Cc: Michael Thomas <mat@cisco.com>, "Dana L. Blair" <dblair@cisco.com>,
        Kulwinder Atwal <kulwinder.atwal@zucotto.com>, john.loughney@nokia.com,
        Pat.Calhoun@eng.sun.com, charliep@iprg.nokia.com,
        seamoby-mm@cdma-2000.org,
        "'seamoby@diameter.org'" <seamoby@diameter.org>
Subject: Re: [seamoby] problem statement and rechartering (was: Re: The   right protocol was  RE: [seamoby-mm] ietf-seamoby-mm-pr   oblem-00-a1.txt)
In-Reply-To: <Roam.SIMC.2.0.6.980820163.8584.pcalhoun@nasnfs>
References: <14966.4987.820692.152021@thomasm-u1.cisco.com>
	<Roam.SIMC.2.0.6.980820163.8584.pcalhoun@nasnfs>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun writes:
 > So, a move WILL require a full IKE phase 1 AND 2 exchange. Again, far from
 > fast (especially given that it is over the air).

Assuming you use IKE, of course. Initially, you
set up an SA with the current AR. With fast
mobility, I believe that you do a BU to the old AR
to set up the forward tunnel, so no IKE here. The
context transfer is likely to be an SA between the
old AR and the new AR. I don't think it's too
unreasonable to expect that they'll end up with
their SA's already up most of the time.

The big question is what happens when MN arrives
on the new AR. Unless it's completely open or
relegated to PPP (ick), I don't know how the
network admission control is performed. This seems
to have been relegated to a BOF, so it's anybody's
guess what the security scheme will be. Going out
on a limb that it's vaguely similar to RFC2752 (a
scheme I hope that DIAMETER adopts as well...),
you wouldn't need a full 6 message IKE exchange on
the air to get admitted. You'd need to do that
eventually (namely, some time before you wanted to
move), but it doesn't seem to be in the critical
path.

Now, you'll get no argument from me that this 
looks pretty crufty from a global view, but
it doesn't seem to be _fatal_ cruftiness.
   
 > Now that's said, it certainly makes MM MUCH more attractive in v6 networks,
 > where a change of care of address could be reduced significantly.

This seems debatable: with MM can the mobile
node initiate a move? Is it notified of the
move? Given the RSVP analysis I've been working
on, I hope the answer to both of those is yes
and if so, you still need a SA between you and
the old AR.

 > >    IPsec is a v6 MUST and is being widely back implemented
 > >    into v4. Can we move on?
 > 
 > Sure, but where?

Somewhere warm with drinks with little
umbrellas would be fab.

		   Mike


From owner-seamoby@diameter.org  Tue Jan 30 13:27:16 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14906
	for <seamoby-archive@odin.ietf.org>; Tue, 30 Jan 2001 13:27:15 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0UHjuu09468
	for seamoby-list; Tue, 30 Jan 2001 09:45:56 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0UHjro09463
	for <seamoby@cdma-2000.org>; Tue, 30 Jan 2001 09:45:53 -0800
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA10198 for <seamoby@cdma-2000.org>; Tue, 30 Jan 2001 09:53:53 -0700 (MST)]
Received: [from ilms03.cig.mot.com (ilms03.cig.mot.com [136.182.15.13]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA03693 for <seamoby@cdma-2000.org>; Tue, 30 Jan 2001 09:53:52 -0700 (MST)]
Received: from em.cig.mot.com ([160.44.128.5]) by ilms03.cig.mot.com
          (Netscape Messaging Server 3.01)  with SMTP id AAA28625;
          Tue, 30 Jan 2001 10:53:52 -0600
Received: by em.cig.mot.com (SMI-8.6/SMI-SVR4)
	id KAA07636; Tue, 30 Jan 2001 10:53:51 -0600
Date: Tue, 30 Jan 2001 10:53:51 -0600
Message-Id: <200101301653.KAA07636@em.cig.mot.com>
To: pcalhoun@nasnfs.eng.sun.com
Cc: seamoby@cdma-2000.org
In-reply-to: <Roam.SIMC.2.0.6.980861471.8162.pcalhoun@nasnfs> (message from
	Patrice Calhoun on Tue, 30 Jan 2001 05:31:11 -0800 (PST))
Subject: Re: [seamoby] Seamoby and SPAM
From: "La Monte Henry Piggy Yarroll" <piggy@em.cig.mot.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

Yes, please.

Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com> writes:
>Well, Dave yesterday entertained us with "I could go to JAIL for selling this
>CD!", and yes he should (and even for just spamming):) 
>
>In any case, this brings up another point. Some of my lists restrict postings
>from list members. This can be quite a pain for people who sent e-mail from an
>address that is different from their subscribed address. However, it does
>benefit the rest of the community from receiving spam.
>
>Should I implement such a policy on all seamoby related lists?
>
>Thanks,
>
>PatC
>


-- 
"Of course, every once in a while you think you're going home and you 
 find yourself instead in a strange bar kneeling in front of a plate 
 of bugs."					NIC Handle LY


From owner-seamoby@diameter.org  Tue Jan 30 14:12:50 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15749
	for <seamoby-archive@odin.ietf.org>; Tue, 30 Jan 2001 14:12:49 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0UGvGA09320
	for seamoby-list; Tue, 30 Jan 2001 08:57:16 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0UGvEo09315
	for <seamoby@diameter.org>; Tue, 30 Jan 2001 08:57:14 -0800
Received: from centralmail1.Central.Sun.COM ([129.147.62.10])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06409;
	Tue, 30 Jan 2001 08:05:01 -0800 (PST)
Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144])
	by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA12013;
	Tue, 30 Jan 2001 09:04:59 -0700 (MST)
Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4)
	id JAA05242; Tue, 30 Jan 2001 09:22:55 -0700
Message-Id: <5.0.0.25.1.20010130080006.00a15e40@localhost>
X-Sender: kempf@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 30 Jan 2001 08:02:33 -0800
To: Claude Castelluccia <claude.castelluccia@inrialpes.fr>
From: James Kempf <james.kempf@sun.com>
Subject: Re: [seamoby] Re: HMIPv6 & regional registrations
Cc: john.loughney@nokia.com, seamoby@diameter.org
In-Reply-To: <3A76AACB.B3467D45@inrialpes.fr>
References: <5.0.0.25.1.20010130015525.00a0a810@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-seamoby@diameter.org
Precedence: bulk

Claude,

At 12:51 PM 1/30/01 +0100, Claude Castelluccia wrote:

>Could you explain me why this is true for HMIPv6?
>I am very interested ;-)....

After looking over the draft, I see that you are right. The LCoA
only goes to the CN if they are on the same link.

However, the draft does say that the mobile can send the LCoA
to the last MAP. This is certainly a way for hierarchical information
to leak out. This won't work if, for example, the LCoA is a site-local
address. Shouldn't the last MAP be treated like any other corresponding
node?

                 jak



From owner-seamoby@diameter.org  Tue Jan 30 14:15:13 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15798
	for <seamoby-archive@odin.ietf.org>; Tue, 30 Jan 2001 14:15:13 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0UHqFZ09480
	for seamoby-list; Tue, 30 Jan 2001 09:52:15 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0UHqBo09475
	for <seamoby@diameter.org>; Tue, 30 Jan 2001 09:52:12 -0800
Received: from glandon.inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id SAA06038;
	Tue, 30 Jan 2001 18:00:03 +0100 (MET)
Received: from inrialpes.fr (localhost [127.0.0.1])
	by glandon.inrialpes.fr (8.8.7/8.8.5) with ESMTP id SAA19953;
	Tue, 30 Jan 2001 18:00:03 +0100 (MET)
Message-ID: <3A76F313.3931F4AA@inrialpes.fr>
Date: Tue, 30 Jan 2001 18:00:03 +0100
From: Claude Castelluccia <claude.castelluccia@inrialpes.fr>
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf <james.kempf@sun.com>
CC: john.loughney@nokia.com, seamoby@diameter.org,
        hesham.soliman@era.ericsson.se
Subject: Re: [seamoby] Re: HMIPv6 & regional registrations
References: <5.0.0.25.1.20010130015525.00a0a810@localhost> <5.0.0.25.1.20010130080006.00a15e40@localhost>
Content-Type: multipart/alternative;
 boundary="------------F6EECE3123DE29B12F16C7D3"
Sender: owner-seamoby@diameter.org
Precedence: bulk


--------------F6EECE3123DE29B12F16C7D3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

James Kempf wrote:

> Claude,
>
> At 12:51 PM 1/30/01 +0100, Claude Castelluccia wrote:
>
> >Could you explain me why this is true for HMIPv6?
> >I am very interested ;-)....
>
> After looking over the draft, I see that you are right. The LCoA
> only goes to the CN if they are on the same link.
>

actually both solutions are possible: a MN can either use its LCoA or RCoA

as source address....

>
> However, the draft does say that the mobile can send the LCoA
> to the last MAP. This is certainly a way for hierarchical information
> to leak out. This won't work if, for example, the LCoA is a site-local
> address. Shouldn't the last MAP be treated like any other corresponding
> node?

you are right but I think we should allow both solutions and let the MN
decide which solution to use....

The MN should probably use its LCoA to register with its previous MAP if
the new and previous MAP belong to the same site and administrative domain

(the routing will then be optimal).

The MN should (or must) probably use its new RCoA to register with its
previous MAP if the new MAP is in an other site or administration
domain....

does it make sense?

regards,

Claude.

>                  jak

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------F6EECE3123DE29B12F16C7D3
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
James Kempf wrote:
<blockquote TYPE=CITE>Claude,
<p>At 12:51 PM 1/30/01 +0100, Claude Castelluccia wrote:
<p>>Could you explain me why this is true for HMIPv6?
<br>>I am very interested ;-)....
<p>After looking over the draft, I see that you are right. The LCoA
<br>only goes to the CN if they are on the same link.
<br>&nbsp;</blockquote>
actually both solutions are possible: a MN&nbsp;can either use its LCoA
or RCoA
<br>as source address....
<blockquote TYPE=CITE>&nbsp;
<br>However, the draft does say that the mobile can send the LCoA
<br>to the last MAP. This is certainly a way for hierarchical information
<br>to leak out. This won't work if, for example, the LCoA is a site-local
<br>address. Shouldn't the last MAP be treated like any other corresponding
<br>node?</blockquote>
you are right but I think we should allow both solutions and let the MN
<br>decide which solution to use....
<p>The MN&nbsp;should probably use its LCoA to register with its previous
MAP if
<br>the new and previous MAP belong to the same site and administrative
domain
<br>(the routing will then be optimal).
<p>The MN should (or must) probably use its new RCoA to register with its
<br>previous MAP if the new MAP&nbsp;is in an other site or administration
domain....
<p>does it make sense?
<p>regards,
<p>Claude.
<blockquote TYPE=CITE>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
jak</blockquote>

<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------F6EECE3123DE29B12F16C7D3--



From owner-seamoby@diameter.org  Tue Jan 30 16:41:08 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17976
	for <seamoby-archive@odin.ietf.org>; Tue, 30 Jan 2001 16:41:05 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0UKeQa09673
	for seamoby-list; Tue, 30 Jan 2001 12:40:26 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0UKeLo09664
	for <seamoby@diameter.org>; Tue, 30 Jan 2001 12:40:21 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 30 Jan 2001 14:48:09 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <D33PGL0J>; Tue, 30 Jan 2001 14:47:56 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8BD8@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'James Kempf'" <james.kempf@sun.com>
Cc: seamoby-mm@cdma-2000.org, "'seamoby@diameter.org'" <seamoby@diameter.org>
Subject: RE: [seamoby] problem statement and rechartering (was: Re: The ri ght 
         protocol was RE: [seamoby-mm] ietf-seamoby-mm-pr oblem-00-a1.txt)
Date: Tue, 30 Jan 2001 14:47:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C08AF5.89972AE0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C08AF5.89972AE0
Content-Type: text/plain;
	charset="ISO-8859-1"


> -----Original Message-----
> From: James Kempf [mailto:james.kempf@sun.com]
> Sent: Tuesday, January 30, 2001 3:42 AM
> To: Dana L. Blair; Patrice Calhoun; Kulwinder Atwal
> Cc: 'Pat Calhoun'; john.loughney@nokia.com; Pat.Calhoun@eng.sun.com;
> charliep@iprg.nokia.com; seamoby-mm@cdma-2000.org;
> 'seamoby@diameter.org'
> Subject: Re: [seamoby] problem statement and rechartering 
> (was: Re: The
> right protocol was RE: [seamoby-mm] ietf-seamoby-mm-pr 
> oblem-00-a1.txt)
> 
> 
> Dana,
> 
>> There are lots of innovations one could make in this area, 
> but I'm afraid that
> mobile IP has a certain amount of deployment momentum at the 
> moment. It
> would be really a shame, when mobile IP is right at the cusp 
> of becoming real
> after 10 years of hard work, to have energy diverted by a new 
> protocol. 

I'm with you to this point, James. But, if we were to follow this logic
through, we'd still be trying to get ISDN to work, or maybe even, 
*shudder* X.25.  I'm willing to bet that the total person years and
$$$ invested in both of these solutions far outweighs what has been
expended on MIP.

The telecom industry, and ITU, are  known for there inertia. Are you
implying
that the IETF must avoid developing better solutions simply because
people spent 10 years on a solution that wasn't needed?

Gary

>
>                          jak
> 
> 
> 

------_=_NextPart_001_01C08AF5.89972AE0
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: [seamoby] problem statement and rechartering (was: Re: The =
right  protocol was RE: [seamoby-mm] ietf-seamoby-mm-pr =
oblem-00-a1.txt)</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: James Kempf [<A =
HREF=3D"mailto:james.kempf@sun.com">mailto:james.kempf@sun.com</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, January 30, 2001 3:42 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Dana L. Blair; Patrice Calhoun; Kulwinder =
Atwal</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'Pat Calhoun'; john.loughney@nokia.com; =
Pat.Calhoun@eng.sun.com;</FONT>
<BR><FONT SIZE=3D2>&gt; charliep@iprg.nokia.com; =
seamoby-mm@cdma-2000.org;</FONT>
<BR><FONT SIZE=3D2>&gt; 'seamoby@diameter.org'</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [seamoby] problem statement and =
rechartering </FONT>
<BR><FONT SIZE=3D2>&gt; (was: Re: The</FONT>
<BR><FONT SIZE=3D2>&gt; right protocol was RE: [seamoby-mm] =
ietf-seamoby-mm-pr </FONT>
<BR><FONT SIZE=3D2>&gt; oblem-00-a1.txt)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Dana,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; There are lots of innovations one could =
make in this area, </FONT>
<BR><FONT SIZE=3D2>&gt; but I'm afraid that</FONT>
<BR><FONT SIZE=3D2>&gt; mobile IP has a certain amount of deployment =
momentum at the </FONT>
<BR><FONT SIZE=3D2>&gt; moment. It</FONT>
<BR><FONT SIZE=3D2>&gt; would be really a shame, when mobile IP is =
right at the cusp </FONT>
<BR><FONT SIZE=3D2>&gt; of becoming real</FONT>
<BR><FONT SIZE=3D2>&gt; after 10 years of hard work, to have energy =
diverted by a new </FONT>
<BR><FONT SIZE=3D2>&gt; protocol. </FONT>
</P>

<P><FONT SIZE=3D2>I'm with you to this point, James. But, if we were to =
follow this logic</FONT>
<BR><FONT SIZE=3D2>through, we'd still be trying to get ISDN to work, =
or maybe even, </FONT>
<BR><FONT SIZE=3D2>*shudder* X.25.&nbsp; I'm willing to bet that the =
total person years and</FONT>
<BR><FONT SIZE=3D2>$$$ invested in both of these solutions far =
outweighs what has been</FONT>
<BR><FONT SIZE=3D2>expended on MIP.</FONT>
</P>

<P><FONT SIZE=3D2>The telecom industry, and ITU, are&nbsp; known for =
there inertia. Are you implying</FONT>
<BR><FONT SIZE=3D2>that the IETF must avoid developing better solutions =
simply because</FONT>
<BR><FONT SIZE=3D2>people spent 10 years on a solution that wasn't =
needed?</FONT>
</P>

<P><FONT SIZE=3D2>Gary</FONT>
</P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; jak</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C08AF5.89972AE0--


From owner-seamoby@diameter.org  Tue Jan 30 17:17:42 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18332
	for <seamoby-archive@odin.ietf.org>; Tue, 30 Jan 2001 17:17:39 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0ULKfm09735
	for seamoby-list; Tue, 30 Jan 2001 13:20:41 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0ULKdo09730
	for <seamoby@diameter.org>; Tue, 30 Jan 2001 13:20:39 -0800
Received: from centralmail1.Central.Sun.COM ([129.147.62.10])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03158;
	Tue, 30 Jan 2001 12:28:35 -0800 (PST)
Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144])
	by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA29460;
	Tue, 30 Jan 2001 13:28:35 -0700 (MST)
Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4)
	id NAA12051; Tue, 30 Jan 2001 13:46:32 -0700
Message-Id: <5.0.0.25.1.20010130122534.00a15bd0@localhost>
X-Sender: kempf@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 30 Jan 2001 12:26:07 -0800
To: Claude Castelluccia <claude.castelluccia@inrialpes.fr>
From: James Kempf <james.kempf@sun.com>
Subject: Re: [seamoby] Re: HMIPv6 & regional registrations
Cc: john.loughney@nokia.com, seamoby@diameter.org,
        hesham.soliman@era.ericsson.se
In-Reply-To: <3A76F313.3931F4AA@inrialpes.fr>
References: <5.0.0.25.1.20010130015525.00a0a810@localhost>
 <5.0.0.25.1.20010130080006.00a15e40@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-seamoby@diameter.org
Precedence: bulk

Claude,

At 06:00 PM 1/30/01 +0100, Claude Castelluccia wrote:
>James Kempf wrote:
>>Claude,
>>
>>At 12:51 PM 1/30/01 +0100, Claude Castelluccia wrote:
>>
>> >Could you explain me why this is true for HMIPv6?
>> >I am very interested ;-)....
>>
>>After looking over the draft, I see that you are right. The LCoA
>>only goes to the CN if they are on the same link.
>>
>actually both solutions are possible: a MN can either use its LCoA or RCoA
>as source address....
>>
>>However, the draft does say that the mobile can send the LCoA
>>to the last MAP. This is certainly a way for hierarchical information
>>to leak out. This won't work if, for example, the LCoA is a site-local
>>address. Shouldn't the last MAP be treated like any other corresponding
>>node?
>you are right but I think we should allow both solutions and let the MN
>decide which solution to use....
>
>The MN should probably use its LCoA to register with its previous MAP if
>the new and previous MAP belong to the same site and administrative domain
>(the routing will then be optimal).
>
>The MN should (or must) probably use its new RCoA to register with its
>previous MAP if the new MAP is in an other site or administration domain....
>
>does it make sense?

Yes, but I think the draft needs to make this clearer.

                 jak



From owner-seamoby@diameter.org  Tue Jan 30 18:03:28 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18911
	for <seamoby-archive@odin.ietf.org>; Tue, 30 Jan 2001 18:03:28 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0UKlE309701
	for seamoby-list; Tue, 30 Jan 2001 12:47:14 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0UKlAo09691
	for <seamoby@diameter.org>; Tue, 30 Jan 2001 12:47:10 -0800
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 30 Jan 2001 14:51:37 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <D33PGMDC>; Tue, 30 Jan 2001 14:51:37 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8BD9@zwdld001.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'seamoby'" <seamoby@diameter.org>,
        seamoby_context@standards.nortelnetworks.com,
        "'seamoby-mm'" <seamoby-mm@cdma-2000.org>
Subject: [seamoby] postings
Date: Tue, 30 Jan 2001 14:51:33 -0500
Sensitivity: Company-Confidential
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: text/plain; charset="ISO-8859-1"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

I would like to ask, once again, that people take the time to prune their
email "To" lists.
I have been receiving up to 4 copies of some postings. And, I noticed in one
recent
mailing, Pat's address appearing no less then 3 times, in addition to the
seamoby and
seamoby-mm addresses.

Gary



From owner-seamoby@diameter.org  Tue Jan 30 19:14:31 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19545
	for <seamoby-archive@odin.ietf.org>; Tue, 30 Jan 2001 19:14:30 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0ULjhK09760
	for seamoby-list; Tue, 30 Jan 2001 13:45:43 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0ULjeo09754
	for <seamoby@diameter.org>; Tue, 30 Jan 2001 13:45:40 -0800
Received: from centralmail1.Central.Sun.COM ([129.147.62.10])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20888;
	Tue, 30 Jan 2001 12:53:09 -0800 (PST)
Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144])
	by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA06025;
	Tue, 30 Jan 2001 13:53:09 -0700 (MST)
Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4)
	id OAA12706; Tue, 30 Jan 2001 14:11:06 -0700
Message-Id: <5.0.0.25.1.20010130123347.00a0e2e0@localhost>
X-Sender: kempf@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 30 Jan 2001 12:48:59 -0800
To: "Gary Kenward" <gkenward@nortelnetworks.com>
From: James Kempf <james.kempf@sun.com>
Subject: RE: [seamoby] problem statement and rechartering (was: Re: The
  ri ght  protocol was RE: [seamoby-mm] ietf-seamoby-mm-pr
  oblem-00-a1.txt)
Cc: seamoby-mm@cdma-2000.org, "'seamoby@diameter.org'" <seamoby@diameter.org>
In-Reply-To: <13E2EF604DE5D111B2E50000F80824E8057A8BD8@zwdld001.ca.norte
 l.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-seamoby@diameter.org
Precedence: bulk

At 02:47 PM 1/30/01 -0500, Gary Kenward wrote:

>I'm with you to this point, James. But, if we were to follow this logic
>through, we'd still be trying to get ISDN to work, or maybe even,
>*shudder* X.25.  I'm willing to bet that the total person years and
>$$$ invested in both of these solutions far outweighs what has been
>expended on MIP.
>
>The telecom industry, and ITU, are  known for there inertia. Are you implying
>that the IETF must avoid developing better solutions simply because
>people spent 10 years on a solution that wasn't needed?

If I thought that, I wouldn't have recommended micromobility be taken to 
the IRTF.
And if I thought mobile IP wasn't needed, I wouldn't be working
on fast handoff (and care so much that the right solution be adopted).

Mobile IP has made some straightforward
extrapolations from the wired case, but it is not clear that they
are optimal. The Seamoby micromobilty design team
has decided to restrict discussion of the need for a new micromobility
protocol to intrasubnet mobility. Now, it is not at all clear that this
is even a problem at L3 given support provided in L2 for mobility
between access points. I don't want to prejudge the outcome of
their process, but I have the impression that this decision was
as much influenced by the fact that mobile IP is the mobility
protocol of choice for the intersubnet case and the people who
have been pushing for doing a new micromobility protocol are
looking for some space where they can do some new work.
I don't think that's the right way to get the best mobility solution.

I think Phil N., Andrew C., and the others that have new ideas in
this area need some space where they can explore exactly
what is the right way to do mobility at the edge and in the
core, without regard to precedent. The IETF is not the
right place for this work, since the intent of IETF standards
is to facilitate interoperability and deployment. The IRTF
is.

The fact of the matter is that mobile IP has deployment momentum
even if it isn't the best (in some abstract sense) protocol given
what we know now. It clearly was when it was designed, and
the deployment momentum suggests we finish it and make
it available for the 3G's and others. After all, would the Internet
have ever happened if IPv4 had been abandoned  immediately when
Deering and others began to realize the problems it has?

                 jak



From owner-seamoby@diameter.org  Wed Jan 31 13:54:29 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23417
	for <seamoby-archive@odin.ietf.org>; Wed, 31 Jan 2001 13:54:29 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0VGBct11390
	for seamoby-list; Wed, 31 Jan 2001 08:11:38 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0VGBao11385
	for <seamoby@diameter.org>; Wed, 31 Jan 2001 08:11:36 -0800
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA27031 for <seamoby@diameter.org>; Wed, 31 Jan 2001 08:19:38 -0700 (MST)]
Received: [from il02exb01.comm.mot.com (il02exb01.comm.mot.com [145.1.204.17]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA04174 for <seamoby@diameter.org>; Wed, 31 Jan 2001 08:19:37 -0700 (MST)]
Received: by il02exb01.comm.mot.com with Internet Mail Service (5.5.2651.58)
	id <DXKCF28R>; Wed, 31 Jan 2001 09:19:37 -0600
Message-ID: <01FAF65DEA16D4119B95009027E78F310248DCFD@il02exm26.comm.mot.com>
From: Lewis Adam-CAL022 <Adam.Lewis@motorola.com>
To: "'seamoby@diameter.org'" <seamoby@diameter.org>
Subject: [seamoby] auth 34455696 subscribe seamoby adam.lewis@motorola.com
Date: Wed, 31 Jan 2001 09:19:30 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk




------                                                                
Adam Lewis

Advanced Technology & Strategy
Global Technologies Development Group

1301 East Algonquin Road, Schaumburg, Illinois 60196
Telephone: (847) 576-8489 Fax: (847) 576-9018
Email: adam.lewis@motorola.com



From owner-seamoby@diameter.org  Wed Jan 31 20:39:20 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29848
	for <seamoby-archive@odin.ietf.org>; Wed, 31 Jan 2001 20:39:19 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f0VNCEp12105
	for seamoby-list; Wed, 31 Jan 2001 15:12:14 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f0VNB1o12100
	for <seamoby@diameter.org>; Wed, 31 Jan 2001 15:11:01 -0800
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f0VMJ3C23163
	for <seamoby@diameter.org>; Wed, 31 Jan 2001 23:19:03 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Jan 31 23:19:05 2001 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2651.58)
	id <DW6GZXMS>; Wed, 31 Jan 2001 23:19:05 +0100
Message-ID: <034BEFD03799D411A59F00508BDF75465B6953@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  (ERA)" <Hesham.Soliman@era.ericsson.se>
To: "'James Kempf'" <james.kempf@sun.com>
Cc: john.loughney@nokia.com, seamoby@diameter.org,
        "Hesham Soliman  (ERA)"
	 <Hesham.Soliman@era.ericsson.se>,
        Claude Castelluccia
	 <claude.castelluccia@inrialpes.fr>
Subject: RE: [seamoby] Re: HMIPv6 & regional registrations
Date: Wed, 31 Jan 2001 23:19:02 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hello James,
 
Thanks for the comment. We will be releasing a new draft next
week anyway. This comment was also brought up during the
presentation in San Diego and we will add the necesary text 
to clarify that. 

BTW, I haven't been able to keep up with the discussions on 
this mailing list, so please let us (the authors) know if there are
any comments to consider for this update. 

Regards,
Hesham


> -----Original Message-----
> From:	James Kempf [SMTP:james.kempf@sun.com]
> Sent:	Wednesday, 31 January 2001 7:26
> To:	Claude Castelluccia
> Cc:	john.loughney@nokia.com; seamoby@diameter.org; hesham.soliman@era.ericsson.se
> Subject:	Re: [seamoby] Re: HMIPv6 & regional registrations
> 
> Claude,
> 
> At 06:00 PM 1/30/01 +0100, Claude Castelluccia wrote:
> >James Kempf wrote:
> >>Claude,
> >>
> >>At 12:51 PM 1/30/01 +0100, Claude Castelluccia wrote:
> >>
> >> >Could you explain me why this is true for HMIPv6?
> >> >I am very interested ;-)....
> >>
> >>After looking over the draft, I see that you are right. The LCoA
> >>only goes to the CN if they are on the same link.
> >>
> >actually both solutions are possible: a MN can either use its LCoA or RCoA
> >as source address....
> >>
> >>However, the draft does say that the mobile can send the LCoA
> >>to the last MAP. This is certainly a way for hierarchical information
> >>to leak out. This won't work if, for example, the LCoA is a site-local
> >>address. Shouldn't the last MAP be treated like any other corresponding
> >>node?
> >you are right but I think we should allow both solutions and let the MN
> >decide which solution to use....
> >
> >The MN should probably use its LCoA to register with its previous MAP if
> >the new and previous MAP belong to the same site and administrative domain
> >(the routing will then be optimal).
> >
> >The MN should (or must) probably use its new RCoA to register with its
> >previous MAP if the new MAP is in an other site or administration domain....
> >
> >does it make sense?
> 
> Yes, but I think the draft needs to make this clearer.
> 
>                  jak


From owner-seamoby@diameter.org  Wed Jan 31 21:40:48 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02164
	for <seamoby-archive@odin.ietf.org>; Wed, 31 Jan 2001 21:40:48 -0500 (EST)
Received: (from majordomo@localhost)
	by charizard.diameter.org (8.10.0/8.10.0) id f111lAH12299
	for seamoby-list; Wed, 31 Jan 2001 17:47:10 -0800
X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f
Received: from maild.telia.com (root@maild.telia.com [194.22.190.3])
	by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id f111l6o12294
	for <seamoby@cdma-2000.org>; Wed, 31 Jan 2001 17:47:07 -0800
Received: from leonardo.levkowetz.com (h242n1fls33o801.telia.com [213.64.180.242])
	by maild.telia.com (8.9.3/8.9.3) with SMTP id BAA00406;
	Thu, 1 Feb 2001 01:55:04 +0100 (CET)
From: Henrik Levkowetz <henrik@levkowetz.com>
Date: Thu, 1 Feb 2001 01:52:12 +0100
X-Mailer: KMail [version 1.1.99]
Content-Type: text/plain;
  charset="iso-8859-1"
To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>, seamoby@cdma-2000.org
References: <Roam.SIMC.2.0.6.980861471.8162.pcalhoun@nasnfs>
In-Reply-To: <Roam.SIMC.2.0.6.980861471.8162.pcalhoun@nasnfs>
Subject: Re: [seamoby] Seamoby and SPAM
MIME-Version: 1.0
Message-Id: <01020101521200.00806@leonardo.levkowetz.com>
Content-Transfer-Encoding: 8bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Pat,

   Is it possible to permit postings where either the From: or
Reply-To: fields match a list member?  That would work out better
for me than limiting it to the From: field only.

   Best,
      Henrik


On Tuesday 30 January 2001 14:31, Patrice Calhoun wrote:
> Well, Dave yesterday entertained us with "I could go to JAIL for selling
> this CD!", and yes he should (and even for just spamming):)
>
> In any case, this brings up another point. Some of my lists restrict
> postings from list members. This can be quite a pain for people who sent
> e-mail from an address that is different from their subscribed address.
> However, it does benefit the rest of the community from receiving spam.
>
> Should I implement such a policy on all seamoby related lists?
>
> Thanks,
>
> PatC