Subject: Re: [netlmm] PMIP6-MIP6 Interactions - Binding Cache Entry Management - Please comment

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 01 Oct 2008 08:54:45 -0700

On 10/1/08 12:38 AM, "Ryuji Wakikawa" <[email-masked]> wrote:

> Vijay,
> 
> 
> On 2008/10/01, at 0:52, Vijay Devarapalli wrote:
> 
>> Hi Vidya,
>> 
>> I don't think it is any longer a simple choice of picking one approach
>> vs the other.
>> 
>> There are valid deployment scenarios where the mobile node is allowed
>> access through only one access network at a time. 3GPP release 8 has
>> already assumed this. The mobile node getting access through two
>> different links at the same time is simply not allowed. For these
>> deployments having two separate binding cache entries on the combined
>> HA/LMA entity introduces complexity, more memory requirements, etc..
>> So
> 
> One question. Two BCE are not managed all the time in Scenario-C if we
> don't consider multihoming.
> Two BCEs are appeared for a moment, only when MN handover between PMIP-
> MIP.

Sure. If you don't consider multi-homing and still go with the two BCE
approach, then two BCEs for a mobile node will exist only for a short
duration during the handover. But still your memory requirements will not be
proportional to the number of mobile nodes you can handle. It would be the
number of mobile nodes plus the number of mobile nodes that might be
performing handovers at any time.

Vijay

> I am not sure how much additional memory you need for separate BCE.
> 
> ryuji
> 
>> 
>> most of the HA/LMA combined entity implementations, IMO, will still go
>> ahead with a single binding cache entry per mobile node irrespective
>> of
>> what we decide here.
>> 
>> At the same time, I don't think any one wants to prevent the
>> "multi-homing scenarios" that George presented. I think the mobile
>> node
>> should be allowed access through multiple access networks. But this
>> will
>> be more like a feature addon that would come later. Maybe 3GPP
>> release 9
>> will allow this. For the mobile node to access the home agent through
>> the home or the visited link, it is best that we use the approaches
>> presented in section 5.6 of
>> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-09.tx
>> t. FWIW, I am strongly opposed to solving scenario C of the PMIPv6-
>> MIPv6
>> interactions document with the hierarchical use of PMIPv6 and MIPv6.
>> 
>> Perhaps it would be better if we focus on how to support both
>> scenarios.
>> 
>> 
>> Vijay
>> 
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Narayanan, Vidya
>>> Sent: Monday, September 29, 2008 5:58 PM
>>> To: [email-masked]
>>> Subject: [netlmm] PMIP6-MIP6 Interactions - Binding Cache
>>> Entry Management - Please comment
>>> 
>>> Hi,
>>> At the Dublin meteing, we discussed the issue of having one
>>> vs. two separate binding cache entries for PMIP6 and MIP6
>>> bindings of an MN.  Vijay and George presented the cases for
>>> having a single vs. separate BCE for the two respectively.
>>> Following that, we tried to get a sense of the room on the
>>> topic.  At the meeting, we had about 15 or so people who were
>>> in favor of having separate BCE's for PMIP6 and MIP6 bindings
>>> of an MN, about 10 people who didn't care how it was done and
>>> about 5 people who were in favor of having a single BCE for
>>> both.  Jari also suggested that the single BCE support
>>> appears fairly complicated and needs further clarity to see
>>> why that should be supported.
>>> 
>>> In order to make progress on the interactions document,
>>> please provide input on the mailing list on whether you would
>>> like to see Scenario C supported with a single BCE or
>>> separate BCE's.  The slides presented at Dublin are at
>>> http://www.ietf.org/proceedings/08jul/slides/netlmm-3.pdf and
>>> http://www.ietf.org/proceedings/08jul/slides/netlmm-4.pdf for
>>> your review.
>>> 
>>> Please provide rationale with your choice - we are not
>>> looking for a vote on this topic.  Please also talk about
>>> what you don't like in the alternative.  Without rationale,
>>> please note that your views cannot contribute towards consensus here.
>>> 
>>> Please write to the list by October 10th, 2008.
>>> 
>>> Thanks,
>>> Vidya
>>> _______________________________________________
>>> 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

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 2 Oct 2008 18:21:50 +0900

> performing handovers at any time.

I don't think not all the MNs are registering all the time..
The additional memory required for this handover period might be  
negligible.

Is this really problem?

regards,
ryuji