Re: [Mipshop] transient binding draft update
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
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.
Vijay
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.