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

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
>Cc: Christian Vogt; Mohana Jeyatharan; NETLMM Mailing List
>Betreff: Re: [netlmm] PMIP6-MIP6 Interactions - Take 2
>
>Hi Gerardo, 
>
>> > 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.
>> > 
>> 
>> 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
>
>> 
>> Gerardo
>> 
>> > 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).
>> > 
>> > >
>> > > >
>> > > > What I don't understand are two things:
>> > > > 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?
>> > 
>> > 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
>> > 
>> > >
>> > > -Raj
>> > >
>> > > >
>> > > > 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
>> > >
>> > >
>> > >
>> > 
>> > 
>> > 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
>> 
>> 
>
>
>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
>
_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop