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

From: Hesham Soliman <[email-masked]>
Date: Wed, 01 Oct 2008 21:01:20 +1000

> 
>> - The natural way of supporting this would use separate BCE.
>> Deviating from
>> this, requires rationale by the people suggesting that. The
>> only rationale I
>> heard so far is memory consumption. This is an extremely weak
>> argument.
> 
> I think this is really debatable. Another point of view is that PMIP6 is
> a MIP6 extension, i.e., PMIP6 uses the same protocol messages and data
> structures than MIP6. This would mean the natural way is to use a
> single/shared BCE.

=> I knew the word "natural" will cause confusion. What I mean is that the
natural way to do things, according to MIPv6 (and as you mention above its
extensions) is for one entity to manage the BCE. Having two separate
entities manage the same binding causes numerous problems as discussed in
the meeting and slides. In this case, we have two entities, the MN and the
MAG. Hence, the argument for functional separation. This is not an abstract
argument, as we've already discussed the negative consequences of doing the
alternative. 
Can you explain what's wrong with doing it this way?

Hesham

> 
> Regards,
> 
> Kilian
> 
> 
> Panasonic R&D Center Germany GmbH
> 63225 Langen, Hessen, Germany
> Reg: AG Offenbach (Hessen) HRB 33974
> Managing Director: Thomas Micke
> 
> 
> _______________________________________________
> 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: "Kilian Weniger" <[email-masked]>
Date: Wed, 1 Oct 2008 14:55:38 +0200

Hi Hesham,

as I wrote in an earlier email, in my opinion we should not discuss
single vs. separate BCE implementation option. We should discuss whether
external HA behaviour should be according to:

1) Data forwarding is always done according to MIP6 BCE, if exists, no
matter whether PMIP6 BCE exists or not. Only if MIP6 BCE is empty, PMIP6
BCE is used (i.e., MIP6 BCE always has priority over PMIP6 BCE) or

2) Data forwarding is done according to last received registration
(i.e., MIP6 and PMIP6 BCE have equal priority). 

I assume that in your email you refer to 1) when you talk about separate
BCE, since this is the approach described in George's slides (which uses
separate BCE implementation option).

To answer your question: As mentioned in my previous emails, IMHO the
main problem of 1) is the increased handover delay in MIP6->PMIP6
transition case. In 1) the HA only starts forwarding data packets to the
MN's new location after it has received the BU de-registration. In 2)
the HA starts forwarding data packets to the MN's new location once the
PBU is received. Hence, 1) "Data forwarding is always done according to
MIP6 BCE" introduces an additional handover delay of at least 1 RTT
between MN and HA/LMA (i.e., PBA + RA + BU de-reg). 

Due to the additional 1 RTT handover delay of 1), the HA behaviour
according to 2) "Data forwarding is done according to last received
registration" is preferable IMHO.

Regards,

Kilian

> -----Original Message-----
> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: Mittwoch, 1. Oktober 2008 13:01
> To: Kilian Weniger
> Cc: Netlmm
> Subject: Re: [netlmm] PMIP6-MIP6 Interactions - Binding Cache 
> Entry Management - Please comment
> 
> 
> >

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 01 Oct 2008 23:16:46 +1000

> BCE is used (i.e., MIP6 BCE always has priority over PMIP6 BCE) or

=> Agreed with everything except for the "or" :). There is no "or" according
to MIPv6.

> (i.e., MIP6 and PMIP6 BCE have equal priority).

=> This is what causes problems.
> separate BCE implementation option).

=> Yes.

> MN's new location after it has received the BU de-registration.

=> Not necessarily de-reg but a new BU. I mean the same issue occurs if the
MN moves from one WLAN to another. I get your point though.

In 2)
> MIP6 BCE" introduces an additional handover delay of at least 1 RTT

=> 0.5 RTT actually.

> between MN and HA/LMA (i.e., PBA + RA + BU de-reg).

=> What you describe above was discussed in the meeting. This *is* how MIPv6
and PMIPv6 work. You need to update the HA/LMA in order to get correct
forwarding. The problem you describe is not new and that is why there are
mobility optimisations for it. If you ask me, the real problem occurs if you
want to manage the same address in the LMA and HA. There is no reason for
that. If you use the hierarchical model your problem will be solved to the
best of MIPv6's ability.

> registration" is preferable IMHO.

