Subject: [seamoby] Micromobility Problem Statement ISSUE 2

From: [email-masked]
Date: Wed, 3 Jan 2001 11:10:15 -0600

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: Kulwinder Atwal <[email-masked]>
Date: Fri, 5 Jan 2001 10:12:21 -0500

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Friday, January 05, 2001 12:07 AM
> To: Kulwinder Atwal
> Cc: 'Pat Calhoun'; Gary Kenward; [email-masked]';
> [email-masked]
> 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: James Kempf <[email-masked]>
Date: Fri, 5 Jan 2001 07:42:58 -0800 (PST)

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?

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Fri, 05 Jan 2001 11:02:17 -0500

>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

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

Michael A. Ramalho, Ph.D.
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.732.449.5762
Cell: +1.732.809.0188
Pager: +1.800.365.4578

---

From: Kulwinder Atwal <[email-masked]>
Date: Fri, 5 Jan 2001 11:22:11 -0500

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. 

> From: Michael A. Ramalho [mailto:[email-masked]]
> Sent: Friday, January 05, 2001 11:02 AM
> To: Kulwinder Atwal; 'Pat Calhoun'; Kulwinder Atwal
> Cc: Gary Kenward; [email-masked]'; [email-masked]

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 5 Jan 2001 11:47:33 -0500

> Sent: Thursday, January 04, 2001 8:13 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: [email-masked]'; [email-masked]

*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

*snip*

> 2. Do we even care about a standardized protocol between the 

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

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 5 Jan 2001 14:46:34 -0500

*snip*
> message to old AP over wired link.

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