Subject: [Int-area] Re: draft on network-based mobility management

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 06 May 2006 13:15:08 +0200

Hi,

  Some early comments on this below.

Regards,

	Henrik

on 2006-05-06 00:21 Soliman, Hesham said the following:
> Folks, 
> 
> This is a draft on the netlmm efforts that have started recently. I
> appreciate
> any feedback on this. The intention is to start a discussion about the
> work.
> 
> http://www.ietf.org/internet-drafts/draft-soliman-netlmm-harmful-00.txt

Overall:
 	
 	The draft starts out drawing a reasonable background for the
 	IETF mobility work in section 1, and then goes on to discuss
 	problems with the problem statement in section 2.  To me the
 	representation of the problem statement is biased, and presents
 	the author's subjective view on the problem statement.  This
 	perception of the problem statement seems to have grown out
 	of the more explicit concerns raised later in the document.
 	In section 3, problems with the NetLMM approach is described,
 	and here I find that it seems that some of the basics of
 	NetLMM have not been sufficiently well communicated that they
 	have been seen clearly by the author.  Details below:

Section 3., para. 1:

>    The NETLMM approach is described on a high level in the current
>    charter. Simply put, NETLMM expects to place a mobility anchor point
>    in the visited network, which acts like a home agent. The mobile node
>    will be configured with an address on the anchor point's link and
>    keep it for the time it is located in the NETLMM domain. The anchor
>    point binds the mobile node's address to its current default router
>    (or Access Router, AR). Hence, whenever the mobile node moves, the
>    new AR will bind its address to the one allocated to the mobile node.
>    Tunneling is done between the anchor point and the AR.  Therefore,
>    the AR's address can be seen as a Care-of address for the mobile
>    node. On a more detailed level, several minor changes can be made;
>    however, the overview above gives the general idea.

	This description is in part incorrect:
 	1. The mobility anchor point *does not* act like a home agent.
 	
 	It is important to understand that the basic functionality of a
 	NetLMM domain is to provide dynamic intra-domain routing, and if
 	you disregard scaling problems, this functionality could be
 	provided in part by use of e.g. OSPF.  That the proposed internal
 	architecture happens to have a local mobility anchor node (or
 	nodes) does not mean that these are like a home agent.  They are
 	not.
 	
 	2. The introduction of the term 'Care-of address' is misleading.
 	A node attaching to a NetLMM domain gets an address by usual
 	means, just as when attaching to any other internet subnet.
 	The exact mechanism by which the route updates are done is
 	immaterial to this, and most importantly, there is no other
 	address involved which is associated with the node, that
 	would warrants the term 'Care-of address'.  The node's IP
 	address is simply the node's IP address.

Section 3.1., para. 0:

 3.1. Applicability to different link layers

	Good discussion, apart from the sligth bias towards NetLMM-
 	bashing.

Section 3.2., para. 3:

>    According to this definition, local mobility may take place between
>    two ARs connected to two different radio technologies. This poses a
>    serious problem for any network-based mobility management scheme. A
>    mobile node may wish to move some or all of its traffic to one access
>    technology. However, a network-based mobility management scheme
>    cannot be aware of the mobile node's preferences and may force one
>    technology for all of the mobile node's ongoing, and possibly future,
>    connections. This situation can also cause operators to force a node
>    to be connected to a particular technology, which may not be the
>    preferred choice for the mobile node. This situation is not addressed
>    in the current charter or work done so far in the NETLMM WG.

	So far, the observation is correct.  However:
 
 							        A
>    network-based mobility management scheme cannot handle this situation
>    in a reliable or deterministic manner. The flaws with a network-based
>    approach in this situation are:

	This part is incorrect.  There is no inherent reason why a network-
 	based mobility management scheme may not handle this in a
 	deterministic manner, based on policy or heuristics.  Examples:
 	move to the a) link with highest basic bandwith; or b) the
 	link with highest user policy ranking; or c) link with lowest
 	cost; or indeed the link determined by any evaluation function
 	using these and other criteria.  As for the reliable manner,
 	reliability is related to quality and determinism, and if the
 	link quality is made part in the evaluation, this may also be
 	covered.  WHAT IS NOT given is that the resulting choice is
 	*optimal* from a user viewpoint.  But consider that given the
 	posited availability of both network-based and host-based mobility
 	support, the mobile may very well have the option of establishing
 	a different ID for the different access types, and use host
 	mobility to switch between these...