=> Not if you use the hierarchical model. I.e., do not manage the HoA/HNP in
the LMA. I've yet to see a reason on the list for not doing this.
If you do manage the same address in the LMA and HA then you end up with the
scenario you mention.

Now, I assume all of this is due to 3GPP requirements. The scenario you
mention will happen in 3GPP when the MN moves from one interface to another.
This is rare of course compared to intra-system handovers. How much damage
is done by adopting normal smoothing techniques here like buffering ...etc?
I'm concerned that for this rare case, which is caused by, IMO, a series of
bad decisions like managing the same address in two places, we are making
life even more complicated.

If we can start from the beginning and someone explains why the *same*
address needs to be managed in the HA and LMA I'll be grateful. I lost count
on how many times I asked that question (definitely more than 5 times) and
never got an answer.

Hesham

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 1 Oct 2008 18:08:36 +0200

Hi Hesham,

> > MIP6 BCE" introduces an additional handover delay of at least 1 RTT

no, I was talking about the *additional* handover delay of HA/LMA
behaviour 1) "Data forwarding is always done according to MIP6 BCE"
compared to HA/LMA behaviour 2) "Data forwarding is done according to
last received registration" in the MIP6->PMIP6 handover case. This is at
least 1 RTT.

In 1), MN sends PBU, HA/LMA receives PBU, HA/LMA sends PBA, MAG sends
RA, MN sends BU de-reg, HA/LMA receives BU-dereg. Only then HA/LMA
forwards data to new location.

In 2), MN sends PBU, HA/LMA receives PBU. Then HA/LMA forwards data
already to new location.

> mobility optimisations for it. If you ask me, the real 

You seem to misunderstand the scenario, please see above.

Of course in general the HA/LMA always needs to be updated with new MN
location before correct forwarding is possible. But with 1) the HA/LMA
only forwards data after receiving the second of two subsequent location
updates (BU-dereg received after PBU), although the first location
update is already enough for the HA/LMA to know the new location of the
MN and hence to correctly forward the data. This is the problem of
HA/LMA behaviour 1) that I was referring to and why HA/LMA behaviour 2)
is preferable in my opinion.

> problem occurs if you

> If you do manage the same address in the LMA and HA then you 

this whole discussion is only about how to support scenario c, which is
exactly the scenario I was referring to. Please see Vidya's email.

Regards,

Kilian

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 02 Oct 2008 02:28:05 +1000

> In 2), MN sends PBU, HA/LMA receives PBU. Then HA/LMA forwards data

=> Ok, yes when you're moving in that direction I agree its 1 RTT.

> is preferable in my opinion.

=> see below.

> exactly the scenario I was referring to. Please see Vidya's email.

=> I know the discussion is about scenario C. I'm questioning the entire
rationale of this scenario which is based on the reuse of the same address
in different logical entities. And I still haven't gotten an answer for that
rationale. 

Hesham

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 01 Oct 2008 11:43:29 -0500

Hi Hesham,

> on how many times I asked that question (definitely more than 5 times) and

Not sure I  understand what you mean by the *same* address being managed by
the HA and LMA... Do you assume that the HA/LMA are managing the *same*
address simultaneously? At least I do not believe that to be the case.
Either the LMA or the HA is managing the prefix or address for an MN at any
given time (lets not worry about multihoming for a moment). So I don't see a
conflict as such except for this scenario where a PBU or a BU is lost or
delayed etc. 

Do you agree that an LMA is an entity which is a combination of DSMIP6
HA+PMIP6 functionality? IMO the LMA is capable of supporting RFC3775 MIP6
MNs as well. So an MN can move which is attached via an AR which is in the
PMIP6 domain to another AR which is not. In such a scenario, the MN simply
sends a BU to the HA (which is also the LMA). In terms of behavior I would
expect that the BCE in the LMA which has the prefix mapped to the CoA of the
MAG would now be deprecated and instead create a new entry wherein the HoA
is mapped to the CoA of the MN. So I don't see the issue of the HA/LMA
maintaining BCEs which are for the same address/prefix concurrently.

Does the above clarify your doubts? If not I guess you need to elaborate on
the comment about the *same* address.

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 01 Oct 2008 11:50:29 -0500

Hesham,

> the LMA. I've yet to see a reason on the list for not doing this.

