Subject: Re: [netlmm] PMIP6-MIP6 Interactions - Take 2

From: "Kilian Weniger" <[email-masked]>
Date: Mon, 3 Nov 2008 17:33:54 +0100

Hesham,

> > I prefer to talk about specific scenarios ;) I assume that "MIPv6
> > multihoming" refers to the scenario in section 5.3 of your 
> draft that
> > you referenced in an earlier email. So the scenario you 
> want to support
> > is that a MN attaches to a PMIP home link with a second 
> interface, but
> > wants to direct the traffic to this interface later (i.e., 
> not at time
> > of attachment), right?
> > 
> > What I don't understand are two things:
> > 1.) why this scenario is essential to be supported.
> => It's a no brainer IMO. There is a high percentage of *existing* 3G
> devices that are capable of multihoming today. I'm using two 
> of them right
> now. Project that to the time of deployment of what we're 
> doing here and it
> becomes an essential requirement.

I didn't ask why multihoming in general is needed. I agree it is. I was
referring to the very specific scenario of section 5.3, which I
summarized above and which was the main argument against approach b). So
the question is: Why is it essential to support a scenario where a MN
has a first interface running MIP, then attaches to a PMIP home link
with a second interface, but *the MN does not want that the traffic is
directed to this second interface at time of attachment*. 

Note that this scenario is not even supported when the MN uses PMIP
instead of MIP on the first interface. So why is this scenario where MIP
is used on the first interface essential in your opinion, but the
scenario where PMIP is used on the first interface is not essential?

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: Basavaraj Patil <[email-masked]>
Date: Mon, 03 Nov 2008 11:05:10 -0500

Hi Kilian,

A few comments inline:

On 10/31/08 10:08 AM, "ext Kilian Weniger" <[email-masked]>
wrote:

> Hi Suresh, 
> 
>> I think this is where we have a disconnect. MIPv6 does support these
>> scenarios and, in the presence of PMIPv6 with b) MIPv6 multihoming
> breaks.
> 
> multihoming" refers to the scenario in section 5.3 of your draft that
> you referenced in an earlier email. So the scenario you want to support
> is that a MN attaches to a PMIP home link with a second interface, but
> wants to direct the traffic to this interface later (i.e., not at time
> of attachment), right?

If the MN attaches via a second interface to its home link, it may not
necessarily imply that the previous registration (DSMIP6) needs to be
deprecated. So the assumption that the MN wants to direct the traffic to
interface 2 later is incorrect. Both registrations should be maintained.
Traffic which has thde destination address that matches the /128 address in
the DSMIP6 BCE is sent via IF1 and anything else is forwarded by the home
link BCE (prefix match).

> 1.) why this scenario is essential to be supported.

Because the MN intends to maintain both BCEs and have connectivity via both
interfaces. 

> 2.) why is it only essential for MIPv6 handover scenarios and not for
> PMIPv6 (i.e., MAG1->MAG2) handover scenarios? Because PMIPv6 does not
> support this scenario.
> 
> Anyway, this scenario can be supported with approach b) in interaction
> scenarios or even in pure PMIP scenarios, when PMIP is extended to allow
> the MN to signal during attach that PBU shall be delayed by some time or
> until MN explicitly triggers it.

At least there is no way for the MN to explicitly trigger the PBU, right? At
least not with the current specs and scope of Netlmm. What is the reason to
delay the PBU?

-Raj

---

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 4 Nov 2008 10:05:55 +0100

Hi Basavaraj, 

> the DSMIP6 BCE is sent via IF1 and anything else is forwarded 

I was referring to the specific scenario described in section 5.3 of
draft-tsirtsis, where the MN wants to delay the direction of traffic to
the interface that attaches to the home link. This scenario was brought
up by others as an argument against the approach to do forwarding
according to latest received registration. I have not yet received an
answer why this scenario is needed.

If the MN wants to use both home and foreign interface for traffic
simultaneously,  it can do so by using H-flag in BU de-reg, as specified
in MCoA draft. That also works for approach b).

> least not with the current specs and scope of Netlmm. What is 

Exactly, in case of PMIP handovers this is currently not supported. So
why do some people think that this scenario is essential to be supported
specifically for the MIP->PMIP handover case?

Kilian

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 04 Nov 2008 20:43:17 +1100

> directed to this second interface at time of attachment*.

=> Because that's how multihomed hosts behave. Two interfaces might be up
but the traffic is only going to one of them. That *is* multihoming in
general. This is why I keep referring to existing devices, that's what they
do. I'm surprised you don't see this as normal operating behaviour.

> instead of MIP on the first interface.

=> Of course it's not supported, PMIP is not exactly great for multihoming.

 So why is this scenario where MIP
> scenario where PMIP is used on the first interface is not essential?

=> :) You're using the lack of support in PMIP to make it sound like
multihoming support is not needed. It's important in all scenarios, it's
just that PMIP lacks some fundamental features due to the brilliant idea of
elimintaing the MN's involvement in mobility. I.e. To answer your question,
it's not supported by PMIP because PMIP is flawed.

