Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s)

From: James Kempf <[email-masked]>
Date: Tue, 24 Apr 2001 14:46:46 -0700 (PDT)

Hi Hesham,

Thanx for your response, but I think we've been through these
points a number of times, we really don't need to rehash them again. Charlie, 
Theo, myself, and one other person (whose name I've forgotten) have spoken up 
for a requirement to support hierarchy. You and Karim have spoken up against it, 
and Raj, expressing a preference for simplicity, has an inclination
against it.

Anybody else out there in SMTP-land want to express a preference?

Phil, any ideas about how to proceed?

		jak

>From: "Hesham Soliman  (ERA)" <[email-masked]>
>To: "[email-masked]'" <[email-masked]>
>Cc: [email-masked]
>Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L 
ocalized Mobility Management Requirement s)
>Date: Tue, 24 Apr 2001 23:34:56 +0200
>
>
>> Actually, no. I'm saying that we have had at least three people who
>> have given good arguments, IMHO, as to why multiple levels of
>> hierarchy might be needed. On the other side, those arguments
>> are refuted by two people who think that no hierarchy is needed.
>> Neither side is going to convince the other, both sides have
>> good arguments.
>> 
>	=> I'm not sure who you mean by the "two" people, there is definitely 
>	more (at least the authors of HMIP are) but anyway
>	after reading the discussion it really seems to me like the only 
>	two (understandable IMHO) reasons are:
>
>	1.  In future there may be a need for multi-level hierarchy. That need 
>	is not explained really. To me this is not a good reason for including
>	any feature. Ithink it makes a lot of sense of scope the problem to
>	what we know without "guessing" what might happen in future
>	and how theuse of MIP can be changed dramatically. No one 
>	knows that this is true.
>
>	2. Multi-level hierarchy localises the signalling. Let's try to 
understand 
>	what this really means. A MAP domain is as large as the amount 
>	of traffic that a MAP can handle, regardless of the number of 
>	levels of hierarchy. The signalling will always be local to that
>	domain. So I'm not really clear on the significant advantage here. 
>	We're certainly not expecting any inter-continental mobility 
>	management using HMIPv6. So careful placement of the MAP 
>	using network engineering skills and common sense is 
>	sufficient. 
>
>> What I'm saying is that we have some arguments the feature is needed,
>> so let's put it in. From Karim's last email, it sounds like we can
>> probably accommodate his concerns about multiplying failure possibilities.
>> 
>	=> At a cost. The beneft MUST outweigh the cost. This is not 
>	the case here IMO.
>
>> If we don't put it in and deployment proves that we need it, 
>> 
>	=> This is exactly point one above. 
>
>	Hesham

---

From: "Phil Neumiller" <[email-masked]>
Date: Tue, 24 Apr 2001 17:00:56 -0500

The LMM can be virtualized with SeaMoby CT, i.e. can follow the MN.
I recommend this option over hierarchical.  Its simpler and more elegant.

Thanks,

Phil

---

From: Theo Pagtzis <[email-masked]>
Date: Tue, 24 Apr 2001 15:34:02 -0700

Hi Phil,

   II don't think I have heard something new here...

The reason:

    At the moment Seamoby CT is actually acting on last hop ARs (unless I am wrong please correct me) so what you are
suggesting is bring the LMM next to the MN...

I horrifically fear that... this will be the end of LMM schemes.... WHY???? But this is CORE MIPv6... !!!!

What you want is to have the LMM in an optimal position for _both_ :

    1) low signalling
     2) reduction in transiting between LMM agents (that is the core ones like GMA/MAP/fooGMA/fooMAP/ blah blah..)

otherwise one advantage will just kill the other and at the end you will be pseudo-LMMing the MN..which is what
else...core MIPv6...

With respect to the elaboration about the LMM pool hosting router IMHO what you have just mentioned is a way of
establishing the hierarchy , and in fact _a priori_  ....very good...

that is with a minimum of 2 LMMs...I think that to me constitutes a hierarchy which DOES grow larger depending on the
degree of visibility you want to keep forward for CT since remember you do not move just forward but backwards also as an
MN... effectively over the LMM spine..

I believe that Phil's elaboration in fact shows how mutli-depth LMM actually helps CT here... :)))

Need I say more...?

Theo

UCL/ Mobile Systems