What you are suggesting is that PMIP6 be used for local mobility and
(DS)MIP6 for global mobility (that is the hierarchical model interpretation
here I presume).  Yes, you can do that. But that is not necessarily the way
PMIP6 is being viewed for deployment. It is pretty much a global mobility
protocol. The aspect of "localized mobility" in *Netlmm* has no relevance to
the actual protocol.
As a result you have the scenaro where the LMA is managing the prefix for
the MN when it is in the PMIP6 domain and the same entity is responsible for
managing the HoA->CoA binding when it is in a non-PMIP environment but the
MN activating (DS)MIP6.
So I don't see the hierarchical model being utilized in the current context
of 3GPP or WiMAX architectures.

-Raj

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 02 Oct 2008 12:34:42 +1000

Hi Raj,

> the comment about the *same* address.

=> I understand what you say and I wasn't saying that the same address would
be managed simultaneously. What I was trying to highlight is the difference
between managing the HoA in the HA *only* Vs managing it in the LMA and HA,
even if not done simultaneously. I.e., the difference between the
hierarchical model and the model being proposed for scenario C. In the
former, the BC is checked independently in two different functional
elements. In the latter, the BC is checked in order, first the HA BC is
checked, then the LMA's BC is checked if no entry was found in the HA's BC.
I'm arguing that the hierarchical model is cleaner and less prone to errors
than what's being proposed in scenario C, even if two separate BCEs are
used. 
So I guess my preference is to not support scenario C, but if we have to,
then I'm strongly in favour of having two separate BCEs.

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 02 Oct 2008 12:44:24 +1000

> protocol. The aspect of "localized mobility" in *Netlmm* has no relevance to

=> Yes but unfortunately the way it's being viewed is inconsistent and
problematic. Ignoring for a minute the profound problems with it being a
global mobility protocol, if that's how it is viewed then we wouldn't be
having this discussion about it's interaction with MIPv6. We would just use
PMIPv6 to manage mobility and MIPv6 would not be used. But people seem to
want to use it sometimes as an LMM, sometimes as a global mobility protocol
and sometimes in conjunction with MIPv6.

If it is limited to local mobility life will be easier and manageable.
Again, I don't understand why people want to manage the home address in the
LMA. 

> of 3GPP or WiMAX architectures.

=> I don't see them using it either, but I don't see any reason for them to
do that. I keep asking why we need to do that and I keep getting answers
like "this is what they're doing". I know! I read the 3GPP specs many times.

Hesham

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 01 Oct 2008 23:47:34 -0500

Hi Hesham,

On 10/1/08 9:44 PM, "ext Hesham Soliman" <[email-masked]> wrote:

> problematic. 

May be too late to change this. The fact is that PMIP6 is a network based
mobility protocol which provides similar capability as (DS)MIP6 except for
there not being any host involvement. So essentially PMIP6 and(DS)MIP6 are
on par and there is nothing really about one being specifically designed for
localized mobility (although PMIP6 can be used in that manner with the
hierarchical approach).

> Ignoring for a minute the profound problems with it being a

I agree. But you cannot ignore the fact that the MN may be connected to
networks that deploy PMIP6 as well as others where there is no network
mobility. And given that both the protocols are basically providing global
mobility via a common anchor (i.e the LMA+HA) the need for such interaction
becomes relevant. So MIP6 essentially is a fallback when the MN moves to
networks which are not part of a PMIP6 domain.

> like "this is what they're doing". I know! I read the 3GPP specs many times.

:) Just making sure that you are indeed reading those 3GPP specs....

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 01 Oct 2008 23:54:06 -0500

Hi Hesham,

Just one question:

> checked, then the LMA's BC is checked if no entry was found in the HA's BC.

What is the reason for the above order of checking the BCs? Is it because of
the hierarchical model view? If you consider PMIP6 and MIP6 as being
essentially equivalent mobility (network vs host) protocols, would you still
have the same order of processing?

-Raj

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 02 Oct 2008 17:04:08 +1000

> localized mobility (although PMIP6 can be used in that manner with the

=> Ok, I won't debate this point because it's slightly off-topic but I'm
happy to discuss it with you offline.

> networks which are not part of a PMIP6 domain.

=> I'm not ignoring that fact. My point is, the *way* that the deployment is
assumed is making it difficult for everybody and I am questioning that
particular way of doing things. The two mechanisms can co-exist with less
trouble if it is done properly.

> :) Just making sure that you are indeed reading those 3GPP specs....