Section 3.2., para. 4:

>    (a) If one accepts that global mobility management is going to be
>    Mobile IP based then one accepts the idea that the end node should be
>    able to select between links to different administrative domains (or
>    network operators). Links to different operators can of course be of
>    the same or different technology. If this is a good thing, why do we
>    not want to provide the host with the same flexibility when different
>    links/technologies are available under the same local domain?

	But we do!  There's nothin inherent or planned in NetLMM to
 	prohibit this!  On the contrary, it is quite likely that this
 	will be the most common way of deploying NetLMM in combination
 	with host-based mobility.

Section 3.2., para. 5:

>    (b) Multi-homed end nodes will at some point be able to use different
>    links for different applications depending on link
>    quality/capabilities. It is easy to see that the level of complexity
>    increases significantly when taking into account flow movement. The
>    proliferation of applications and possibility that the end node is
>    enabled with interfaces unknown to any given network-based mobility
>    scheme makes this a difficult problem. How would a network based
>    mobility management system know which flows to move to which link?

	It wouldn't.  And, more to the point, nobody has claimed that
 	it would or should!

Section 3.2., para. 6:

>    (c) Since the coverage area of different technologies is likely to
>    overlap, the decision to use one technology or the other becomes a
>    policy decision. The end nodes will have to deal with making such
>    policy decisions between different networks and they should be able
>    to make the same decisions between different technologies. The
>    network operator should define metrics (like cost, loading etc) but
>    it should let the end host decide what to do. This is not a
>    philosophical point; there are concrete reasons why the host needs to
>    make this policy decision. For instance, the host is most
>    knowledgeable about the applications it runs and what radio
>    technologies are best suited to those applications.

	Agreed.  And nobody has claimed otherwise!!

Section 3.3., para. 1:

>    End to end signaling is important and necessary in order to maintain
>    the end to end design philosophy of the Internet. When it comes to
>    localized mobility management, the end to end concept remains crucial
>    to the robustness of the mobility management mechanism. Handovers are
>    uncertain by nature and in some cases the new attachment point may
>    change during the handover process. This is due to the volatile
>    nature of the radio link at cell borders, which is typically the case
>    in most cellular technologies. It is also known that mobile nodes can
>    experience ping-pong movement, or cellular thrashing, during
>    handovers; i.e. the mobile node may quickly move back and forth
>    between two different access points for a short period of time. A
>    network-based mobility management protocol can cause the mobile
>    node's traffic to be routed to the wrong AR, i.e. the AR that the
>    mobile node was expected to move to, but did not. This can result in
>    packet losses. In contrast, if the IP mobility signaling is initiated
>    from the mobile node, it would be able to discover that the next AR
>    has changed and inform the network of its new choice. When the action
>    is taken by the mobile node it can be done in a quicker manner for
>    predictive or reactive handovers.

	I don't see that this follows.  What would make it quicker,
 	when it has less predictive ability than the network, and
 	longer signalling paths?

Section 3.4., para. 1:

>    One of the unwritten motivations of NETLMM is that some operators and
>    vendors "believe" that the network must control the handover. Lets
>    explore this belief a bit more. Specifically, what does network
>    control mean? Why is it needed? And how does a network-based mobility
>    management mechanism allow for more control?

	Since this is an allegation of unwritten motivation, it is of
 	course hard to prove otherwise.  I believe this is more in the
 	mind of the author than in the minds of those who work on the
 	NetLMM design.
 	
 	But there is a MUCH deeper danger here than mis-representation
 	of motivations; and that is to perpetuate the either-or dichotomy
 	between host-based and network-based mobility support.  Looking
 	closer at the respective advantages of network-based and host-based
 	mobility, we find that in their pure state, both have clear draw-
 	backs, which best can be complemented by the other.  So the
 	title of the current section paints a picture of strife, where
 	the optimal solution is cooperation.

