Subject: RE: [mobile-ip] LMM for IPv6 requirements-Movement detection

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 28 Nov 2001 13:16:50 +0100

> 
  > I believe that if you place the LMM agent anywhere else 
  > than the AR you
  > will eventually have suboptimal routing since it will need to go to
  > 
  >   that AR ------> LMM -----> that AR ------> MN
  > 

=> I don't really get that logic, it greatly depends on
where the CN is and the network topology. 

E.g :

                    CN
                     |
                     |
                    AR
                     |
                    some routers

                     |
                     |
                     LMM
                      |
                      | 
                     AR
                      |
                     MN

Where is the suboptimality here ? The packets
will traverse the LMM router anyway to get 
to the AR.

You can play around with the topology to get 
one that will add one hop or maybe two, to the
"optimal route" but I don't think that is a major
concern. You can also add 10 hops to the optimal
route but that would be strange network design
for someone trying to use an LMM agent. 

Similarily I can make the LMM in the AR look like 
a very suboptimal solution if the two ARs 
(between which the MN is moving) are not physically
connected and are topologically 'far'. 

So it's not as simple as saying that the LMM
in the AR is more optimal. Operators will have
to be careful how they place these agents. This 
will largely depend on their type of access network, 
mobility patterns ...etc.

Hesham

---

From: Theo Pagtzis <[email-masked]>
Date: Wed, 28 Nov 2001 12:46:42 +0000

Hi Hesham,

Perhaps I did not explain clearly. 

In your schematic you assume that the LMM is in fact an AR! This is fine
but not what Mike had in mind. Mike talked about _not_ co-locating the
LMM with an AR. However, an LMM has to be behind a link if not an AR
itself. Thus, the LMM in such case MUST be behind some AR. The schematic
becomes:

            CN
             |
             |
             AR
              |
              .
              .
              .
            Internet
              .
              .      1
              |      ->
   (domain)   ARb --------           <-------- decoupling of AR and LMM
such that LMM is behind
      |       |    <-    | | 2                 that AR (since not
co-located)            
      |       |     3   ^| v                   Routing suboptimality
goes for steps 1,2 and 3
      |       .          |                     as packets have to go
through that path
      v       .         LMM                    since they are forwarded
by the LMM to the MN !
              .
              |
              AR
              |
              |   
              MN 

Now take ARb and augment it to be ARb/LMM in one single box. At the same
time get rid of the individual LMM box; thus you get rid of 1,2,3.
Wouldn't that reason for colocation offering optimality in the routing
of packets sent by the LMM to the MN?

Theo 
UCL/Mobile Systems Group

---

From: Michael Thomas <[email-masked]>
Date: Wed, 28 Nov 2001 09:39:15 -0800 (PST)

It seems that there is some amount of expectation
that colocating LMM's at the last AR will produce
a least cost routing solution, as well as be
easier to locate. As Hesham points out, it won't
necessarily be least cost, and as I pointed out,
even if it were, it's not very clear that it needs
to be least cost.

Therefore, the more interesting question is
actually the discovery question. In isolation, I
think it may be easy to handwave this away and
keep it simple, but as I pointed out earlier, this
is explicitly at the expense of not being able to
split the functionality up, which may not be a
good thing. 

That said, I don't get the sense that discovery
based on a MN's current location is unique to LMM
discovery. In fact, it seems pretty much the same
sort of problem as AR discovery when there's
multiple choices, in multiple realms, etc. It may
also be a factor with context transfer if the CT
peer isn't the first hop away from the MN. More
interestingly, I think that there's a generic
desire to be able locate content and services
which are replicated based on current location
and/or topology. 

Thus, I guess I question whether this WG really
needs to take on this work, even if we decide to
allow LMM's to be place somewhere other than the
first hop. It seems that there are a number of
ways that you could build a workable service in
the mean time from as simple as assuming that it's
colocated with the AR, to sending an HTTP request
to a web server which spews some XML at you with a
list of candidates, etc.

	Mike