=> Trust me, I'll never forget the experience (or trauma) :)

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 02 Oct 2008 17:23:36 +1000

Kilian,

I want to summarise our discussion by saying the following points:

1. I agree with the way you break up the two different ways of solving the
problem. 

2. I agree that under the assumption of the use of the HoA by the LMA and
HA, there is a 1 RTT delay when the MN moves from 3GPP to another access.
This is *assuming* that the MN brings up one interface and tears down the
other. 

I think your assumption that the MN, despite having more than one interface
(3GPP and WLAN for instance; leave out the multiple 3GPP interfaces for
now), will not keep both interfaces up, is a flawed assumption. Why? Because
it defies reality. Think of any device on the market today, laptop, iphone,
Nokia N95, blackberry....etc that have multiple technologies implemented and
tell me which one of those devices only keeps one interface up at the same
time. None! It would be silly if those devices tore down one interface when
the other one appears. Not supporting that would be ignoring reality.

I don't care if 3GPP specs don't explicitly support multihoming. The reality
is if a device supports multiple interfaces you can't force it to have one
interface up at one time.

Your 1 RTT problem would be solved if you do a make-before-break handover
between the technologies. Of course that requires different addresses on
different links.

Now, to bring it back to my point about managing the HoA in the LMA and HA,
how will you handle this reality? Advertise the same prefix on both links?
The argument about Scenario C would be moot if we make sure that the LMA
doesn't manage the HoA at all, which is why I keep asking about the need for
this.

So to summarise, if you're worried about PMIPv6-MIPv6 co-existence in 3GPP,
you are considering movement between different access technologies. If you
are considering that, then it's unacceptable to not consider a
make-before-break handover, i.e. Multihoming. If you accept a
make-before-break handover, then there are no delays to worry, provided of
course that the radio link doesn't disappear on you, which is outside our
control. 

Hesham

---

From: "Kilian Weniger" <[email-masked]>
Date: Thu, 2 Oct 2008 11:11:14 +0200

Hi Hesham,

I didn't say that a make-before-break optimization should not be
considered. I agree that if a make-before-break optimization is possible
the additional 1 RTT handover delay that option 1) introduces can be
saved. However, make-before-break optimization is not always possible:

First of all, please note that our discussion is only about the
MIP6->PMIP6 handover case, i.e., the MN moves from foreign to home link
(because you were mentioning in your email the scenario "3GPP to another
access", which is different since 3GPP is always home link).

A MIP6->PMIP6 handover may or may not involve change of access
technology. For instance, you could move from non-3GPP WLAN access
network 1 to non-3GPP WLAN access network 2 and the operator has
configured access network 2 as PMIP6 domain and MN's MIP6 home link and
access network 2 as MIP6 foreign link. This scenario is possible in 3GPP
and assuming the MN has only one WLAN interface, make-before-break is
not possible here.

And even if the access technology changes, make-before-break is not
always possible, e.g., when old and new access technology are using same
frequency band it may not be possible due to interference. Or when the
MN moves out of coverage it may not be possible, as you mentioned.

Since we are talking about MIP6->PMIP6 handover case, the
out-of-coverage problem may not be so rare. For instance, the MN may
move from WLAN foreign link (using MIP6) to 3GPP home link (using
PMIP6). In such probably not uncommon scenario the MN may not be able to
do make-before-break, since it may loose WLAN signal quickly (e.g., move
out coverage).

So in summary, I agree that there are some optimizations possible where
the additional 1 RTT handover delay is not relevant. But in the general
case, the additional 1 RTT handover delay problem of option 1) is
relevant IMHO.

Regards,

Kilian

> Sent: Donnerstag, 2. Oktober 2008 09:24
> To: Basavaraj Patil; Kilian Weniger; Netlmm
> Subject: Re: [netlmm] PMIP6-MIP6 Interactions -on Kilian's 
> concern about delays
> 
> Kilian,
>

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 02 Oct 2008 19:26:31 +1000

> saved. 

=> Ok, so lets note that this will solve the problem then lets address the
other concerns. Please note that in my email I emphasised two points:
1. MBB handover
2. HoA only managed by HA.
I'm afraid I'll keep emphasising point 2 until you or someone else tell me
why it can't be done.

> access", which is different since 3GPP is always home link).

=> Again, note my objection to this assumption about 3GPP being the home
link.