---

From: "Phil Neumiller" <[email-masked]>
Date: Tue, 24 Apr 2001 17:42:28 -0500

Hi Theo,

----- Original Message -----
From: "Theo Pagtzis" <[email-masked]>

> I horrifically fear that... this will be the end of LMM schemes.... WHY???? But this is CORE MIPv6... !!!!

Hmm.  The end-to-end principle of the global Internet clearly states that all intelligence
should be moved to the edge of the network.  The method I propose moves the routing
decision to the edge where it belong and also has proven to scale.

>      2) reduction in transiting between LMM agents (that is the core ones like GMA/MAP/fooGMA/fooMAP/ blah blah..)

The optimal position for "localized mobility management" is the first router the MN
touches.  This is what I am proposing.  How much more local can you get?
How much lowere signalling can you get?

> establishing the hierarchy , and in fact _a priori_  ....very good...
No, I have proposed a web on the edge where routers know about their
handoff candidates or learn them as needed.

> I believe that Phil's elaboration in fact shows how mutli-depth LMM actually helps CT here... :)))

I believe my elaboration is the antithesis of hierarchy, i.e. fully distributed which is the best
way for the global Internet IMHO.  I guess we differ here?

Thanks,

Phil

---

From: Theo Pagtzis <[email-masked]>
Date: Tue, 24 Apr 2001 16:14:08 -0700

Hi Phil,

    some more elaboration below..

> decision to the edge where it belong and also has proven to scale.

which edge is that? the border one or the last hop to the MN?