Section 3.5., para. 3:

>    The above situation is more difficult to support when a network-based
>    mobility management mechanism is adopted. In particular, the
>    following problem arises. An anchor point may be required to setup a
>    security association with any access router in the network at any
>    time. A network administrator is suddenly forced to consider the
>    impacts on memory capacity and the speed of the security association
>    establishment at the critical handover time. This situation does not
>    arise when the signaling is done end-to-end because in this case only
>    one security association is needed, regardless of the mobile node's
>    location. Furthermore, the security association does not need to be
>    established during the critical handover time.

	And neither does it in a NetLMM case -- the most natural to
 	me would be to pre-configure these, not to try to do it ad-hoc.

Section 4., para. 1:

>    The endorsement of more than one alternative for the same problem
>    needs to be strongly justified. Unfortunately this was not the case
>    for the NETLMM work in IETF. Both NETLMM BoFs clearly stated that the
>    WG will exclude the mobile node from the IP mobility management
>    signaling, which is not a typical requirement related to a problem,
>    but one designed around a solution. This premise was challenged in
>    both BoFs. Despite lack of clear consensus, the IESG decided to form
>    the WG. The problem here is two-fold: How do we decide on new WGs?
>    And what is the impact of solving the same problem in two different
>    standards? Both questions are not specific to the NETLMM WG, however,
>    this WG illustrates the need for a uniform and predictable process.

	This argument seems to be based on the idea that there exists
 	an alternative to NetLMM within the IETF.  This I don't see,
 	maybe because I see host-based and network-based mobility
 	support as complementary technologies, and mutually beneficial.

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 8 May 2006 17:27:13 -0700

> > Well in the sense that it binds one relatively stable address to
 > > another. 
 > 
 > No.  It does *not* bind one address to another.  It updates the
 > routing rules for an IP address - there's no two addresses here to
 > bind together.

=> See my answer below.

 > 
 > > Of course it's not exactly an HA. 
 > 
 > Right.  Except it seems you're still sticking to the idea that it's
 > 'kind of' an HA.  But again: it's not.
 > 
 > > Again, it's a simple analogy to the anchoring mechanisms in MIP.
 > > I'd rather not delve into a terminology debate at this 
 > point, I think
 > > we both understand the overall picture of the NETLMM 
 > approach described
 > > in
 > > the charter.
 > 
 > Sorry, Hesham.  From the whole content of the draft, the 
 > basic problem
 > I see is that it seems you don't understand the overall picture.  So
 > please don't try to dodge this as you do above - I think you need to
 > take a second look at this, and re-evaluate the 'simple 
 > analogy to the
 > anchoring mechanisms in MIP'.

=> Like I said, I didn't think it's the real issue in the draft but 
since you persist, and since I don't like to be a "dodger" I took a 
second look at the charter since I'm not aware of any WG doc. 
Here's an excerpt:

  The network-based localized mobility management protocol will conform 
  to the following framework. Mobility anchor points within the backbone

  network maintain a collection of routes for individual mobile nodes. 
  The routes point to the access routers on which mobile nodes currently

  are located. Packets for the mobile node are routed to and from the 
  mobile node through the mobility anchor point. When a mobile node 
  moves from one access router to another, the access routers send a 
  route update to the mobility anchor point.

So, it's an anchor point that "forwards" the MN's traffic to the AR.
If the MN moves to another AR then a "route update" is sent. Since this 
anchor sends the MN's traffic to an AR that I presume is potentially
several
hops away, is there some kind of encapsulation going on here? IP in IP
perhaps?
Is there some binding between the outer address and the inner address? 
If there isn't then how does this "forwarding" happen?

 > >        As for the reliable manner,
 > > So you're jumping over many assumptions here. You're assuming that
 > > both host and network mobility can coexist. On the surface 
 > this sounds
 > > conciliatory and ideal, but I'm afraid 
 > > it's not practical.
 > 
 > Heh!  As I've seen it in action, you'll have hard time sweet-talking
 > me into closing my eyes to this.  I've seen the benefits of running
 > both in parallel.  If you want to close your eyes to the 
 > mere possibility,
 > go ahead, but don't expect me to agree.  It is indeed *very* 
 > practical.

