Re: FMIPv6 : Triggering of tunnel establishment

Hello Rajeev,


Friday, 08 August, 2003 2:46 AM
From: Rajeev Koodli <[email protected]>


> Hello Suvidh,
>
> Suvidh Mathur wrote:
>
>> Hi,
>>
>>
>>     1. If stateful address configuration is used at NAR, until NAR
allocates
>>  NCoA and
>>           sends it in HACK message, the PAR is not aware of the NCoA. In
>>  such a scenario,
>>        PAR would not be in a position to send NCoA in PrRtAdv, and
>>  subsequent FBU /
>>        FNA sending from MN would also be done without MN knowing the
NCoA.
>>
>
> Right. However, the MN could "propose" a NCoA in FBU, which is then
> carried in HI. The NAR can allocate a new one or okay the proposed one.
> The result is indicated in FBack. Note that even if PrRtAdv provided
NCoA,
> the binding is not complete until FBack is received. When the allocated
NCoA
> is different compared to the proposed NCoA, FBack should contain the
allocated
>
> NCoA.

That seems reasonable. FBAck then needs a way to return the allocated
NCoA when that is different from the one proposed by MN. Porbably making
Alternate CoA as a valid Mobility option for FBAck would be sufficient.


>>
>>     2. For packet buffering at PARs, the draft specifies "When the PAR
>>  receives an FBU,
>>        it MUST send a HI message to the NAR. Upon receiving a
corresponding
>>  HACK
>>        message, the PAR MUST send FBACK to the MN. Until the HACK is
>>  received,
>>        the PAR MAY buffer any packets arriving for the MN."
>>
>>        In this case, if MN sends FBU after attaching to the new link
then
>>        there would be
>>        some packet loss which can be avoided if AR starts buffering on
>>        receipt of RtSolPr.
>>
>
> When PAR should start buffering is a good question. If RtSolPr is sent
just
> before handover, this should work fine. However, the very same event that
> allowed RtSolPr to be sent anticipating an impending handover could also
> serve as trigger to send FBU. So, the general problem is: how does the MN
know
>
> it is moving ? Because of this and other reasons, we separated the Proxy
> Router messages
> from the actual handover timing. In any case, the MN should be able to
send
> them
> any time. So, if an option to request buffering is desirable in RtSolPr,
> I suppose we
> could add that.
>

I agree to the basic idea of separated the Proxy Router messages from
the actual handover timing. But in case of anticipated handovers, it
would be nice to let PAR start buffering on receipt of RtSolPr.


>>
>>     3. For buffering at NAR, the draft specifies "The New Access Router
MUST
>>  NOT
>>        tunnel packets from the MN with PCoA as source IP address
destined
>>  for arbitrary
>>        correspondent nodes to PAR until a HI message is received, and
the
>>  NAR MAY
>>        buffer any such packets."
>>
>>        What would be the trigger for NAR to start buffering?
>>
>
> There has been some discussion on this leading to the following. The MN
would
> tunnel directly to PAR instead of requring NAR to do tunneling. In fact,
the
> tunnel termination and begining will happen at the MN instead of at NAR.
So,
> 3) should not be an issue anymore.
>

yeah. I did not follow the discussion on this. Of course, having NCOA as
tunnel endpoint is not altogether a good idea, but I think we can live
with that.

Thanks for your reply,
Suvidh