Hesham

---

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 4 Nov 2008 12:00:48 +0100

> do. I'm surprised you don't see this as normal operating behaviour.

Hesham, multihoming is a very broad term. I wouldn't agree that the
specific scenario you brought up is "multihoming in general". We need to
be more specific regarding multihoming to have a meaningful technical
discussion. 

A "delayed BU de-registration" as described in section 5.3 for achieving
some kind of "multihoming" is not even described in any IETF
specification.

Other scenarios of MIP multihoming like flow filtering and MCoA can be
supported with both approach a) and b) IMHO.

> => Of course it's not supported, PMIP is not exactly great 

right, not yet. I think that is the root of the issue.

> multihoming support is not needed. It's important in all 

We are talking about "PMIP-MIP interactions multihoming" only here and I
didn't say it is not needed in general. 

But I think it would make more sense to discuss those PMIP-MIP
interactions multihoming issues that are actually PMIP multihoming
issues once PMIP multihoming support specification is more clear.

Kilian

> scenarios, it's

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 04 Nov 2008 23:55:21 +1100

> Hesham, multihoming is a very broad term.

=> No it's not. Multihoming is well defined. I think you're confusing the
word "multihoming" with the different scenarios that can take place as a
result of being multihomed. More below.

I wouldn't agree that the
> be more specific regarding multihoming to have a meaningful technical

=> We're not building a product here, we need to be able to support a
scenario where a node can have two interfaces up, active, and configure IP
addresses on both. This is what multihoming means. In your product you can
get specific about the level of support you want to provide for this
scenario. In *standards* we need to enable this scenario. I think I said why
we need to enable that many times before.

> some kind of "multihoming" is not even described in any IETF

=> You're talking about a specific solution. I'm not interested in picking a
solution now, I was answering your question about why we need to support
this scenario, which to me implies: "why do we need to support
multihoming?".

> supported with both approach a) and b) IMHO.

=> Again, you're talking about optimisations and different levels of
support. This is *not* what the word "multihoming" means. If we can't get
the basic definitions right it's difficult to discuss solutions.

Hesham

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Tue, 4 Nov 2008 11:02:49 -0800

Hi Kilian,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Kilian Weniger
> Sent: Tuesday, November 04, 2008 1:06 AM
> To: Basavaraj Patil; ext Kilian Weniger; Suresh Krishnan
> Cc: Christian Vogt; Mohana Jeyatharan; NETLMM Mailing List
> Subject: Re: [netlmm] PMIP6-MIP6 Interactions - Take 2
> 
> Hi Basavaraj,
> 

This is the usual procedure for vertical handovers. Since the MN is dual radio it can connect to one access, prepare the access in advance and then move the data later whenever it wants. In this way you don't need FMIPv6 or other optimizations.

The main point you don't get is that technically from a MN point of view this is not about MIP-PMIP handovers. This is about a MIP handover to a home link which happens to be a PMIP domain (and this is transparent to the MN). Therefore everything which works in a normal MIP handover must work also in this scenario. 

Gerardo

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 5 Nov 2008 15:59:36 +0100

Hi Gerardo, 

> This is the usual procedure for vertical handovers. Since the 
> MN is dual radio it can connect to one access, prepare the 
> access in advance and then move the data later whenever it 
> wants. In this way you don't need FMIPv6 or other optimizations.

So you say that this feature is needed to improve handover performance?
I wouldn't agree to that. 

Even with approach b) the MN can send/receive data via the first
interface while the second interface sets up the radio bearer. The
traffic is redirected to the second interface once the attach procedure
is complete and the PBU reaches the LMA. So in dual radio case, the
handover performance of approach b) should not be worse than that of
approach a). In single radio case, approach b) is obviously better than
approach a) (i.e., 1 RTT lower handover delay), as already discussed.

Actually, a vertical foreign-home handover with approach b) has same
handover performance than a vertical PMIP handover.

> 
> The main point you don't get is that technically from a MN 
> point of view this is not about MIP-PMIP handovers. This is 
> about a MIP handover to a home link which happens to be a 
> PMIP domain (and this is transparent to the MN). Therefore 
> everything which works in a normal MIP handover must work 
> also in this scenario.

A normal MIP handover works with approach b). So far, only two special
scenarios were brought up as issues:
1) the MN wants to delay the redirection of traffic by some amount of
time after a vertical handover from foreign to home link by sending a
delayed BU de-reg. I still have not seen a convincing answer why this is
important to support. This is not specified in RFC3775 or anywhere else
and PMIP does not support it either. If PMIP is extended to support it,
approach b) supports it as well.
2) MN has multiple interfaces up and uses foreign link interface for
sending/receiving traffic. MN does horizontal handover within the home
link, but doesn't want to redirect the traffic to this interface. This
can be solved by considering HI flags in PBU and/or with flow filters.

Kilian

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 5 Nov 2008 13:48:56 -0800

Hi Kilian,