> and assuming the MN has only one WLAN interface, make-before-break is

=> Sure, but if you remove your assumption about PMIP6 being the home link,
then this scenario is a normal handover case.

> MN moves out of coverage it may not be possible, as you mentioned.

=> Yes but now we're getting into typical handover optimisation issues,
there is nothing new or specific to PMIP-MIP6 here.

> do make-before-break, since it may loose WLAN signal quickly (e.g., move

=> Again, this is about typical heuristics for handover, nothing new here.
There is nothing specific to PMIP6-MIP6 if you remove your assumption that
PMIP6 = home link. You need to tell me why you can't change that assumption
in order to make progress in the discussion.

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 02 Oct 2008 20:35:57 +1000

> have the same order of processing?

=> Well, if you have one address that can potentially be in two different
places (even if it's for a short time) and you need to know where to forward
packets to that address then you need to check two places. This is the case
if you *don't* use the hierarchical model. Of course, the next obvious
question is what do you do if you find two different bindings? You need to
choose one... What now?

If you use the hierarchical model this issue doesn't exist because there are
two separate functional elements who are each responsible for a different
address; so there is no confusion.

Hesham

---

From: "Kilian Weniger" <[email-masked]>
Date: Thu, 2 Oct 2008 14:15:09 +0200

Hi Hesham, 

> => Ok, so lets note that this will solve the problem then 

No, let's note that make-before-break optimization is possible in some
cases, but in the general case the problem remains that 1) "Data
forwarding is always done according to MIP6 BCE, if exists" introduces
an additional handover delay of 1 RTT.

> lets address the

I don't want to discuss the need for scenario C again here. First, this
is out of scope of this thread, since this thread is about *how* to
support scenario C. Second, this was already discussed several times on
the ML and all arguments should be on the table (the argument that we
should not ignore that 3GPP has already agreed to support this scenario
is only one of them). It seems to me that you are the only one that
still questions this scenario.

Regards,

Kilian

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 02 Oct 2008 22:36:22 +1000

> cases, but in the general case

=> General case?? Which case is that? The handover between 2 WLANs where one
of them runs PMIP? All your scenarios are predicated on PMIP being the home
link or missing general handover optimisations. Plus you didn't answer my
original question on how you plan to support multihoming; will you just hope
it won't happen?

  the problem remains that 1) "Data
> still questions this scenario.

=> You didn't answer my simple question. When you can answer my question or
send me a link to an answer out of those numerous discussions you refer to
we can continue. 

FYI and for others on the list who don't know this: who do you think
designed the IPv6 address allocation scheme in 3GPP or informed 3GPP about
what IPv6 nodes need to implement or how to behave? It was IETF (IPv6 WG),
after it became clear to both organisations that the existing model at the
time was not working. Have a look at RFCs 3314 and 3316 if you don't believe
it. 

You can ignore the questioning of the core issue if it makes you feel like
you're making progress. But you can't continue with your claims about
performance issues when you know very well that the reason is the wrong
assumption. It remains a wrong assumption until you explain otherwise.

Hesham

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 02 Oct 2008 09:26:52 -0500

> question is what do you do if you find two different bindings? You need to

Right... And that is a problem which can potentially be resolved by marking
one of the BCEs as deprecated or setting some similar flag based on the last
received PBU or BU.

> address; so there is no confusion.

True. I agree.

-Raj

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 2 Oct 2008 14:44:45 -0400

Hesham,

I don't see how your repeatedly questioning the need for scenario C
helps us in this discussion. Can we please move past that?

Vijay

