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

From: James Kempf <[email-masked]>
Date: Tue, 17 Apr 2001 18:04:42 -0700 (PDT)

Hi Phil,

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

Yes, it needs to 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.]

Sounds good.

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

I made the comment, actually, I think we need to identify what this
means in terms of specific technical requirements. Here are a few:

	5.1 Router/agent state involved in implementing localized mobility
	management should scale linearly at most.
	
	5.2 The number of routers/agents should scale sublinearly or
	linearly with the number of deployed subnets, not with the 
	number of mobile nodes.

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

I would suggest a requirement that the design verify that any additional
bytes are removable with header compression, and that header compression
+ context transfer will not introduce any additional latency into
handover, if any additional header bytes are being introduced This should 
require a review by ROHC.

>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?]

We're working on it.

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

OK.

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

This is a subtopic of the router/agent state scaling requirement, which I think
is more appropriate.

>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?]

Yes.

>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?]
>

Not clear what the consequences are. Can we have clarification 
from the proposer?

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

Agreed.

>Received no feedback on the following proposed requirements.  Anybody want
>to keep these?
>13. Should minimize # of network nodes affected by HO signalling.

Agree.

>14. Should support autoconfig.

Agree.

>15. Should simplify network design and provisioning.

Agree.

Also:

16. LMM should not introduce any additional machineary beyond that
required for LMM (preferences, load balancing, etc.). These are
the domain of other protocols being developed by other working
groups. 

		jak

---

From: James Kempf <[email-masked]>
Date: Wed, 18 Apr 2001 12:06:03 -0700 (PDT)

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

I agree with this. It is a much more precise description.

		jak
>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.
>
>
>
>>
>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..
>
>
>
>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.
>
>
>
>>
>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..
>
>
>I personally insist that multiple levels of LMM hierarchy should be allowed. I
>feel unconvinced that single depth is sufficient for different LMM scenarios
>
>
>>
>fine
>agreed
>if we specify what we mean by level of mobility management so that we
>understand what we are talking about, then maybe....
>
>
>
>I am not in favour of keeping that for reasons already explained.
>
>
>>
>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.
>
>
>>
>not sure about what is meant by that..either elaborate a little or drop..
>
>
>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.
>
>
>simplification is a contradiction to specialisation (i.e. extension). Drop.
>
>
>Theo
>
>UCL/Mobile Systems
>

---

From: James Kempf <[email-masked]>
Date: Thu, 19 Apr 2001 08:29:29 -0700 (PDT)

Hi Claude,

>> > 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.
>>
>> I assume this applies to a "domain" being something larger than one IP subnet
>> and smaller than the whole Internet, since in the first case L2 does the work
>> and in the second case the existing HA does the work.
>> My question is whether it would be useful to constrain the size and other
>> attributes a bit more.
>>
>> For instance, is this "domain" within one adminstrative domain or not?
>> The answer affects what trust models make sense for securing things.
>>
>
>Just as an example in HMIPv6, we refer as "domain" the set of nodes that are
>supported by the
>same MAP (or set of MAPs)...
>I am not sure whether this domain has to be owned by the same administrative
>entity (probably not)...
>

There are security implications of LMM. When the mobile node switches
between one LMM authentication domain and another, it will probably
have to go through  some kind of authentication exchange to change
its regional care of address. So that suggests to me that it will
probably be owned by the same administrative entity, at least for
the top level. If the LMM protocol supports multiple levels of hierarchy
(a requirement that I think is important), there can be subLMM agents
that sit under the top agent, so again they would be under the same
administrative entity.

Given the authentication requirement, I have a difficult time seeing
how the "domain" could not be under the same administrative entity.
Can you be more specific about what you had in mind?

		jak

---

From: James Kempf <[email-masked]>
Date: Thu, 19 Apr 2001 08:59:04 -0700 (PDT)

Tom,

>Firstly, a good design principle to limit the size of a "domain" is to
>think how fast handoffs this "domain" would be able to provide. In a
>humongous hierarchy with slow links between the elements of the hierarchy,
>even the localized mobility management may not provide reasonably fast
>handoffs. The size of the domain is also linked to the number of MNs the
>system must support. By splitting mega-domains, one would also gain some
>scalability for the entire system of domains, but that is merely a network
>design issue, perhaps not that tightly related to protocol design.
>

Yes, this is another reason why I think that the design must support
arbitrary levels of hierarchy. Service providers need the flexibility
to do network engineering so they can optimally lay out their
routing.

		jak