Subject: RE: [seamoby] Some thoughts and issues

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 4 Jan 2001 14:00:52 -0600

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:[email-masked]]
Sent: Thursday, December 21, 2000 9:36 AM
To: [email-masked]'
Cc: James Kempf; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [seamoby] Some thoughts and issues

> -----Original Message----- 
> From: Andrew T. Campbell [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Thursday, December 21, 2000 7:06 AM 
> To: Kenward, Gary [WDLN2:AN10:EXCH] 
> Cc: James Kempf; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked] 
> 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

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 4 Jan 2001 15:56:35 -0800 (PST)

> 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: Phil Neumiller <[email-masked]>
Date: Thu, 04 Jan 2001 20:24:55 -0600

Bizzare comments below...

Pat Calhoun wrote:
> =
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: Phil Neumiller <[email-masked]>
Date: Thu, 04 Jan 2001 20:43:45 -0600

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: Pat Calhoun <[email-masked]>
Date: Thu, 4 Jan 2001 18:26:34 -0800 (PST)

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 4 Jan 2001 19:44:04 -0800 (PST)

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

PatC