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 protected]
https://www1.ietf.org/mailman/listinfo/int-area
