Subject: RE: [Mipshop] FMIPv6 - Encapsulating FBU into Mobility Header (FN A)

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Fri, 12 Aug 2005 07:26:15 -0500

> 
> I think that if the "assigned address" field is removed from 
> the HAck/FBAck (in the spec) then the inner workings of the 
> proactive approach will certainly be influenced.
> 
> That may mean that the proactive approach can be used only 
> with vendor-specific extensions (that are not yet specified).
> 
> If only the stateless autoconf is taken into account by FMIP 
> then probably only the reactive approach may continue to work.
> 
> Alex
> 

Why is that? Predictive mode vs. reactive mode differs in when the MN is sending the FBU. All the information the MN needs for autoconfiguration can be obtained from the PrRtAdv - no? What am I missing? 

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Aug 2005 14:49:34 +0200

Narayanan Vidya-CVN065 wrote:

>> 
>> I think that if the "assigned address" field is removed from the
>> HAck/FBAck (in the spec) then the inner workings of the proactive
>> approach will certainly be influenced.
>> 
>> That may mean that the proactive approach can be used only with
>> vendor-specific extensions (that are not yet specified).
>> 
>> If only the stateless autoconf is taken into account by FMIP then
>> probably only the reactive approach may continue to work.
>> 
>> Alex
>> 
> 
> Why is that? Predictive mode vs. reactive mode differs in when the MN
> is sending the FBU. All the information the MN needs for
> autoconfiguration can be obtained from the PrRtAdv - no?

Yes, MN could autoconfigure an address from PrRtAdv but it is not worth
doing so if it sends the FBU only after attaching to NAR.  There's no
point (no relevant gain in "speed") for MN to autoconfigure an address
from PrRtAdv as opposed to autoconfigure an address from RS/RA on NAR.

(MN sends RS upon attachment to NAR and receives RA and then sends FBU -
 this takes 3 units of time in addition to about 30units of
 time for link-layer attachment.  If MN uses PrRtAdv (instead of RS/RA)
 it saves only 2 worthless units of time.  The "units of time" are from
 measurements of a specific link-layer, the one that was presumably used
 for implementations.  More specifically: successful link-layer
 attachment time is 90milliseconds, RTT on wireless is 300microseconds.)

Alex

---

From: "James Kempf" <[email-masked]>
Date: Fri, 12 Aug 2005 08:48:21 -0700

>  attachment time is 90milliseconds, RTT on wireless is 300microseconds.)

What link layer are you talking about?

        jak

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Aug 2005 18:46:55 +0200

> What link layer are you talking about?

802.11b, laptop, PCMCIA: RTT 3ms (just measured), successful attachment
                         90ms (just measured), nok att 50ms (just
                         measured).
                         For a device much smaller than laptop and card
                         much smaller than PCMCIA: same RTT, but
                         attachment 5seconds(!) (measured).
802.11blah-blah MIMO off-the-shelf AP: probably 300us (speculation on
                                       its 108Mbit/s instead of 11, not
                                       measured).

The measurements where done with ping/v4 and unix time command.

ping next_hop 10 packets says 2millisecond average RTT
time -p iwconfig wrong_key says real 0.04 user 0.00 sys 0.05
time -p iwconfig right_key says real 0.09 user 0.00 sys 0.10.

Anyone else got similar or different figures?

Alex