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

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

Hesham/All,

Excuse the mess of the previous schematic. Ascii art and text don't mix
in resizable editing spaces.
So there it is again:

             CN
              |
              |
              AR
               |
               .
               .
               .
             Internet
               .
               .      1
               |      ->
    (domain)   ARb --------           
       |       |    <-    | | 2               
       |       |     3   ^| v            
       |       .          |             
       v       .         LMM                
               .
               |
               AR
               |
               |
               MN

Decoupling of AR and LMM such that LMM is behind that AR (since not
co-located)
Routing suboptimality goes for steps 1,2 and 3 as packets have to go
through that path since they are forwarded by the LMM to the MN !

Cheers

Theo
UCL/Mobile Systems Group

Theo Pagtzis wrote:
> 
> 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
> 
> "Hesham Soliman (ERA)" wrote:
> >
> >   >
> >   > 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 13:21:25 +0000

Hi all,

Having seen the latest version of the fast handoffs draft, I see that
the protocol leans now towards predictive handoffs that was not the case
for the previous 2 versions)  which I am already addressing in my
proactive mobility proposal:

http://search.ietf.org/internet-drafts/draft-pagtzis-seamoby-proactivev6-00.txt
with schematics that 

can be found in 

http://www.cs.ucl.ac.uk/staff/t.pagtzis/papers/draft-pagtzis-mobileip-proactivev6-00.ps
or
http://www.cs.ucl.ac.uk/staff/t.pagtzis/papers/techRep20010103.ps.gz

I believe I could contribute to the fast handoffs draft by augmenting it
with existing text from my proposal with respect addressing state
preconfiguration as well as other issues that I would be addressing
otherwise in my updated version. Would such contribution be encouraged
by the authors of the fast handoff draft?

Theo
UCL/Mobile Systems

PS. BTW the argument that my proposal was very long is not really an
excuse for not returning comments since as I can see other proposals
much longer and complicated. Additionaly, I can 'see' that people have
read the proposal. That means that any comments would be welcomed.

---

From: Gopal Dommety <[email-masked]>
Date: Wed, 28 Nov 2001 08:55:18 -0800

Theo,

This version has BETH integrated into it and also renames the earlier method.

We would definetly welcome any contributions that enhance Fast Handoffs.

Thanks
Gopal

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 28 Nov 2001 15:03:48 -0800

Hi Theo,

Actually, as far as leaning towards "predictive handoffs", this new
version has no difference. I think the new terminology "predictive"
makes you think that way.

This is kind of misleading. Both BETH and rest of FMIPv6 require
some level of "anticipation". The protocol signaling has to be
completed before L2 handover is complete. Since BETH has
zero L3 signaling, the amount of required anticipation is less.

Of course any positive contribution is welcome. It is just that
the protocol is same as before, except addition of BETH.

alper

----- Original Message -----
From: "Theo Pagtzis" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, November 28, 2001 5:21 AM
Subject: [mobile-ip] fast handoffs v3 draft

> proactive mobility proposal:
http://search.ietf.org/internet-drafts/draft-pagtzis-seamoby-proactivev6-00.
txt
> can be found in
http://www.cs.ucl.ac.uk/staff/t.pagtzis/papers/draft-pagtzis-mobileip-proact
ivev6-00.ps