> From: Kilian Weniger [mailto:[email-masked]]
> Sent: Wednesday, November 05, 2008 7:00 AM
> To: Giaretta, Gerardo; Kilian Weniger; Basavaraj Patil; Suresh Krishnan
> Subject: RE: [netlmm] PMIP6-MIP6 Interactions - Take 2
> 
> Hi Gerardo,
> 

Fair enough - at this point we can agree we disagree.

A MN attached to WLAN may want to attach to a cellular network in order to be ready for a handover, but still having the flows in WLAN when this is available. This is the easiest way of designing an optimized handover for a dual radio terminal without any need of special pre-authentication procedures and complex interactions in the backend. 

I see a lot of value in this multihoming scenario which does not require MCoA and allows handover optimizations. You don't see any value on this and that's ok - we cannot agree on everything :-)

Gerardo

---

From: "BLUME, Oliver" <[email-masked]>
Date: Thu, 6 Nov 2008 11:07:22 +0100

Hi Kilian,

please let me just point to some work in MIPSHOP that may be of interest here .

> If PMIP is extended to support it, approach b) supports it as well.

I agree to your statement that PMIP doesn't support delaying of PBU at nMAG (e.g. MAG on home link). But actually, MIPSHOP currently is specifying a way to allow this in the way that the PBU comes with a "transient binding" option. This option indicates that the LMA shall not yet forward traffic to the MN via nMAG (i.e. the home link in this case). Later, a second PBU (without the option) can be used to start forwarding through the tunnel to nMAG. With this extension delaying would be possible. (see http://www.ietf.org/internet-drafts/draft-ietf-mipshop-transient-bce-pmipv6-00.txt . An earlier version of this has been discussed as an individual draft to netlmm in Philadelphia)  

A use case for delaying occurs when the link layer is not yet finalised (e.g. during bearer setup between access point and MAG in the home link). Another use case may be that at the time of the PBU the radio channel to the home link is still quite weak and the nMAG preferes to wait until the MN comes closer into the coverage of the home link. Meanwhile the foreign MIP link may still be used.

Please not that this should also work for the opposite HO, i.e. for a HO from PMIP home link to a foreign MIP link, at least for approach b).

Regards,

Oliver

>-----Ursprüngliche Nachricht-----
>Von: [email-masked] [mailto:[email-masked]] 
>Im Auftrag von Kilian Weniger
>Gesendet: Mittwoch, 5. November 2008 16:00
>An: Giaretta, Gerardo; Kilian Weniger; Basavaraj Patil; Suresh Krishnan
>Betreff: Re: [netlmm] PMIP6-MIP6 Interactions - Take 2
>
>Hi Gerardo, 
>
>> This is the usual procedure for vertical handovers. Since the MN is 
>> dual radio it can connect to one access, prepare the access 
>in advance 
>> and then move the data later whenever it wants. In this way 
>you don't 
>> need FMIPv6 or other optimizations.
>
>Even with approach b) the MN can send/receive data via the 
>first interface while the second interface sets up the radio 
>bearer. The traffic is redirected to the second interface once 
>the attach procedure is complete and the PBU reaches the LMA. 
>So in dual radio case, the handover performance of approach b) 
>should not be worse than that of approach a). In single radio 
>case, approach b) is obviously better than approach a) (i.e., 
>1 RTT lower handover delay), as already discussed.
>
>Actually, a vertical foreign-home handover with approach b) 
>has same handover performance than a vertical PMIP handover.
>
>> 
>> The main point you don't get is that technically from a MN point of 
>> view this is not about MIP-PMIP handovers. This is about a MIP 
>> handover to a home link which happens to be a PMIP domain 
>(and this is 
>> transparent to the MN). Therefore everything which works in a normal 
>> MIP handover must work also in this scenario.
>
>A normal MIP handover works with approach b). So far, only two 
>special scenarios were brought up as issues:
>1) the MN wants to delay the redirection of traffic by some 
>amount of time after a vertical handover from foreign to home 
>link by sending a delayed BU de-reg. I still have not seen a 
>convincing answer why this is important to support. This is 
>not specified in RFC3775 or anywhere else and PMIP does not 
>support it either. If PMIP is extended to support it, approach 
>b) supports it as well.
>2) MN has multiple interfaces up and uses foreign link 
>interface for sending/receiving traffic. MN does horizontal 
>handover within the home link, but doesn't want to redirect 
>the traffic to this interface. This can be solved by 
>considering HI flags in PBU and/or with flow filters.
>
>
>Kilian
>
>> 
>> Gerardo
>> 
>> > > Because the MN intends to maintain both BCEs and have 
>connectivity 
>> > > via both interfaces.
>> > >
>> > > At least there is no way for the MN to explicitly 
>trigger the PBU, 
>> > > right? At least not with the current specs and scope of Netlmm. 
>> > > What is the reason to delay the PBU?
>> > 
>> > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas 
>> > > > Micke
>> > > >
>> > > >
>> > Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: 
>Thomas Micke
>> > 
>> >