Subject: RE: [mobile-ip] Revised Localized Mobility Management Requirement s

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Wed, 18 Apr 2001 12:01:45 +0200

Hi Phil

I agree with most of the proposals and in dropping requirements
from 9 onwards.

> 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

OK.

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

OK as it is for me.
However, this is applicable to HAs also so it could be generalised
and a common solution should be devised. Hesham had proposed to start
some work on this.

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

OK with your proposed change.

> 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 can't understand the purpose of this one since it is applicable
in the same way to a HA. Is there anything specific to local mobility?

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

Do you mean to say that no new messages apart from MIPv6 BUs should
be introduced? I'm OK with that.
Regarding the overhead I think we're concluding that we need to
monitor other groups (ROHC/Seamoby) and possibly provide them with
requirements from our side.

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

Ongoing (thread is MIP v6 Regional Registration - identifying re qui rements)

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

MN needs some change, so I'm OK with your proposal.

Regards
/Karim

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Wed, 18 Apr 2001 12:26:25 +0200

Hello James

A few comments below.
 	
> >[Comments were that it should be minimized, or that it was 
> ok if it meant no
> 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.

This is really a requirement on ROHC to support multiple header
compression and is independent of MIP. Also, Context transfer for HC
is not yet a settled issue from what I understand. Some say you can
reestablish context by transmitting a few uncompressed packets. The
MN still gets service so no additional latency is involved. Others
say you need CT. If CT for HC is required (depending on the ROHC/Seamoby
decisions) then this becomes a requirement on Seamoby CT to support
tunnel HC CT. Again this is applicable to tunnelling and has a wider
scope than MIP. So I believe these are not requirements on local mobility.

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

Do you mean that preference etc. should or should not be covered?
Advertising a preference for an agent is part of MIPv6.
Moving MN connections to different MN interfaces is useful but
will be put into another draft, to be generalised to work for HA also.
Why is your requirement above needed? I think it doesn't really
need to be stated as a requirement since it is obvious that the
domain of other WGs is outside the scope. Is there anything else
in particular you wanted to avoid having in the draft?

Regards
/Karim

---

From: "Glenn Morrow" <[email-masked]>
Date: Wed, 18 Apr 2001 10:18:56 -0500

Phil,

Could you plese send out a consolidation of all of the proposed
requirements, including a reworded 9 and 10+?

-----Original Message-----
From: Karim El-Malki (ERA) [mailto:[email-masked]]
Sent: Wednesday, April 18, 2001 5:02 AM
To: [email-masked]'
Subject: RE: [mobile-ip] Revised Localized Mobility Management
Requirement s

Hi Phil

OK.

OK as it is for me.

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

Ongoing (thread is MIP v6 Regional Registration - identifying re qui
rements)

Regards
/Karim

---

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

Hi Karim,

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

>I think this change could bring new functionality into local MIP mobility
>which is not necessarily needed. The local agent is basically a
>local HA. 

Actually, that is only true for HMIP. In RegReg, it is a router. 

>Adapting to topological change is in the domain of MANET.
>IMO we need some agent redundancy protocol more than a MANET protocol
>which the above points to. It may be due to my misinterpretation, but
>that's the way it reads to me. So I am happier with Phil's version
>or something along those lines.
>

Adapting to topological change may be needed if a router
goes down and the route changes to another. I think it should
be a requirement that an LMM router actually handles this kind of thing,
exactly as for a regular router.

>In any case this requirement can be applied to HAs and local agents (MAPs),
>so it could be (should be?) solved outside the local mobility draft.
>(i.e. mobility agent redundancy protocol).

Whether it applies to HAs or not is irrelvent for the current discussion.
The final LMM solution does not have to look like an HA. 

		jak

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 20 Apr 2001 18:00:13 -0700 (PDT)

> hierarchy permits distributing the problem set across that graph and a
> vechicle to provide another level of indirection as required.  This gives
> us the capability to address the scalability as Erik points out.  Load

Jim,

note my clarification that I'm not advocating that we need an
hirarchy for scalability. I'm just 1) trying to understand the
arguments/requirements and 2) sort out in my head how we can
compare the different type of fruit.
(Trading off e.g. the simplicity of no hirarchy against the flexibility
possible with an hirarchy.)

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 20 Apr 2001 18:01:19 -0700 (PDT)