You see if you move the intelligence too close to the MN, from a Mobile IP perspective, you are basic acting like core MIPv6
(in terms of localisation). So the default localisation if I am an MN in MIPv6 is last hop AR, which _indeed cannot get ANY
closer..(ok for adhoc is the MN itself but that's a killer in this WG)

What we want is to localise mobility with some slack in our movement (just to put it simply). This slack is enough for us to
reduce the signalling overheads to the involved entities (HA/CNs). But we don't want to make the slack too big since the
latency will catch up with us..so the original benefit just gets negated...

> How much lowere signalling can you get?

well I think this is not Localised Mobility management at least in the light of the proposed schemes, that is...Reg^2 v6 and
HMIPv6

Why do you think you get lower signalling in such case in the first place anyway?????? Every time an MN touches a router it
will be as local as possible but this is not LMM ...this is core MIPv6 (unless I ready something wrong here..)

> handoff candidates or learn them as needed.

yes but that web has a depth of at least 2 (spans vertically not horizontally) isn't that a 2-level hierarchy?

> way for the global Internet IMHO.  I guess we differ here?

I must say that this is far from truth... by the moment you have the notion of "next possible candates" you have already
established a hierarchy structure of "previous -> next"

The above is the building block for any hierarchy in the world....since you interact between the two states and the state is
temporal to that depth of the structure..

of course you can turn your hierarchy drawing by 90 degrees and it does not look like a hierarchy anymore...

Theo

UCL/ Mobile Systems

---

From: Yogesh <[email-masked]>
Date: Tue, 24 Apr 2001 21:51:33 -0700 (PDT)

Dear James, Charlie, and all,
I would like to put forth my arguments on hierarchies from a slightly different perspective. IP is a very flexible architecture and relays on several _supporting_ mechanisms to facilitate what it does facilitate. In my opinion, its unwise to push all such hierarchy mechanisms into the "native IP" protocol and make it complicated. In fact several other protocols would have greatly benefited had there been a possibility of hierarchy in IP itself (by hierarchy I mean the mechanism that supports hierarchy, not the static address hierarchy).

Take for example routing. If there was a hierarchy maintenance mechanism inbuilt in IP, then many of the routing protocols could have been simpler. However, instead of adding hierarchy, the protocol designers came up with the concept of CIDR, to gain the benefits of hierarchy, _without_ "corrupting" the native IP stack. This of course makes routing a bit more complicated (although not too much), but it leaves IP to be a very generic protocol without enforcing any policy. Levels of hierarchy and hierarchy itself is a matter of policy and should be left out of IP.

The difficulty with hierarchy is that it requires states, and when you have states, you require reliability. IP being a datagram service cannot provide this. If the datagram nature of IP is to remain intact (which I think it should), then building a hierarchy in the native IP protocol is impossible ( if you are re-transmitting IP packets at the network layer then its no longer the original datagram model of IP. Its rather a reliable service inside the IP header. A wolf in the sheep's clothing)

In my opinion, the Mobile-IPv6 should only aim at coming up with a mobility management mask (similar to subnet mask in CIDR), and should rely on _supporting_ mechanisms to provide hierarchy. This can allow numerous levels of hierarchy, _without_ "corrupting" the IP stack. This also has the added benefit that a router can safely ignore all such mobility masks if it does not want to support this feature. I can provide more details if needed.

A little digression  from the original topic and coming back to the re-transmission mechanisms, I think Mobile-IPv6 should also get rid of all re-transmission mechanisms. In the present Mobile-IPv6 draft, a mobile node keeps sending binding update to the home agent unless it receives a response from the home agent. This is less than ideal and should be changed. A router that drops a binding update should send an explicit ICMP message saying so (this means that the binding update can no longer be the destination option, but an ICMP message). A mobile node should send binding update only once, and after it has detected movement. All such error report ICMP messages should be reported to the upper layer protocol, which could decide the best strategy (the argument that this will break the existing applications is bogus since IPv6 itself will break all existing applications. If one can move to IPv6 from IPv4, then once can also catch these ICMP messages.) The benefit is that an uppe!
!
!
!
r layer protocol is probably a better judge of what has to be done next (possibly though human interaction) as opposed to a dumb piece of software that will keep retransmitting for ever.

I read these e-mails in my free time, more as a hobbyist, and I will not be able to respond to your comments during my working hours (8:00-5:00 central time). Hope that's fine.

Thank you for your time.
Best Regards
Yogesh

  James Kempf <[email-masked]> wrote: 
Hi Hesham,

jak

>From: "Hesham Soliman (ERA)" 
>To: "[email-masked]'" 
understand 
> => This is exactly point one above. 

Swami Prem Yogesh
Research Engineer
Office:                          Home:
Nokia Research Center            826W, Royal Lane
6000 Connection Dr.              #392
Irving, Texas-75039              Irving, Texas-75039 
Tel: 972-374-0669                Tel: 972-831-9589

---------------------------------
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices

---

From: Wolfgang Schoenfeld <[email-masked]>
Date: Wed, 25 Apr 2001 12:59:25 +0200

Yogesh,

(I'm happy to have found in your contribution some kind of a SYNCH point 
in this interesting ongoing discussion on Hierarchical Mobility Management.
Sorry for skipping many of the others - it's too much.
Living in time zone GMT-1 somehow out-of-SYNCH, 
I'm trying to run through about 20-30 contributions each morning
which is quite hopeless.)

I think I understand your point:
By dividing addresses, one arrives at a hierarchical address space
which, applying the divide-and-conquer principle, makes routing more efficient
(i.e. routing algorithms are faster).
However, this notion of "hierarchy"
is different from that considered for Hierarchical Mobility Management.
Let me shortly explain why I think this is so.

Mobility is managed by a set of "mobility agents" (HA, FA, MAP, ...),
their service is to forward packets to hosts
currently not a the position indicated by their address.
You may view the set of mobility agents as a "mobile network"
where the links are IP paths ("tunnels").
This is very similar to Virtual Private Networks and the like.
The question is now which topology this mobile network has.

For classical Mobile IP, it is a "clique" (in the graph-theoretic sense,
i.e. any FA is directly linked (via a single tunnel) to any HA.
In Hierarchical Mobility Management (whichever proposal you consider),
the topology is not a clique, it is a "tree" (again in the graph-theoretic sense)
with a distinguished "root", sometimes also called a "hierarchy".

But note that this makes sense with a flat (i.e. non-hierarchical)
address space, with a two-layer hierarchy as in classical IP,
and with any other number of layers.
No matter how many layers you have,
the topology of each layer may be a clique, a tree or anything you prefer.
The two notions of "hierarchy" are independent of each other.
Maybe, one should reserve the word "hierarchy" for the address space
and talk of "Tree-like Mobility Management"
in order to avoid confusions.
But I know - terminology tends to (and should) freeze very rapidly.

Let me finish by mentioning that a question more critial 
than the height of a mobile network is whether it should be tree-like at all.
Note that IP is not, for various well-known reasons.
But starting with trees is a good practice since
topologies with weaker or no restrictions are much harder to handle.

Hope this helps (instead of confusing)

Wolfgang
-- 
Wolfgang Schoenfeld, GMD-IPSI, Dolivostr. 15, D-64293 Darmstadt
Office: +49-6151-869-865 FAX: -6847 Mobile: +49-174-7093455

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 26 Apr 2001 07:36:46 -0700 (PDT)

Theo,

> I must say that this is far from truth... by the moment you have the notion
> of "next possible candates" you have already established a hierarchy
> structure of "previous -> next"

Now I'm really confused.
I've been assuming that the hierarchy that we've been discussing is
common for a number of MNs (perhaps all) in some particular part of
the network.

But your previous->next relationship is a function of the individual movement
patterns of a particular MN thus it might be different for all MNs (at least
if you track enough of their history using a chain of prev->next
relationships).

That sounds like the "update the previous FA" scheme in MIPv4 which
doesn't look like a (shared) hierarchy at all.

   Erik

---

From: Theo Pagtzis <[email-masked]>
Date: Thu, 26 Apr 2001 08:49:51 -0700

Hi again Erik,

> doesn't look like a (shared) hierarchy at all.

Ok,

   the hierarchy implied by the "previous->next" relationship can either be
generic...ie all mobile nodes that are participating in a admin domain ...or it
can be specific that is per MN by refering specifically to generic relationship.
It is only the per-MN behaviour that is instantiated on the second.

In your understanding (above) you happen to see the second. The first though is
ALREADY there.

In the first you refer to a packet that goes from the previous LMM-aware routing
element to the next..

In the second you refer to a packet for a _particular_ MN that goes for the last
hop previous LMM-aware routing element to the next..

So you have correctly assumed a common hierarchy for all MNs here..you just pick
a snapshot for the individual MN...

It is like the analogy...I can see the map of the roads...but at the same time I
can see my route on that map.

Multicast has said it in a different ..perhaps clearer way...incoming and
outgoing interfaces...but it is the same thing...stil hierarchy..

I only wanted to show that the building blocks for a hierarchy are in principle
there...it is just a matter of tying them together...in an admin domain

So I am definetely refering to a shared hierarchy...one which an LMM scheme
could instantiate differently than another depending on how it wants to see
it...

Theo

UCL/ Mobile Systems

---

From: Gopal Dommety <[email-masked]>
Date: Thu, 26 Apr 2001 12:20:17 -0700

Hello:

Going through the Advantages and disadvantages of  of LMMs or LMAs it might 
be clear if multiple levels of hierarchy are needed.

Advantages:

1. Localizes  signalling (Localizing signalling does not mean reducing 
signalling)  For localizing signalling one level of hierarchy is enough, if 
we assume that the cost to send a message within a domain is the the same 
irrespective of the nuber of routed hops.

2. Could potentially reduce handoff delay. Handoff delay consists of two 
components that are relavent to this discussion
1) transimssion delay  2) processing delay. Unless over a low speed link 
transmission delay is not a major factor. Processing delay
is what will hit you the most.  Multiple levels of hierarchy add to the 
processing dealy and so could actually increase the handoff delay.

3. Reduces the need to update the caches in the CN or change the VPN tunnel 
endpoint. For this also one level of hierarchy is enough.

Disadvantages of LMMs or LMAs

1. The amount of processing for the data path increases. Every data packet 
has to traverse these hierarchies. so multiple levels of hierarchies are 
not necessarly good.

2. The points of failure increases. Increases in the levels of hierarchies 
are not necessarly good.

So multiple levels of hierarchy may not be needed if the cost of 
transmitting/packet is not affected significantly by the number of routed 
hops it traverses (who knows one day slow routing might be back in fashion).

I am not against multiple hierarchies, if the simplicity of the solution is 
not comprimised. I personally think it is very
easy to have muliple levels of hierarchy (see 
draft-dommety-mobileip-lma-ipv6-02.txt).

Thanks
Gopal

---

From: Theo Pagtzis <[email-masked]>
Date: Thu, 26 Apr 2001 13:18:35 -0700

Hi Gopal,

some comments below

> irrespective of the nuber of routed hops.

Fortunately or unfortunately it MEANS reducing....since the localisation of
multiple movements does not translate to equal number of updates to CNs and
HA...This is a given ages ago...

> processing dealy and so could actually increase the handoff delay.

I would not touch on handoff delay..unless you want to get the fast handoff
proponents say that LMMs are not handing off fast enough so they are not good..We
definetely don't want to reach handoff levels equal to core MIPv6 but I would not
go as far as implying that an LMM is by virtue handing off fast...in that spirit
any LMM is not handing off fast by default..however it is definetely faster than
core MIPv6

> endpoint. For this also one level of hierarchy is enough.

you have just contradicted yourself with your first argument...I think I don't
need to explain this one..

> has to traverse these hierarchies. so multiple levels of hierarchies are

yes this is a classical tradeoff against resiliency...but we knew that ..perhaps
resilency-free and fault-INtolerant systems may also come into fashion...

> 2. The points of failure increases. Increases in the levels of hierarchies

well we know from fault-tolerant systems that the probability of having two (say
LMM-aware) autonomous entities failing at the same time is exponentially SMALL and
decreases with the number of the probable failing entities tending to zero. This
is the basic principle of backup systems ...otherwise critical systems would not
exist..

So the above is becoming as probable as 10E-5 or something like that...in that
sense there is a minute possibility, definetely not normative, that it could not
be good but then forget resiliency anyway since you can get so pedantic...

> hops it traverses (who knows one day slow routing might be back in fashion).

This of course goes for the existence of LMM also...if in core MIPv6 such cost is
not significantly affected then forget LMM just hack core MIPv6... What I am
saying is that we start considering BIG IFs which I don't think reflect upcoming
scenarios...remember murphy's law...by the time a system has been specified...is
obsolete...you want to leave multiple hierarchies out...be my guest...we will have
to devise yet another extension...

All I am saying is that a multi-level LMM hierarchy can only benefit ANY LMM
scheme for upcoming realistic mobility scenarios...like IPRANs..

Theo

UCL/ Mobile Systems

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 26 Apr 2001 13:15:18 -0700 (PDT)

> So you have correctly assumed a common hierarchy for all MNs here..you just
> pick a snapshot for the individual MN...
> 
> It is like the analogy...I can see the map of the roads...but at the same
> time I can see my route on that map.

Sure, but the road network doesn't pretend to be a tree-like (i.e. what
I think we mean by hierarchical) structure (unless you are referring to
the meta structure of national roads vs. regional vs. local vs. cow-paths
as the tree-like structure).

