Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Fri, 12 Jul 2002 18:10:25 -0500

Hello Vijay,
Please find my inline reply. I will only be
able to answer your subsequent emails tomorrow. 
regards,
ajoy

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]]
Sent: Friday, July 12, 2002 5:16 PM
To: Singh Ajoy-ASINGH1
Cc: 'James Kempf'; Rajeev Koodli; [email-masked]
Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions

hi Ajoy,

Singh Ajoy-ASINGH1 wrote:
> 
> Hello Vijay,
> You have not answered my question yet. 

is this a trick question? we do the demo in a lab. in our lab 
and in connectathon, we trigger a handoff from userland (an 
ioctl call). you cannot trigger a fast handoff by moving 
5 feet. all 802.11 cards see all access points.

> BTW, I do not see
> any difference in BETH as well as anticipated handover
> scheme in this respect. Both of them need L2 triggers
> to enable fast handoff. In case of anticipated handover, we need
> L2 trigger either at MN or oAR. Please find the following
> text from the current fast handoff draft:

this is not a fair comparison. we are not talking about the same 
L2 triggers now. 

Ajoy-> Why not? In what way network initiated L2 trigger of anticipated
handover is different from BETH L2-ST? 

I have problems with L2 triggers where the access point sends
some information to the access router about the MN, without
the MN sending an IP message. (because, this is specific to 
each link layer and is not even available in 802.11). for 
example the Target Trigger (which is needed by BETH) supplies
the newAR with the L2 address of the MN.

Ajoy-> Target trigger will be suitable for cellular 
networks.  BTW, even in case of WLAN, you can receive
L2-TT trigger at nAP. L2TT (Re-association Request) can 
provide nAP the L2 address of the oldAP as well as L2 
address of the mobile node. If we implement FA function 
at AP, then this becomes an implementation issue. 
If not, then you need to define some protocol between 
AP and AR which can be addressed in separate document. 
I understand that Re-Association Request is 
not as good as pre-trigger, but this will provide 
you lot better performance than standard Mobile/IP.

my 802.11 access point cannot supply the L2 address of the MN to the newAR.
the 
Target Trigger also supplies the L2 address of the oldAR to the
newAR. how does this happen (unless the two 802.11 APs talk
to each other)

in the anticipated part any information obtained (for setting up
the tunnels) is through IP messages.

and when I said I use one L2 trigger, I use the a trigger which
is internal to the MN and it just says "hey, I have an L2 connection".
in response to this, the MN sends either a FNA or NA. whereas the
Link Up trigger required by BETH not only says "hey, I have an L2
connection", but also "hey, heres the L2 address of the newAR".
cool...

Ajoy-> MN L2 trigger is only used for Mobile Initiated handover. 
What happens when handover is network initiated ?

I am not saying you cannot have these triggers. cellular links have
these triggers already. but there is no standard which works for
all link layers. therefore we need a protocol with only IP messages
to do a fast handover. 

Ajoy->IP layer protocol only works for Mobile Initiated trigger. It does
not work for network initiated trigger. BTW, based upon our 
implementation, we found anticipated handover does not provide
good performance on cellular link. Hence, anticipated handover
is not going to address fast handoff need for various cellular networks. 

regards
Vijay

