Subject: [mobile-ip] Revised Localized Mobility Management Requirements

From: Phil Roberts <[email-masked]>
Date: Tue, 17 Apr 2001 18:17:15 -0400

OK.  Let's make another cut through these.  Seems that folks like the title
Localized Mobility Management.  I didn't retain the original numbers.

Agreed upon requirements where there was no dissent:
1. Regional registration shall be introduced to minimize the signaling
traffic to the home agent or correspondent nodes for intradomain mobility.
2. Regional registration shall be secure against malicious behavior from
visiting mobiles

That's about it.

There was only minor dissent on these:
3. Connectivity to the mobiles shall not be interrupted in the presence of
the failure of regional registration agents.
[Only comment was that disruption should be minimized.  I'd like to get a
sense from the working group whether it feels that this one should be
restated]
4. Regional registration shall support fast handoffs.
[Several comments that it should be compatible and no dependencies between
the specs, so how about: Regional registration shall be compatible with fast
handoffs.]
5. Regional registration shall scale to support millions of nodes in a
visited network.
[One comment that this was too broad, so I'd request someone to rephrase it
in a better way]

Mostly disagreement on these:
6. .  Regional registration shall not introduce new overhead on links
between the mobile and the local mobility management agents.
[Comments were that it should be minimized, or that it was ok if it meant no
more overhead than a binding update.  Here's my attempt at a revision: local
mobility management shall not introduce new messages to notify the LMM
agents of a move.  There is a disagreement as to whether adding additional
over the air bytes is an issue, and if it is whether it's this WG's
responsibility to solve it]
7. Regional registration shall allow multiple levels of hierarchy.
[There was some strong disagreement on this.  Perhaps Jim or Karim could
start a separate thread to track this one down?]
8. Regional registration shall not require changes ot the MN, the home
agent, or correspondent nodes.
[Many thought requiring no change to the MN was not doable, but the home
agent or CN should be unchanged.  So I propose we just rewrite this as:
Regional registration shall not require changes to the home agent or
correspondent nodes.]
9. Regional registration shall not introduce host routes in routing tables.
[Didn't get much positive on this one and got the sense folks don't want to
rathole on a host routing discussion.  I propose we drop this.]  

We also had request for some new requirements:
10. LMM should provide the same level of mobility mgmt support as in the
basic MIP v6 spec.  MM fns supported in MIP v6 must not be reduced.
[Some positive feedback on this, shall we keep it?]
11. LMM must interwork with MIPv6, IPv6, and the proposed mechanisms for SA
establishment
[One comment that this was stating the obvious.  Shall we keep it?]

12. LMM should be optimized for mobile-to-mobile.
[Never really understood what this requirement was supposed to be.  Got
similar feedback from others.  I propose we drop it.]

Received no feedback on the following proposed requirements.  Anybody want
to keep these?
13. Should minimize # of network nodes affected by HO signalling.
14. Should support autoconfig.
15. Should simplify network design and provisioning.

---

From: Theo Pagtzis <[email-masked]>
Date: Wed, 18 Apr 2001 11:18:44 -0700

Hi Phil,

a few comments below..

> 2. Regional registration shall be secure against malicious behavior from

Perhaps on 2 we want to incorporate _any_ malicious behaviour..not just the
MNs??

> the failure of regional registration agents.

I would like to propose here that this requirement is made rather more generic.
The requirement in the rationale I have considered is that :

     "a Localised mobility management scheme should be able to adapt to
topological changes
arising in the domain that the LMM scheme is in effect.

The reason:

    the failure of LMM agents manifests itself as a topological change, since
in IPv6 any such LMM agent will be a routing element. However, the population
of new routing elements that can be potential candidates for LMM agents is also
a manifestation of a topological change.

The LMM scheme should be able to adapt to both; the latter is extremely
important in terms of scalability and incremental deployment since we cannot
expect to cast a domain topology in stone and live without expansion.

> sense from the working group whether it feels that this one should be