> > Basically I see two approaches and I don't know how to resolve them:
> > 1. A domain might be huge (for whatever reason) hence for 
> > scaling reasons
> >    you need to be capable of having a arbirarely deep 
> > hirarchy of agents.
> 
> Why? Would this not work just as well with a single level of hierarchy,
> but one where there are multiple top level agents, i.e a distributed
> set of top-level agents which can load balance if that is a concern.

I don't know why - others are making claims like the above - I'm just
trying to understand how the different types of claims based on
different approaches to costructing requirement can be resolved.

Sorry for not making that clear up front.

  Erik

---

From: "Muhammad Jaseemuddin" <[email-masked]>
Date: Mon, 23 Apr 2001 15:31:29 -0400

> From:	Theo Pagtzis [SMTP:[email-masked]]
> Sent:	Wednesday, April 18, 2001 2:19 PM
> To:	[email-masked]
> Subject:	Re: [mobile-ip] Revised Localized Mobility Management
> Requirements
> 
> Hi Phil,
> 
> a few comments below..
> 
> 
> Phil Roberts wrote:
> 
> > OK.  Let's make another cut through these.  Seems that folks like the
> title
> > Localized Mobility Management.  I didn't retain the original numbers.
> >
> > traffic to the home agent or correspondent nodes for intradomain
> mobility.
> > 2. Regional registration shall be secure against malicious behavior from
> > visiting mobiles
> >
> 
> Perhaps on 2 we want to incorporate _any_ malicious behaviour..not just
> the
> MNs??
> 
> 
> >
> > That's about it.
> >
> > 3. Connectivity to the mobiles shall not be interrupted in the presence
> of
> 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
> 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.
> 
> >
> > [Only comment was that disruption should be minimized.  I'd like to get
> a
> 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.
> 
> 
> 
> >
> > [Several comments that it should be compatible and no dependencies
> between
> > the specs, so how about: Regional registration shall be compatible with
> fast
> > handoffs.]
> >
> 
> 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..
> 
	[MJ]  I agree that the fast handoff should comply with the LMM
requirements. Hence, I would like to propose the 
	following additional LMM requirement.

	x. LMM MAY require a MN to change IP address as a result of handover
to the new AR.

	Hence, any fast handoff solution based on LMM requirement SHOULD not
automatically assume change of IP address during handoff. The fast handoff
solution should provide a provision in its signaling messages whether or not
new AR should assign a new IP address. I think this requirement is important
to decouple LMM with fast handoff. If LMM requires MNs to get new IP address
at the new ARs, then it should be somehow (e.g. through configuring handoff
signaling message) made known to the fast handoff, hence fast handoff can
facilitate acquisition of new IP address. For example, fast handover IPv6
defines code value 1 (No change of COA required) for IPv6 PrRtAdv message,
but assumes always change of address in HI message. I think HI message
should also have a bit (like S bit defining stateful address configuration)
defining whether or not change of address is required. 

> > [One comment that this was too broad, so I'd request someone to rephrase
> it
> > in a better way]
> >
> 
> 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.
> 
> 
> 
> >
> > [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
> > agents of a move.  There is a disagreement as to whether adding
> additional
> 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..
> 
> 
> > [There was some strong disagreement on this.  Perhaps Jim or Karim could
> I personally insist that multiple levels of LMM hierarchy should be
> allowed. I
> feel unconvinced that single depth is sufficient for different LMM
> scenarios
> 
> 
> >
> > [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:
> fine
> > 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.]
> 
> agreed
> 
> >
> >
> > 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?]
> >
> 
> if we specify what we mean by level of mobility management so that we
> understand what we are talking about, then maybe....
> 
> 
> 
> > 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?]
> >
> 
> I am not in favour of keeping that for reasons already explained.
> 
> 
> >
> > 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.]
> >
> 
> 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.
> 
> 
> >
> > Received no feedback on the following proposed requirements.  Anybody
> want
> > to keep these?
> > 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: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 23 Apr 2001 19:49:12 +0200

James, 

Just catching up on email, one clarification below.

> Actually, that is only true for HMIP. In RegReg, it is a router. 
	=> That's not true. HMIP basic mode is identical to the HA, 
	but Extended mode is a HA with some modification. How is 
	RegReg different from an Etended mode MAP ? 

	Regards,
	Hesham