=> It depends on what you mean by "both in parallel". I'm 
comparing a *host-based LMM mechanism* to an exclusively *network-based
LMM mechanism*. Have you run those two in parallel? I don't think it
would make sense to do that.

 > > Having NETLMM *excludes* the host's ability to
 > > communicate with a local anchor. Hence, when you say host 
 > mobility is 
 > > possible you must mean a host-HA relationship. This isn't efficient
 > > enough
 > > for the types of handovers, flow movement or multihoming 
 > decisions that 
 > > a host might make. This also assumes that the overhead of 
 > having the
 > > remote
 > > HA is acceptable. It's not acceptable in many cases.
 > 
 > Oho!  Please be very aware that here you're *not* arguing host-based
 > mobility versus network-based mobility; you're arguing one particular
 > type of local mobility-support versus another type.  

=> Of course I am! I'm raising concerns against network-based
LMM and my reference is the existing host-based LMM. 

   THIS can be a
 > very interesting discussion indeed, but it is *not* a host-based
 > mobility versus network-based mobility discussion, which is what
 > your draft seems to be about.

=> Host-based LMM Vs NETLMM. The entire draft addresses LMM
exclusively.

 > > I really think you should reconsider this assumption. You seem
 > > to assume that an inter-access technology handover is host-based 
 > > while not limiting the definition of a mobility domain to a single
 > > access technology. You can't have it both ways :)
 > 
 > Of course I can.  There are more degrees of freedom here than can be
 > captured in the simple view that 'since A is able to handle inter-
 > access mobility, B has lost the freedom to handle it'.  Both the set
 > of possible radio technologies, and the set of potential providers
 > of such are open-ended, and provide for much richer possibilities
 > than that.

=> So let's discuss those possibilities. 

 > > Same answer. Check the definition of local mobility. Not 
 > > my definition!
 > 
 > I don't know what you want to say with this.
 > 
 > I'm trying to show that your fears about NetLMM is largely 
 > unfounded, and
 > it seems to me that you're wed to your fears, and won't let 
 > go of them
 > even if they're unfounded.

=> I'm not talking about fears, I'm raising technical concerns. 
If they are unfounded then tell me why. Simply saying that they're
wrong or negating them without explanation doesn't help. For example,
my answer above refers you to the definition of "local Mobility", which
says nothing about whether the handover is within the same access tech
or a different one. Your response talks about my unfounded fears. That's

not progressing a discussion.

 > > It's quicker because of most link layers the mobile knows
 > > first what it's best candidate will be. The mobile
 > > is in the best position to measure signals from other basestations
 > > to itself. So of course it will know first.
 > 
 > What you're describing here is not predictive capability, 
 > but reactive:
 > measuring what is.  For the access technologies *known to 
 > it* a network
 > may be predictive, where a mobile node has a harder time of 
 > it.  

=> I don't see how it is possible that the network can predict
better than the mobile since every link I've seen that is capable 
of this prediction bases such prediction on the information received
from the mobile. My point in that particular paragraph was about 
the uncertainty of movement during handovers and how the mobile 
node can react quickly to those changes. The handover itself is 
predictive because actions are taken before the mobile moves. However,
I was concerned with reactions to certain changes in signal strength, 
availability ...etc that can happen later in the handover process, i.e.
potentially after the network had already decided that the mobile is 
moving to a particular link.

  Of course,
 > for access technologies outside those known to a network, it 
 > will know
 > nothing (unless the mobile tells it about those).

