Subject: [mobile-ip] Final(?) Cut on LMM Requirements

From: Phil Roberts <[email-masked]>
Date: Wed, 25 Apr 2001 10:37:21 -0400

Seems like we're converging apart from the multiple levels of hierarchy
discussion.  Here's what has emerged:

1. LMM shall be introduced to minimize the signalling traffic to the home
agent or correspondent nodes for intradomain mobility.
(One comment - how constrained is "domain" here?  Certainly administrative
domain but can it be more constrained than that?  Didn't see any other
suggestions.)
2. LMM shall be secure from malicious behavior.
3. Connectivity to the mobiles should be minimized (MUST) or eliminated
(strive for this) in the presence of failure of LMM agents.
(A couple of comments is that this should be restated to be "in the presence
of topological changes" where failure of an LMM is a particular instance of
this.  There was some dissent on this alternative.)
4. LMM shall be compatible with fast handoffs.
5. LMM shall scale to support millions of nodes.
(Comment had been that this was too broad but only other suggestion was:
"LMM shall scale so that the number of LMM agents scale linearly or
sublinearly with the number of deployed subnets, not the number of mobiles."
Unless there is more support for the revision we'll stay with the original)
6. LMM shall not increase the number of messages between the MN and the LMM
agents.
7. Any additional header overhead caused by LMM should be eliminated by
compression and transfer of compressor state on movement should be possible
so as not to introduce any perceived service disruption.
(This depends on work in other groups (ROHC and Seamoby))
8. LMM shall not require changes to the HA and the CNs.
9. LMM should provide the same level of mobility management support as in
the basic MIPv6 spec.
10. LMM should support autoconfig.

Unless there is some strong objection to these they will be requirements.
We may or may not add one on multiple levels of hierarchy depending on the
other discussion.

Phil

---

From: Theo Pagtzis <[email-masked]>
Date: Wed, 25 Apr 2001 10:37:37 -0700

Hi Phil,

Some comments here:

BTW do we think that the LMM should not require all routers to be LMM-aware?

more comments below..

> domain but can it be more constrained than that?  Didn't see any other

I am not aware of a name that maps to such notion but I think we could enforce
a number of hops that identify a

    macro domain (adminstrative)
     micro domain (two or more domains) that constitute a macro domain. It's
cardinality could be identified as
                                                    diameter of macro domain
                        MDcard =      ----------------------------
                                                 target diameter for micro
domain

depending on the target diameter for a micro domain we can have a variable
sized domain as part ot the admin one.

> 2. LMM shall be secure from malicious behavior.

agreed

> (strive for this) in the presence of failure of LMM agents.

agreed

> 4. LMM shall be compatible with fast handoffs.

agreed

> Unless there is more support for the revision we'll stay with the original)

In principle fine; just a shot to see if we can enrich the revised one:

The LMM shall scale to support aggregates of dense populations of MNs (in the
figures of mi/bi/zillions) per administrative domain unit. These dense MN
populations should be distributed within constituents of the admin domain so as
to avoid hot spot effects that can undermine the efficiency of the LMM scheme.

> 6. LMM shall not increase the number of messages between the MN and the LMM

as opposed to what?  We need to provide a yardstick here...

> (This depends on work in other groups (ROHC and Seamoby))

I think we state as a requirement that:

"Any additional header overhead caused by LMM should be eliminated so as not to
introduce any perceived service disruption."

I suggest that we leave the solution space (ROHC/Seamoby) out of this since
that other group are working on them..it is the task of these groups to effect
such optimizations over any LMM protocols.

> 8. LMM shall not require changes to the HA and the CNs.

agreed

> 9. LMM should provide the same level of mobility management support as in

of course you imply "A minimum of" otherwise there is no reason for an
extension

> 10. LMM should support autoconfig.

very much agreed

> We may or may not add one on multiple levels of hierarchy depending on the

In terms of the host routes and multiple levels of hierarchy I can only
emphasize that we are going to find them in front of us as soon as

- not all routing elements are LMM-aware (need to know the immediate LMM-aware
neighbours to cater for resiliency), hence we need urgently host routes..which
BTW the B-Cache has had for years... :))))
- we want resiliency to failure....we will need to know the previous and next
LMM-aware routers which can only map to a hierarchy... assuming no partitioning
in LMM servicing..

If we opt not to put them in it is just that we have decided to turn a blind
eye and put them under the carpet...but we will step on that spot very soon...

Theo

UCL/ Mobile Systems