[Mip4] Re: Pre-Registration Request routing issue in Low Latency Handoffs in Mobile IPv4 Draft --

Hi Manish,
If I understand the problem correctly, you're saying that
it would take longer for the Registration Req to reach nFA
in the case of reverse tunnelling since it would have to
traverse the HA twice. This may or may not delay the
actual handoff depending on the anticipation time and the FA-HA
delay. Typically the wireless leg and handoff time tend to
compensate for additional fixed delays so there would not be
a problem. However there may be a case where the overall handoff
time is impacted (do you have any practical case?) thus we
could introduce shorter path routing for the reverse
tunnelling case. The oFA has knowledge of its nFA neighbour
addresses and could further filter incoming packets (RR?)
destined to the nFA routing them through the secure oFA-nFA
interface. That would be compatible with reverse tunnelling
and the packets wouldn't be dropped by source address filters.
There's a couple of issues, possibily including this one, that
I'd like to take up in a revision of the draft following RFC
publication (in RFC Ed queue). I'll put forward a list.
Regards,
Karim

Chugtu Manish-a22653 wrote:
> Hi Karim,
>  
> This is regarding the method of handling Pre-Registration request by oFA
> in the /Low Latency Handoffs in Mobile IPv4 /
> <http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-11.txt>/ Internet
> Draft./ According to me, the way it is handled by the draft might have a
> problem as follows:
>  
> Pre-Registration according to draft should be treated as *normal IP
> packet which has to be routed **to the nFA by oFA*. But since the MN is
> already registered to oFA and lets say we have Reverse Tunneling enabled
> on oFA, any packet with the source address as Home Address of MN would
> be tunneled to HA including the Pre-registration packet, which is not
> what we want.
>  
> Also, in this case if somehow we route the Pre-Reg packet to the nFa
> by-passing reverse tunneling (by defining some routing policies or may
> be by coding it in such way) , it still may not be a good idea, since
> one of the main reason for reverse tunneling is to avoid packet drops
> for topologically in-correct source address.
>  
> So we would have to define a specific way to handle Pre-Reg packets in
> reverse tunneling case eg: Might need to tunnel it to the nFA. Please
> let me know your inputs and also in case I am missing something here. In
> case you agree to the problem, do you think we might need a revision to
> the draft which states and addresses the above mentioned problem
>  
> Best Regards
> Manish Chugtu

-- 
Mip4 mailing list: Mip4@ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/