My feeling on this one is that objectively we need to strive for elimination.
However, with the current expertise we have this may not seem a realistic
target for the particular requirement which to me sounds like

"topological changes in the routing fabric with regard to an LMM scheme MUST
bear a measure of minimal disruption to the extension optimizations effected by
that (LMM) scheme. However, it is the intention that an LMM scheme should
strive to eliminate even minimal disruption to the MNs, if possible."

As such we should explictly state that we are making a minimum requirement the
minimization and we strive for elimination.

> the specs, so how about: Regional registration shall be compatible with fast

Agreed. Although I think that it is fast handoffs that should worry about that
requirement not the LMM scheme itself. In a divide and conquer manner I
consider that you try to effect

   1. Mobility
    1.a  localisation of mobility and subsequent speedups (LMM)
       1.a.a speedup optimizations by applying fast handoff techniques over
that LMM...

So the compatibility is for the fast handoff scheme not for LMM since the LMM
is the core of the optimization...

I am not sure what is the order of prescedence for others over fast handoffs
though..

> [One comment that this was too broad, so I'd request someone to rephrase it

Well thinking about it again and again we have two sides of scalability, one
interacting with the other. Consider:

      The LMM scheme should be able to adapt (according to the rationale I have
provided above) to topological changes effected in the routing fabric of the
domain the LMM scheme gets applied on. But why should it be able to adapt? Of
course to utilise _all_ the available (during expansion) or possible (during
contraction) routing elements and thus candidate LMM agents.

    On reason for that is to optimize the localisation point (better
candidates). But as soon as the localisation point gets optimized in a
distributed fashion (i.e. not all MNs get the same one) you have what?????
SCALABILITY.....

So adaptivity may implicitly effect scalability from the routing fabric's
viewpoint of an LMM scheme.

From the perspective of the MN:

     We want the following:
   "the LMM-enabled domain to support a dense population of mobile nodes."

That may be mi/bi/trillions, etc. However, to effect that, the LMM scheme MUST
take advantage of the scalability potentials of the routing fabric in terms of
LMM-aware routers.
An that implies that it is the LMM scheme that has to provide such internal
scalability before it can adhere to any scalability goals for dense MN
populations within an LMM-aware domain.

In that respect, I am inclined to say that:

an LMM scheme MUST provide scalable population of LMM-aware routing elements
which should be utilised if the scheme is to support dense populations of MNs
within an LMM-aware domain.

> responsibility to solve it]

I agree that an LMM scheme should minimize overhead on links between LMM agents
and MNs
But there is also a slight falacy about what constitutes a new message. We have
the backdoor of expanding the BU I guess so I could render the requirement
invalid.

I think it would work better to let implementors feel responsible about
minimization rather than trying to constraint them like that..they usually find
the backdoor straight away..

> start a separate thread to track this one down?]

I personally insist that multiple levels of LMM hierarchy should be allowed. I
feel unconvinced that single depth is sufficient for different LMM scenarios

> Regional registration shall not require changes to the home agent or

fine

> rathole on a host routing discussion.  I propose we drop this.]

agreed

> [Some positive feedback on this, shall we keep it?]

if we specify what we mean by level of mobility management so that we
understand what we are talking about, then maybe....

> [One comment that this was stating the obvious.  Shall we keep it?]

I am not in favour of keeping that for reasons already explained.

> similar feedback from others.  I propose we drop it.]

basically here people referred to CN being in the same net with the MN and both
being mobile, didn't they?

Although the description of the original req has not been very clear, I suggest
we either become clearer on what we want to get out of that or drop it.

> 13. Should minimize # of network nodes affected by HO signalling.

not sure about what is meant by that..either elaborate a little or drop..

> 14. Should support autoconfig.

I would say an ABSOLUTE 'must' or at worst 'should'. Most LMM schemes I know
of, have pushed a lot of important parts of the protocol. If single points of
failure must be resolved then autoconfiguration is nothing _less_ than a must.

> 15. Should simplify network design and provisioning.

simplification is a contradiction to specialisation (i.e. extension). Drop.

Theo

UCL/Mobile Systems

