Subject: Re: [netlmm] Commentondraft-muhanna-netlmm-pmipv6-support-transient-coa-01.txt

From: "Mohana Jeyatharan" <[email-masked]>
Date: Wed, 9 Apr 2008 09:07:33 +0800

Hi Oliver,

Thanks for your response. I have read your draft previously. If I remember correct, you are trying to reduce packet loss in a inter technology hand-off (MBB) by using secondary caches and also save up-link packets from previous interface. Yes, it is pretty much the same as ahmad's draft but the scenarios are slightly different. Ahmad's one is a single interface hand-off. Pls see reply in-line.

BR,
Mohana

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of BLUME, Oliver
> Sent: Tuesday, April 08, 2008 5:34 PM
> To: Mohana Jeyatharan; Ahmad Muhanna; Marco Liebsch
> Cc: [email-masked]
> Subject: Re: [netlmm] 
> Commentondraft-muhanna-netlmm-pmipv6-support-transient-coa-01.txt
> 
> Hi Mohana and Ahmad,
> 
> please allow me to enter this discussion, as I  have subitted 
> a draft with the same idea (using a different name: secondary 
> instead of transient, see 
> draft-blume-netlmm-secondary-binding-proxymip6ho-00.txt ).
> 
> For the protection of uplink packets from the old MAG there 
> actually is a possibility to handle this in LMA. For this, 
> the LMA would have to implement a timer that will allow for 
> packets for some time after the deregBPU. Please note that 
> the MinDelayBeforeBCEDelete timer has a somewhat different 
> purpose: This keeps memory of the previous binding in the 
> single radio (break-before-make) handover, where the radio 
> reconfiguration leads to a break between deregPBU and the PBU 
> from the new MAG. The timer asures that the LMA still 
> "remembers" the UE and can give the same HNP to the UE on the new MAG.
I know the purpose of the MinDelayBeforeBCEDelete timer. This is to keep the cache incase, dereg PBU arrives before new PBU(it will happen mostly in single radio per access technology type). But, why I quoted that here is that, if LMA can keep such information, then it could possibly keep some memory of the old cache until the dereg arrives from old MAG. 

But, you quote above that after dereg PBU the LMA should hold the packet for some time. But, after dereg PBU the MAGs are not going to send uplink packets. I think the problem is between the time of new PBU from new MAG and the dereg from old MAG that the up-link packets will be lost. Unless you are talking about some delay in packets and they arrive after dereg PBU...

> There is no specification how the LMA has to treat packets 
> arriving during this interval from the old MAG. LMA could 
> drop these packets or could decide to still accept them for 
> deencapsulation and routing to the final destination. This is 
> implementation specific and could be configurable at the LMA. 
> The drawback is that there is no coupling to the handover 
> progress and the behaviour is not specified.

Well, from how I understand, the problem is that the LMA does not know the UEs state, thus the explcit 
Notification to create secondary cache and setting rules is very useful for both downlink and uplink packets as stated in all three drafts. Agree. So, the secondary cache is to mainly save downlink packets and prevent buffering at new MAG and so on. Am I correct?
> 
> Once you introduce transient/secondary/preliminary binding 
> cache entries for uplink packets from the new MAG (while 
> still tunneling downlink packets to the old MAG) you can 
> reuse this feature to handle uplink packets from the old MAG 
> in a well specified way. I described a state diagram for this 
> in my draft. A further benefit is that now (instead of the 
> MinDelayBeforeBCEDelete timer) the deregPBU of the old MAG is 
> used to terminate the intervall of acceptance of these packets.

Yes, I understand, when clear instructions are given to LMA using explcit signaling, it is always easier.
> Best regards,
> 
> Oliver
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Im Auftrag von Mohana Jeyatharan
> Gesendet: Dienstag, 8. April 2008 09:21
> An: Ahmad Muhanna
> Cc: [email-masked]
> Betreff: [netlmm] Comment 
> ondraft-muhanna-netlmm-pmipv6-support-transient-coa-01.txt
> 
> Hi Ahmad,
> 
> I read your draft on transient CoA. I definitely see the need 
> to protect uplink packets that are on transit during hand-off 
> and also understand the need for transient caches maintained 
> at LMA during hand-off.
> 
> But, the question is that, base PMIP draft maintains BCE even 
> after deregPBU. Cant the LMA maintain old BCE during 
> horizontal hand-off for a short time and accept up-link 
> packets. Why should the new MAG explicity give this 
> information to LMA with a specific time field. 
> I agree, in your case, you are talking about early PBU via 
> new MAG(using context transfer), and you do not want downlink 
> packets to come until MN makes attachment at new MAG. Apart 
> from this benefit, I am not verysure why LMA cant handle this 
> and prevent the uplink packet loss from old MAG.
> 
> BR,
> Mohana
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm
> 
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm