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

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 1 Oct 2008 10:27:08 -0700

Hi Kilian,

> -----Original Message-----
> From: Kilian Weniger [mailto:[email-masked]]
> Sent: Wednesday, October 01, 2008 1:38 AM
> To: Giaretta, Gerardo
> Cc: Netlmm
> Subject: RE: [netlmm] PMIP6-MIP6 Interactions - Binding Cache Entry
> Management - Please comment
>
> Hi Gerardo,
>
> > I think that Kilian's made a good point in his email that the
> > issue is probably not about separate vs single BCEs but more
> > about how the HA routes the packets.
> >
> > Based on his analysis I think we should specify that "Data
> > forwarding is always done according to MIP6 BCE, if exists,
> > no matter whether PMIP6 BCE exists or not". This seems to be
> > the most flexible solution as it works in any scenario.
> > Moreover, we will not need to revisit any specification when
> > multiple CoAs and IP flow mobility will come into the picture.
>
> Can you explain why one data forwarding option is more flexible than
> the
> other and how the data forwarding options are related to MCoA?
>

It is more flexible as it works with any possible scenario we have described as you indicated in your email.

> One benefit of the "Data forwarding is done according to last received
> registration" option is that the handover performance in terms of delay
> is typically faster.
>

As discussed in this thread, that is true only for some scenarios and there are other tools to deal with that. We should provide a generic framework of PMIP-MIP interaction and not provide handover optimization for that in this document. Otherwise we should broaden the discussion to include all possible handover optimizations.

> > The de-registration BU will be the first packet sent by the
> > MN. The difference in terms of packet loss may be just
> > insignificant and if one is concerned about packet loss then
> > buffering of packets after a PBU is received can be
> > performed. But I don't think that would be even needed: for
> > example in E-UTRAN (as you like the 3GPP example) the uplink
> > link is established before the downlink one so the
> > de-registration BU will not add any significant delay.
>
> Of course packet loss can be prevented by buffering, but packet delay
> cannot.
>

You mentioned packet loss, not me :-)

And again you are talking about handover optimizations which I think is not the main point of this work

> Regarding your argument about E-UTRAN, as far as I know this is not
> fully correct. There are two options for PMIP case: Depending on
> whether
> S-GW (MAG) receives UE (MN)'s IP address via PCC or not, the S-GW sends
> PBU before or after radio bearer establishment (see section 8.2.1.2 in
> TS 23.402). So your argument does apply for only one option in E-UTRAN
> (i.e., only if no PCC is used). And it does not apply to handovers to
> other access technologies.
>

True. This is exactly my point: the case you are trying to solve is a very specific E-UTRAN case that I don't think should affect what IETF thinks and specifies on PMIP-MIP interactions

Regards
Gerardo

> So in the general case, handover performance in terms of delay is
> better
> with the option "Data forwarding is done according to last received
> registration".
>
> 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

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 1 Oct 2008 10:34:51 -0700

> Subject: RE: [netlmm] PMIP6-MIP6 Interactions - Binding CacheEntry
> > Multiple CoAs is not needed to be multihomed in particular in
> > the case where the home link is a p2p link. The MN may just
> > attach to the home link (e.g. for handover preparation) but
> > still keeping the DSMIPv6 binding valid (i.e. avoid using
> > directly the HoA and letting the HA intercepting packets).
> > This was discussed several times and has nothing to do with MCoAs.
>
> IMHO, supporting this scenario is not related to CMIP PMIP
> interactions.

We need to define a solution which does not need to be changed when we include multihoming support.

> The scenario is that the MN is attaching to a new MAG, but the LMA is
> still forwarding data to the old location. This is also not possible in
> pure PMIP (MAG1->MAG2) handover scenarios. The reason is that layer 2
> and layer 3 handover currently cannot be done independently in PMIP.
> Hence, this is a pure PMIP problem.
>

Sorry I did not get this scenario and why it relates to the scenario we are discussing. Multihoming does not require PMIP multihoming but UE being multihomed for DSMIPv6 and one CoA managed by PMIP or the home link managed by PMIP

> In my opinion, if you want to support this scenario, you should propose
> a PMIP extension.

This has nothing to do with PMIP multihoming.

Gerardo

> Once this extension is specified, your scenario is
> supported in all PMIP handover scenarios and also automatically in the
> PMIP CMIP handover case.
>
> Regards,
>
> Kilian
>
> >
> > Gerardo
> >
> > > Perhaps it would be better if we focus on how to support both
> > > scenarios.
> > >
> > >
> > > Vijay
> > >
> > > > 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

---

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

Hi Gerardo, 

> It is more flexible as it works with any possible scenario we 
> have described as you indicated in your email.
 
Please be more specific. Which scenario is not possible with 1) or 2)?

Do you refer to "Approach 1) is only possible with separate BCE, whereas
2) is possible
with both separate and single/shared BCE." So according to that 2) "Data
forwarding is done according to last received registration" is more
flexible.

> As discussed in this thread, that is true only for some 
> scenarios 

It is true for the vast majority of cases that 2) has better handover
performance than 1). And in the remaining few cases, both options have
equal handover performance. 

> and there are other tools to deal with that. We 

Which tools can improve handover delay for option 1)? I.e., how can you
improve handover delay if the HA always only starts forwarding to the
new location after receiving the second of two location updates? 

> should provide a generic framework of PMIP-MIP interaction 
> and not provide handover optimization for that in this 
> document. Otherwise we should broaden the discussion to 
> include all possible handover optimizations.

Gerardo, this is not about optimizations. 2) "Data forwarding is done
according to last received registration" has the handover performance of
today's mobility management protocols, so no optimization. 

Your proposed solution 1) introduces an additional 1 RTT handover delay
over today's mobility management protocols. 

Further optimizations can still be discussed and may also be possible
for 2) "Data forwarding is done according to last received
registration".

You propose option 1), where the HA/LMA starts forwarding only after
receiving a second of two consecutive location updates. Can you explain
why the HA/LMA should ignore the first location update with respect to
data forwarding, if it contains all the information that allow the
HA/LMA to forward data to the new MN location?

Every other mobility management protocol (MIP, PMIP) starts forwarding
after the first received location update. 

> You mentioned packet loss, not me :-)

I don't know which emails you are referring to, but I did not mention
packet loss in any email of this thread (except of this email now ;).

> 
> And again you are talking about handover optimizations which 
> I think is not the main point of this work

This is not about optimization, please see above.

> True. This is exactly my point: the case you are trying to 
> solve is a very specific E-UTRAN case that I don't think 
> should affect what IETF thinks and specifies on PMIP-MIP interactions

Gerardo, you are mixing things up.

You were saying "the uplink link is established before the downlink one
so the de-registration BU [your proposed solution 1)] will not add any
significant delay."

I was saying that "uplink link is established before the downlink" is
only true for a very specific case, which is E-UTRAN without PCC. For
E-UTRAN with PCC and for other access technology like WLAN this is not
true.

This means that in the very most cases your solution 1) "Data forwarding
is always done according to MIP6 BCE, if exists" introduces an
additional delay.

Regards,

Kilian

---

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

Hi Gerardo, 

> We need to define a solution which does not need to be 
> changed when we include multihoming support.

Gerardo, please be more specific. Which solution need to be changed to
include multihoming support? Why? What do you mean by multihoming?

I was referring to the "handover preparation" scenario you raised above
in your email: "The MN may just attach to the home link (e.g. for
handover preparation) but still keeping the DSMIPv6 binding valid (i.e.
avoid using directly the HoA and letting the HA intercepting packets)."
I was saying that this is not related to CMIP PMIP interacions, since it
is a pure PMIP problem (see below).

> Sorry I did not get this scenario and why it relates to the 
> scenario we are discussing. Multihoming does not require PMIP 
> multihoming but UE being multihomed for DSMIPv6 and one CoA 
> managed by PMIP or the home link managed by PMIP

You raised the "handover preparation" scenario above, where the MN
attaches to the new link (in your example the home link) for handover
preparation, but the HA/LMA still keeps sending data packets to the
"old" location (in your example avoid using directly the HoA and letting
the HA intercepting packets) as opposed to the new location (home link).

My point is why do you need this "handover preparation" optimization
(BTW, didn't you say in another email that we should not talk about
optimizations now)? 

And if it is needed, why do you need it only for MIP6->PMIP6 handovers
and not for PMIP6->PMIP6 handovers, because it can equally apply to
MAG->MAG handovers? 

If this is needed, it would be better to design a general solution,
which does not only work for MIP6->PMIP6 handovers. You can extend PMIP6
to support that, e.g., by allowing the MN to signal to the MAG that it
wants to delay the PBU registration because of handover preparation
(delay by specific time or till the MN triggers the MAG to send the
registration). Then the "handover preparation" scenario that you raised
above can be supported for every PMIP handover (MAG->MAG) and
automatically for MIP6->PMIP6 handover. 

> This has nothing to do with PMIP multihoming.

Did I say so? I was just referring to the "handover preparation"
scenario you raised above.

Kilian