Or concretely, if MN1 moves from LMMa to LMMb and MN2 moves from LMMb to
LMMa, what does the common tree look like?
Is LMMa a parent and a child of LMMb?

> outgoing interfaces...but it is the same thing...stil hierarchy..

Yes, for one sender - there is no IP multicast tree that is common for
all senders. I think this is analogous to one tree per MN.

  Erik

---

From: Theo Pagtzis <[email-masked]>
Date: Thu, 26 Apr 2001 14:24:15 -0700

Erik,

  I don't want to get into the design of roads but at the very least a main road
branches off to many streets, a main freeway branches onto many main roads, blah
blah blah.. To me it looks like a hierarchy (could also be tree-like) where the
main entity is a parent of sub-entities..but anyway ..it was only an analogy..if
you don't like it ..forget it..

> Is LMMa a parent and a child of LMMb?

same to both...what is the point here?

> all senders. I think this is analogous to one tree per MN.

right but I am looking now at the hierarchy from the LMMs perspective not the
MNs...

Theo

UCL/ Mobile Systems

---

From: Jim Bound <[email-masked]>
Date: Thu, 26 Apr 2001 22:37:39 -0400 (EDT)

I agree with these.  But I think if the hierarchies are defined well the
traversals can be optimized.  In my last example when I leave the office
to my car to the bar to the taxi to the home the path for each point is
defined and so is all the signaling.  

Now sure someone could build this poorly as the current VPN/LT2P networks
in some cases I see today and it will run poorly.  We can only prevent
users and vendors from doing dumb and evil things to networks to some
degree as protocol designers.  If we try to catch every case we will all
be here till 2003 discussing it.

As Charlie put it mails ago we can have one, two, three, etc.. or none of
hiearchy but to not permit using indirection and distribution of task in
Mobile IP Wireless is not wise it appears to me.

/jim