Re: [Mipshop] transient binding draft update
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mipshop] transient binding draft update



Hello Vijay,

After this clarification, may I ask what is the next step?

Thanks in advance!

Regards,
Ahmad
 

> -----Original Message-----
> From: mipshop-bounces at ietf.org 
> [mailto:mipshop-bounces at ietf.org] On Behalf Of Muhanna, Ahmad 
> (RICH1:2H10)
> Sent: Friday, September 11, 2009 12:14 AM
> To: Vijay Devarapalli; Marco Liebsch; Mipshop
> Subject: Re: [Mipshop] transient binding draft update
> 
> Hi Vijay,
> Thanks for your detailed comments. Please see comments inline.
> 
> Regards,
> Ahmad
> 
> > -----Original Message-----
> > From: Vijay Devarapalli [mailto:vijay at wichorus.com]
> > Sent: Thursday, September 10, 2009 6:43 PM
> > To: Muhanna, Ahmad (RICH1:2H10); Marco Liebsch; Mipshop
> > Subject: Re: [Mipshop] transient binding draft update
> > 
> > Hi Ahmad,
> > 
> > On 9/4/09 1:17 AM, "Ahmad Muhanna" wrote:
> > 
> > >> The "static configuration" at the LMA actually starts accepting 
> > >> uplink packets from the nMAG only after receiving a PBU 
> from nMAG.
> > > [Ahmad]
> > > This actually may explain why you insist on the text above
> > under the
> > > previous paragraph. It is very interesting! First of all, 
> is this a 
> > > new usecase that you would like the transient BCE draft to
> > address?! 
> > > IMO, it is a little late but we can consider that if we
> > understand the usecase.
> > > 
> > > Though, it will be helpful, if you take us through the
> > details of this
> > > usecase and what you are trying to optimize and achieve by
> > using the
> > > tBCE in here. Also, whether it is a new addition on top 
> of RFC5213?
> > 
> > There is no new use case. The use case, IMO, has always 
> been that the 
> > LMA should accept uplink packets both from the pMAG and the nMAG 
> > during a handover for a certain amount of time.
> > How you achieve this can be different.
> > 
> > In the transient binding cache mechanism, there is an 
> explicit signal 
> > from the nMAG to the LMA to accept uplink packets from the 
> nMAG even 
> > though the BCE points to the pMAG.
> > A subsequent PBU message from the nMAG updates the binding 
> cache entry 
> > to point to the nMAG. After that the LMA stops accepting the uplink 
> > packets from the pMAG.
> > 
> > In the static configuration case, the PBU from the nMAG 
> would update 
> > the binding cache entry at the LMA immediately with the proxy CoA 
> > being set to the nMAG. But, the LMA would be configured to accept 
> > uplink packets from the pMAG for a short duration 
> (configured on the 
> > LMA). When the timer for this duration expires, the LMA will accept 
> > uplink packets only from the nMAG.
> [Ahmad]
> I see what you are saying here. But, usecase 1 is a little 
> different. In usecase 1, we are not worried about the uplink 
> data traffic from the pMAG after the 1st PBU with the 
> transient option included. We are worried about the downlink 
> traffic. In other words, in usecase 1, if we allow the LMA to 
> update the BCE with nMAG pCoA immediately, the LMA will start 
> forward downlink traffic to the nMAG immediately and that is 
> a problem for usecase 1. Because, the link between the LMA 
> all the way to the base station in the downlink direction is 
> NOT setup yet.
> 
> In usecase 1, IMO, 3GPP folks did an excellent job designing 
> a very reliable well thought handover mechanism.
> 1. When the MN moves to the target access network (nAN) with 
> an active data session, the MN does not need to worry about 
> uplink traffic nor downlink and it continues to send uplink 
> traffic as normal. That is why as soon as the MN moves to the 
> target access network, the uplink direction of the link from 
> the base station all the way to the LMA is ready. 
> 
> 2. In order to avoid any packet loss in the downlink 
> direction, all downlink traffic continues to go to the pMAG 
> to the pAN and from the pAN to the nAN and then to the MN.
> 
> 3. while the data traffic is moving as in 1 and 2, the 
> network is working on setting up the link for the downlink 
> direction from the LMA all the way to the nAN. 
> 
> 4. When the link in the downlink direction is complete and 
> ready, the LMA switch the tunnel completely to point to the 
> nMAG and nAN.
> 
> 5. After the LMA switches the tunnel completely, there is no 
> uplink traffic in-flight to worry about from the pMAG because 
> the uplink traffic has been going through the nMAG directly 
> to the LMA for sometime. Only, in-flight downlink traffic 
> which is sent to the pMAG.
> But, in that case the pMAG continues to forward that to the 
> pAN, and pAN to the nAN to the MN.
> 
> It is a very smooth mechanism! :)
> 
> 
> > 
> > So it doesn't matter how you achieve this, the goal is to 
> enable the 
> > LMA to receive uplink packets from both the pMAG and the nMAG for a 
> > certain amount of time during a handover.
> > 
> > Hope this clarifies my earlier email.
> [Ahmad]
> Thanks! it does. Please see comments above.
> 
> > 
> > Vijay
> > 
> > 
> _______________________________________________
> Mipshop mailing list
> Mipshop at ietf.org
> https://www.ietf.org/mailman/listinfo/mipshop
> 

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.