---

From: Michael Thomas <[email-masked]>
Date: Thu, 19 Apr 2001 09:25:59 -0700 (PDT)

So I've got a nagging question:

Why is RR and the forward tunnel aspect of FMIP
considered to be different problems? They both
involve registering with an AR which acts like a
home agent for the MN.

Wouldn't it be better to have exactly *one* set of
requirements and protocol of how a MN attaches to
a local home agent, and let FMIP just define the
interaction (or not, IMO) between the old AR and
the new AR?

If nothing else, the combinatorics of
MIP/HMIP/FMIP here are pretty hard to get my head
around.

		Mike

---

From: Theo Pagtzis <[email-masked]>
Date: Thu, 19 Apr 2001 11:23:23 -0700

Hi Mike,

  I will only show my rationale behind it and hope that it reflects and objective
interpretation and classification in the pursuit for fine-grained mobility.

Having as a given core MIPv6, we attempt to approach reduction of signalling by
localisation.

An LMM is nothing more than an instantiation of the mobility problem that is
fine-grained over a certain locality. That means to me that an LMM should sit on
top of core MIPv6 just to be able to revert back if the LMM does not work or
fails.

A Fast MIPv6 scheme attempts to remove latency during the handoff independent of
the mobility pattern. This is somewhat different than what the LMM is primarily
pursuing: that is reduction of signalling, but as a side-effect it should meet
lower latencies since the localisation point is closer now. That means to me also
that an FMIP scheme should be able to sit on top of core MIPv6 for similar reasons
to the ones for an LMM scheme.

Now one could say here that an LMM and an FMIPv6 scheme lie on the same level of
applicability...I think not...

Why

If one tries to apply mobility in the following order we have:

core MIPv6
LMM for v6 (localisation extn of the core MIPv6)
since the LMM for v6 is only effecting a localisation (and fundamentaly
_recursing_ base mobility to a good extent) I would find it reasonable to try and
speed up the process locally..
that is apply FMIP on top of the LMM

If we follow the opposite order from the LMM scheme onwards, I see it happening in
a bit unnatural fashion. Consider:

core MIPv6 in effect
Fast MIPv6  to speed up the handoff process
Now apply the LMM scheme..I cannot see how you speed up the handoff and past that
you try to reduce the signalling by effecting localisation...

This is because you have already tried to use optimized signalling for speed over
any AR and then you try to reduce them for locality when you become extra specific
about the instance of the AR: that is (in the current specs) a GMA/MAP. I don't
think it will get reduced without losing optimality for the original purpose

Theo

UCL/Mobile Systems

---

From: Michael Thomas <[email-masked]>
Date: Thu, 19 Apr 2001 12:43:45 -0700 (PDT)

> applicability...I think not...

   I'm not saying that they're equally applicable. I'm saying that
   the mechanisms are nearly (completely?) identical and that it
   would be nice to keep it that way since they
   both have to interoperate with AAA, QoS, etc too.

   In general, I think that RR, etc, would do well 
   to steer away from what their applicability is
   and focus more on what the protocol mechanisms 
   are given a set of requirements. All I'm asking
   is why FMIP's needs for a localized forward
   tunnel to be established should not be part of
   the requirements for RR. We could then delete
   the redundant set of mechanism from FMIP.

		Mike

---

From: Theo Pagtzis <[email-masked]>
Date: Thu, 19 Apr 2001 13:14:02 -0700

Hi Mike,

>    the redundant set of mechanism from FMIP.

IMHO it is quite the opposite...it is not that FMIP needs a localised forward tunnel
but that the localised forward tunnel could use FMIP to further speed up handoff..

IF FMIP wants to be applicable over an LMM scheme it should  be compatible with the
LMM's mode of operation, i.e if we want to apply FMIP over an LMM scheme the FMIP
proto should be adaptable to LMM..

In practice that should not be difficult at all since the AR are simply becoming
LMM-aware routing elements..of course there is more to it, but this is the core
essense, I think.

Theo

UCL/ Mobile Systems