[email-masked] wrote:
>> No, let's note that make-before-break optimization is possible in
>> some cases, but in the general case
> 
>> forwarding is always done according to MIP6 BCE, if exists"
>> introduces an additional handover delay of 1 RTT.
>> 
>>> lets address the
>>> I'm afraid I'll keep emphasising point 2 until you or someone else
>>> tell me why it can't be done.
>> 
>> I don't want to discuss the need for scenario C again here. First,
>> this is out of scope of this thread, since this thread is about
>> *how* to support scenario C. Second, this was already discussed
>> several times on the ML and all arguments should be on the table
>> (the argument that we should not ignore that 3GPP has already agreed
>> to support this scenario is only one of them). It seems to me that
>> you are the only one that still questions this scenario.
> 
>>>> MIP6->PMIP6 handover case, i.e., the MN moves from foreign to home
>>>> link (because you were mentioning in your email the scenario "3GPP
>>>> to another access", which is different since 3GPP is always home
>>>> link). 
>>> 
>>> => Again, note my objection to this assumption about 3GPP being the
>>> home link.
>>> 
>>>> 
>>>> configured access network 2 as PMIP6 domain and MN's MIP6 home
>>>> link and access network 2 as MIP6 foreign link. This scenario is
>>>> possible in 3GPP and assuming the MN has only one WLAN interface,
>>>> make-before-break is not possible here.
>>> 
>>> => Sure, but if you remove your assumption about PMIP6 being the
>>> home link, then this scenario is a normal handover case.
>>> 
>>>> 
>>>> always possible, e.g., when old and new access technology are
>>>> using same frequency band it may not be possible due to
>>>> interference. Or when the MN moves out of coverage it may not be
>>>> possible, as you mentioned. 
>>> 
>>>> out-of-coverage problem may not be so rare. For instance, the MN
>>>> may move from WLAN foreign link (using MIP6) to 3GPP home link
>>>> (using PMIP6). In such probably not uncommon scenario the MN may
>>>> not be able to do make-before-break, since it may loose WLAN
>>>> signal quickly (e.g., move out coverage).
>>> 
>>> => Again, this is about typical heuristics for handover, nothing
>>> new here. There is nothing specific to PMIP6-MIP6 if you remove
>>> your assumption that PMIP6 = home link. You need to tell me why you
>>> can't change that assumption in order to make progress in the
>>> discussion. 
>>> 
>>> Hesham
>>> 
>>> 
>>> 
>>> 
>> 
>>

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 03 Oct 2008 10:26:47 +1000

> helps us in this discussion.

=> That's because you don't understand the consequences of what you're
proposing. 

Hesham

Can we please move past that?

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 2 Oct 2008 20:35:23 -0400

Hesham Soliman wrote:
> => That's because you don't understand the consequences of what
> you're proposing. 

Which one? Scenario C or the solutions for scenario C? I didn't come up
with scenario C. It would help if you recognize the fact that there are
folks who want to deploy scenario C and move on.

Vijay

>>> => General case?? Which case is that? The handover between 2 WLANs
>>> where one of them runs PMIP? All your scenarios are predicated on
>>> PMIP being the home link or missing general handover optimisations.
>>> Plus you didn't answer my original question on how you plan to
>>> support multihoming; will you just hope it won't happen?
>>> 
>>>> (the argument that we should not ignore that 3GPP has already
>>>> agreed to support this scenario is only one of them). It seems to
>>>> me that you are the only one that still questions this scenario.
>>> 
>>> => You didn't answer my simple question. When you can answer my
>>> question or send me a link to an answer out of those numerous
>>> discussions you refer to we can continue.
>>> 
>>> designed the IPv6 address allocation scheme in 3GPP or informed
>>> 3GPP about what IPv6 nodes need to implement or how to behave? It
>>> was IETF (IPv6 WG), after it became clear to both organisations
>>> that the existing model at the time was not working. Have a look at
>>> RFCs 3314 and 3316 if you don't believe it.
>>> 
>>> You can ignore the questioning of the core issue if it makes you
>>> feel like you're making progress. But you can't continue with your
>>> claims about performance issues when you know very well that the
>>> reason is the wrong assumption. It remains a wrong assumption until
>>> you explain otherwise. 
>>> 
>>> Hesham
>>> 
>>> 
>>> 
>>>> 
>>>> Regards,
>>>> 
>>>> Kilian
>>>> 
>>>>> 
>>>>>> MIP6->PMIP6 handover case, i.e., the MN moves from foreign to
>>>>>> home link (because you were mentioning in your email the
>>>>>> scenario "3GPP to another access", which is different since 3GPP
>>>>>> is always home link).
>>>>> 
>>>>> => Again, note my objection to this assumption about 3GPP being
>>>>> the home link. 
>>>>> 
>>>>>> 
>>>>>> technology. For instance, you could move from non-3GPP WLAN
>>>>>> access network 1 to non-3GPP WLAN access network 2 and the
>>>>>> operator has configured access network 2 as PMIP6 domain and
>>>>>> MN's MIP6 home link and access network 2 as MIP6 foreign link.
>>>>>> This scenario is possible in 3GPP and assuming the MN has only
>>>>>> one WLAN interface, make-before-break is not possible here.
>>>>> 
>>>>>> And even if the access technology changes, make-before-break is
>>>>>> not always possible, e.g., when old and new access technology are
>>>>> your assumption that PMIP6 = home link. You need to tell me why
>>>>> you can't change that assumption in order to make progress in the
>>>>> discussion. 
>>>>> 
>>>>> Hesham
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>>