> 3.1.6.   Mobile Initiated Handover
> 
>    The main difference between mobile initiated network initiated
>    handover is that, in mobile initiated handover, MN receives
>    predictive information about the Layer 2 handover. The MN MUST send a
>    RtSolPr message to the oAR to trigger the PrRtAdv.
> 
> 3.1.2.  Network Initated Handover
> 
>    In network initiated handover, the oAR receives an indication that
>    the MN is about to move and information on the nAR to which the MN
>    will be moved. Both stateless and stateful nCoA configuration are
>    supported, as is use of the oCoA.
> 
> I do not really see why are you so opposed to 3.2.1 of the FMIPv6 (Version
> V4)
> draft ?
> regards,
> ajoy
> 
> 
> 
> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Friday, July 12, 2002 4:05 PM
> To: Singh Ajoy-ASINGH1
> Cc: 'James Kempf'; Rajeev Koodli; [email-masked]
> Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions
> 
> hi Ajoy ,
> 
> I think Raj's email answers your question.
> 
> I am afraid Section 3.2.1 of draft 4 will hold back the draft
> from advancing unless there is a standard way of doing L2-ST,
> L2-TT, L2-LD, L2-LU. even if there is a standard way of doing
> the triggers, there has to be some kind of reference that FMIPv6
> can quote. I am afraid that is not there (or wont there when
> we need to advance FMIPv6)
> 
> take a look at the following mail from Jack McCann, I just saw
> in the IPv6 WG. I hope I am not doing anything wrong by cutting
> and pasting this mail
> 
> > The current Basic API draft (draft-ietf-ipngwg-rfc2553bis-05.txt)
> > contains normative references to the Scoped Addressing Architecture
> > (draft-ietf-ipngwg-scoping-arch-04.txt).  In particular, it relies
> > on the definition of zone indices, and on the scoped address text
> > format defined in that document.  This was flagged as an issue
> > during IESG review.
> >
> > To allow 2553bis to move forward and be published as an RFC without
> > having to wait on the scoping-arch document, we've proposed to move
> > those portions of the Basic API that rely on scoping-arch into a
> > separate document that can advance alongside the scoping-arch document.
> >
> > There are 4 items that will move from 2553bis to the new "scoping api"
> > document:
> >
> > 1. References to the terms "link index" and "site index" in
> >    the definition of the sin6_scope_id field.  Note that the
> >    sin6_scope_id field will remain in 2553bis.
> >
> > 2. Use of the scoped address text format with getaddrinfo().
> >
> > 3. Use of the scoped address text format with getnameinfo().
> >
> > 4. The NI_NUMERICSCOPE flag.
> >
> 
> draft-ietf-ipngwg-scoping-arch-04.txt is infact a WG document in the
> IPv6 WG, but not an RFC yet. because of this, it cannot be referenced
> in the API draft.
> 
> L2 triggers draft has not been adopted by any WG.
> 
> do you see the danger?? please dont conclude I am spreading FUD. this
> is a real concern.
> 
> Vijay
> 
> Singh Ajoy-ASINGH1 wrote:
> >
> > Hello Vijay,
> > Thanks for your email. BTW, can you please
> > explain how can we implement fast handoff without
> > any link layer support? I also do not understand
> > why standardization of FMIPv6 will get delayed
> > because of L2 triggers. Is it not enough to
> > document various L2 triggers and the actions to be taken
> > based upon the L2 triggers? Do we need anything more than this?
> > regards,
> > ajoy
> >
> > -----Original Message-----
> > From: Vijay Devarapalli [mailto:[email-masked]]
> > Sent: Friday, July 12, 2002 2:08 PM
> > To: Singh Ajoy-ASINGH1
> > Cc: 'James Kempf'; Rajeev Koodli; [email-masked]
> > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions
> >
> > Ajoy,
> >
> > you got me wrong. I am not against using L2 triggers. I know you
> > need them to get the most optimized handovers. but we also need
> > a generic FMIPv6 solution (I dont know how manys times I have
> > said this now) that does not depend on L2 triggers. we need an
> > RFC soon (dont you?).
> >
> > Vijay
> >
> > Singh Ajoy-ASINGH1 wrote:
> > >
> > > Hello Vijay,
> > > We have implemented FMIPv4 in our prototype 3G Cellular testbed.
> > > We have implemented both source as well as target triggers required
> > > to support Post-Reg (FMIPv4 version of BETH). So, I do not understand
> > > why are you complaining about L2 triggers? BTW, can you explain how
> > > can you implement FMIPv6 without using Link layer triggers?
> > > regards,
> > > ajoy
> > >
> > >
> > > -----Original Message-----
> > > From: James Kempf [mailto:[email-masked]]
> > > Sent: Friday, July 12, 2002 12:26 PM
> > > To: Vijay Devarapalli
> > > Cc: Rajeev Koodli; [email-masked]
> > > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions
> > >
> > > > > In particular, Section 3.3 and 3.4 were dropped from the draft.
> These
> > > are critical
> > > > > for describing how Postregv6 (aka BETH)
> > > > > can be implemented. If there is some problem with too much
reference
> > to
> > > L2
> > > >
> > > > Section 3.3 and 3.4 also critically depend on L2 triggers to work.
> > > > BTW, I still havent figured out how to implement L2 triggers on our
> > > > testbed. I dont see FMIPv6 draft moving forward unless the L2
triggers
> > > > draft becomes a standard. right?? and the L2 triggers document does
> > > > not even have a permanent home (WG).
> > > >
> > >
> > > If you want to know how to implement L2 triggers, either I or Jon Wood
> can
> > > help you. I implemented them on the Solaris
> > > emulator and Jon on our Linux/BSD emulator. Jon is also in the process
> of
> > > implementing L2 triggered 802.11 handover, in a
> > > manner that is consistent with the 802.11 spec and doesn't depend on
> > > proprietary extensions.
> > >
> > >         jak

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 16 Jul 2002 07:28:55 -0700

Hi Ajoy,

> address of the mobile node. If we implement FA function 

Does re-association also apply to BSS mode, or when
the station moves between two different ESS?

If it is only used when the station moves from one AP
to another in the same ESS, this is not as interesting,
because the mobility is already handled at link-layer
in 802.11b.

> AP and AR which can be addressed in separate document. 

http://www.ietf.org/internet-drafts/draft-yegin-l2-triggers-00.txt

...

> is not going to address fast handoff need for various cellular networks. 

Ajoy, was that an FMIPv4 implementation, or FMIPv6 implementation?

alper

---

From: "James Kempf" <[email-masked]>
Date: Tue, 16 Jul 2002 18:11:42 -0700

Reassociation.request() is sent whenever the mobile station is in infrastructure
mode.

            jak

----- Original Message -----
From: "Alper E. YEGIN" <[email-masked]>
To: "Singh Ajoy-ASINGH1" <[email-masked]>; "'Vijay Devarapalli'"
<[email-masked]>
Cc: "'James Kempf'" <[email-masked]>; "Rajeev Koodli"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, July 16, 2002 7:28 AM
Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions