Subject: Re: [Mipshop] FMIPv6 - NAR sets up tunnel endpoint?

From: Rajeev Koodli <[email-masked]>
Date: Fri, 16 Sep 2005 11:10:02 -0700

Perhaps a better question might be "are there objections to having it as 
an option"?

I am okay either way. Just that if someone wishes to keep an option, we 
should not disallow it (assuming it is not overly complex of course!).

Thanks,

-Rajeev

James Kempf wrote:
> I'd like to simplify the protocol. I don't think an additional tunneling 
> mode is necessary. I don't think it makes a difference if it's a MAY or 
> not.
> 
> If nobody else is interested in this, I'm willing to drop it. Is anyone 
> else interested in simplifying the protocol by getting rid of the 
> PAR-NAR tunnel?
> 
>            jak
> 
> ----- Original Message ----- From: "Rajeev Koodli" <[email-masked]>
> To: "James Kempf" <[email-masked]>
> Cc: "GAABAB Brahim RD-CORE-CAE" <[email-masked]>; 
> <[email-masked]>; "Alexandru Petrescu" <[email-masked]>
> Sent: Friday, September 16, 2005 10:42 AM
> Subject: Re: [Mipshop] FMIPv6 - NAR sets up tunnel endpoint?
> 
> 
>>
>> Hi Jim,
>>
>> ya, I was showing how the PAR - NAR tunnel could still provide 
>> predictive handover feature. I agree that you can live with reactive 
>> handover. Note that:
>>
>> - PAR - NAR tunnel set up is optional (MAY, not required).
>> - there will not be two different tunnels.
>>
>> Would you object to having it as an option?
>>
>> -Rajeev
>>
>>
>> James Kempf wrote:
>>
>>>> Okay. In this case (according to the current spec), the MN knows 
>>>> that PAR - NAR tunnel is set up already. So, all it has to do is to 
>>>> announce itself to the NAR and receive packets. And, send packets 
>>>> using PCoA.
>>>> In essence, predictive handover.
>>>>
>>>
>>> If the proposed CoA was accepted, then the tunnel runs from PAR to 
>>> nCoA on the MN. If not, then the current spec runs the tunnel to the 
>>> NAR.
>>>
>>> I'm proposing to modify this. The modification is that the 
>>> specification of a tunnel to NAR is dropped. Instead, the 
>>> specification requires the MN to do oDAD on the new link and send FBU 
>>> to the PAR again from the new link with the new CoA, treating the 
>>> handover as reactive.
>>>
>>>>>
>>>>> 2) The MN gets the FBack on the NAR as the first packet when it 
>>>>> arrives on the link, in which case the MN can take the action above.
>>>>>
>>>>
>>>> Before the MN receives FBack, it would have sent FNA to which the 
>>>> NAR would respond NAACK. In any event, the tunnel is already set up 
>>>> (hence FBack is waiting in the queue).
>>>>
>>>
>>> I'm proposing the FBack is only sent through NAR to the nCoA if the 
>>> proposed nCoA is accepted (it is always sent through PAR to the 
>>> oCoA). If the proposed nCoA is not accepted, no FBack is sent and the 
>>> MN must again failover to reactive handover.
>>>
>>> As a separate issue, we can discuss NAR and NAACK v.s. a simple NS.
>>>
>>>> So, when PAR - NCoA tunnel fails (very rarely I would think), PAR - 
>>>> NAR tunnel is already set up providing the predictive handover 
>>>> features when the MN shows up on NAR's link.
>>>>
>>>
>>> Right. I'm proposing that since this is a very rare event, we drop 
>>> this additional feature with the attendant code and additional 
>>> complexity and instead use features that are already part of the 
>>> protocol and necessary for other reasons (i.e. reactive handover) to 
>>> solve the problem, thereby simplifying the protocol.
>>>
>>> Would you like me to make a proposal in the issue data base on this?
>>>
>>>            jak
>>>
>>
> 
> 

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