---

From: "Premec, Domagoj" <[email-masked]>
Date: Fri, 3 Oct 2008 14:34:04 +0200

Hi Killian,

> Hence, 1) "Data forwarding is always done according to
> MIP6 BCE" introduces an additional handover delay of at least 
> 1 RTT between MN and HA/LMA (i.e., PBA + RA + BU de-reg).  

Does the calculation cover the race condition case where the LMA needs to double check with the MAG/MN the actual delivery destination, or is the calculation different in that case?

domagoj

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Kilian Weniger
> Sent: 01. listopad 2008 14:56
> To: Netlmm
> EntryManagement - Please comment
> 
> Hi Hesham,
> 
> as I wrote in an earlier email, in my opinion we should not 
> discuss single vs. separate BCE implementation option. We 
> should discuss whether external HA behaviour should be according to:
> 
> 1) Data forwarding is always done according to MIP6 BCE, if 
> exists, no matter whether PMIP6 BCE exists or not. Only if 
> MIP6 BCE is empty, PMIP6 BCE is used (i.e., MIP6 BCE always 
> has priority over PMIP6 BCE) or
> 
> 2) Data forwarding is done according to last received 
> registration (i.e., MIP6 and PMIP6 BCE have equal priority). 
> 
> I assume that in your email you refer to 1) when you talk 
> about separate BCE, since this is the approach described in 
> George's slides (which uses separate BCE implementation option).
> 
> To answer your question: As mentioned in my previous emails, 
> IMHO the main problem of 1) is the increased handover delay 
> in MIP6->PMIP6 transition case. In 1) the HA only starts 
> forwarding data packets to the MN's new location after it has 
> received the BU de-registration. In 2) the HA starts 
> forwarding data packets to the MN's new location once the PBU 
> is received. Hence, 1) "Data forwarding is always done according to
> MIP6 BCE" introduces an additional handover delay of at least 
> 1 RTT between MN and HA/LMA (i.e., PBA + RA + BU de-reg). 
> 
> Due to the additional 1 RTT handover delay of 1), the HA 
> behaviour according to 2) "Data forwarding is done according 
> to last received registration" is preferable IMHO.
> 
> Regards,
> 
> Kilian
> 
> > Subject: Re: [netlmm] PMIP6-MIP6 Interactions - Binding Cache Entry 
> > Management - Please comment
> > 
> > 
> > > 
> > >> this, requires rationale by the people suggesting that. The only 
> > >> rationale I heard so far is memory consumption. This is an 
> > >> extremely weak argument.
> > > 
> > => I knew the word "natural" will cause confusion. What I 
> mean is that 
> > the natural way to do things, according to MIPv6 (and as 
> you mention 
> > above its
> > entities manage the same binding causes numerous problems 
> as discussed 
> > in the meeting and slides. In this case, we have two 
> entities, the MN 
> > and the MAG. Hence, the argument for functional separation. This is 
> > not an abstract argument, as we've already discussed the negative 
> > consequences of doing the alternative.
> > > Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: 
> Thomas Micke
> > > 
> > >

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 8 Oct 2008 11:24:58 +0200

Hi Domagoj,

> Does the calculation cover the race condition case where the 
> LMA needs to double check with the MAG/MN the actual delivery 
> destination, or is the calculation different in that case?

Once a registration of different type (PBU after BU or vice versa) is
received by the HA/LMA, the LMA can double check with the MAG/MN the
actual delivery destination. During the time the double check is
performed, the HA/LMA can already start forwarding data to the
destination specified in the last received registration. Since this is
the correct destination in normal case (normal case=PBU/BU have not
overtaken each other), there is no additional delay with option 1).

So answer is yes, the calculation covers the double check with MAG/MN.

Kilian

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 8 Oct 2008 18:10:46 +0200

Hi Domagoj, 

there was a typo in my reply to your question. Please find below the
corrected version (correction marked with "**").

overtaken each other), there is no additional delay with *option 2)*.

Kilian