=> Sure, but whether an access network is "known" is itself 
another big question. "known" should mean "known and functional".
An AP might be present, responds to pings, but it's radio isn't 
functioning. So a server in the core would certainly know less 
about the state of the radio than a mobile which can detect whether
an AP is funtional, available, limited ...etc.

 > 
 > So, my question above stands:

=> I tried to answer above.

 > > It was a spoken motivation that I heard for many many people
 > > over the last 5 years. So it's not something I made up. 
 > 
 > Since the NetLMM work is *much* younger than 5 years, I don't know
 > what other efforts you're overloading on the current one here.

=> Ah, the WG is very new of course, the culture of "network control"
is very old and we had these discussions for many years in MIP. Some 
of "no mobile involvement" approaches are even reflected in certain
modes of FMIPv4 and v6. 

 > > All I'm asking for is a clear and coherent problem statement that
 > > justifies what you claim above. The claims in the current statement
 > > are frankly well below the average engineering common 
 > sense. I really
 > > hope someone can show me how these claims make any sense 
 > or are backed
 > > by
 > > any data. Simply saying that "each approach has its 
 > problems" is not
 > > good
 > > enough or technical enough for me to agree.
 > 
 > Fine.  So comment on the problem statement.

=> There is a whole section on it in the draft. 

 > > I don't think this is feasible in a practical deployment. 
 > I've worked
 > > on and seen these networks deployed. Imagine a situation 
 > where you have 
 > > a 100 - 200 local agents and 10 - 20 K basestations, each 
 > containing an
 > > AR. Now 
 > > try to manually configure SAs between all ARs and all anchors and
 > > maintain
 > > those SAs, i.e. roll the keys ....etc I don't think you'll 
 > find many
 > > people wanting
 > > to manage things this way.
 > 
 > No.  Of course you don't want to manually manage 20 K 
 > base-stations' SAs.
 > But that doesn't mean that you can't pre-configure the relationships
 > using other means than manually handling each of them.  The point is
 > that you wouldn't do it ad-hoc.

=> Not sure what you mean by "ad-hoc". You can certainly pre-config
with Certificates ...etc but the point raised in the draft was two
fold (assuming that you agree manual config is not practical):
 A. You don't want SA establishment during handover because it adds
    time. Since we don't want permanent NxM SAs (no of ARs times number
    of anchors), we have a timing problem. This is specific to NETLMM.

 B. It's not easy to deduce how many SAs are needed in the anchor based
    on the number of MNs it can support. This is a dimensioning
challenge
    which only exists in NETLMM.

Hesham

---

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 9 May 2006 12:07:52 -0700

> 
 > I have to confess that I fail to understand how on one hand 
 > it can be 
 > unfeasible to manage SAs between 100-200 local agents and 
 > 10-20K base 
 > stations, while on the other hand there are mobile operators which 
 > manage on a daily basis SAs with tens of millions of subscribers.

=> Well, the SAs you're referring to are preconfigured and predicted
easily. A network operator knows exactly how many subscribers he has,
gives each of them a shared secret and scales the AAA infrastructure
accordingly. 
The SA is set at bootstrap and not on the fly during handover time. See
my two 
points in the last email to Henrik for more details on this. The SAs you
refer 
to are also many-to-one and not many-to-many.

Hesham

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 10 May 2006 07:45:08 -0700

> >   "You're assuming that both host and network mobility can coexist.
 > >    On the surface this sounds conciliatory and ideal, but 
 > I'm afraid
 > >    it's not practical."
 > >
 > > is clearly incorrect.
 > 
 > In practice local and global mobility schemes co-exist. 

=> Of course. 

   For 
 > example, MIP 
 > can co-exist with 802.11 handoff schemes (e.g. 11i, 11r).  
 > So I think that 
 > it will be required to point out specific co-existence 
 > issues, rather than 
 > asserting that the generic co-existence problem has no 
 > practical solution. 

=> Please see my response to this point to Henrik. I don't think
IP-based NETLMM and host-based LMM can coexist. Of course host-based
LMM and link-layer mobility in general coexist everywhere. 

Hesham