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.