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

From: "Mohana Jeyatharan" <[email-masked]>
Date: Mon, 3 Nov 2008 09:21:28 +0800

Hi Vijay and All,

Thanks Vijay for highlighting. This is what I also feel. You cant
support a multihomed node without adequate multihoming support at
LMA/HA. Also as Vijay pointed out in a previous mail that what
multhoming w.r.t to the MN needs to be defined. Is this node a Monami6
type of mobile node. If it is, then there needs to be adequate support
at LMA/HA. We cant make multihoming work without such support. 

As all of us can remember, for multhoming, PMIPv6 RFC needed to be
defined in a certain way. Similarly for MIPv6 node to support
multihoming (such as packets to a single home address needs to be
tarversed via all interfaces or chosen specific interfaces) we needed
Monami 6 solution. Similary for scenario C, if we are considering
multihoming, which is identical to MCoA simulatneous attchment via home
and away, we need appropriate protocol extensions. I think that is what
Vijay is stressing and I fully agree with this.

BR,
Mohana

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Saturday, November 01, 2008 1:48 AM
> To: Christian Vogt; Kilian Weniger
> Cc: Mohana Jeyatharan; NETLMM Mailing List
> Subject: RE: [netlmm] PMIP6-MIP6 Interactions - Take 2
> 
> [email-masked] wrote:
> > Hi Kilian -
> > 
> >> As I wrote in another email and as Mohanna explained, im 
> my opinion 
> >> multihoming scenarios that are not yet supported by PMIP should be 
> >> out of scope of this discussion. [...]
> > 
> > I don't think it matters whether or not P-MIP supports multi-homing.
> > Option (a) has a potential to break multi-homing in either 
> case.  In 
> > fact, the issue only comes up if multi-homing is handled by
> > (host-based) MIP.  The example I gave shows this:  The mobile host 
> > uses MIP to make use of a second interface, and P-MIP still 
> interferes 
> > with this.
> 
> It doesn't if the HA/LMA entity is made aware of this. The 
> HA/LMA entity would maintain both bindings if that is what 
> the mobile node wants to do. The mobile node just needs to 
> send a BU, with the 'H' flag set in the BID option to make 
> sure it can be connected via the home link and the visited 
> link at the same time. See 
> draft-ietf-monami6-multiplecoa-09.txt. Version 10 will be 
> submitted very soon.
> 
> Vijay
> 

_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: "Premec, Domagoj" <[email-masked]>
Date: Mon, 3 Nov 2008 14:41:33 +0100

Vijay,

> 3GPP, the only customer for handovers across interfaces using 
> PMIPv6, has specified this. The mobile node when it attaches 
> to the MAG indicates via a link layer mechanism whether it is 
> an initial attach or a handover. 

In case where multiple access network are involved, specifying this only on the 3GPP side is not enough. For example, if 3GPP-WiMAX handover is to be supported, then a mechanism is needed to indicate the attach type to the MAG located in the WiMAX access network, and today there is no such mechanism.

FWIW, I prefer the IP layer solution over the link layer. The L2 solution requires going to different SDOs, making changes to the L2 and then updating the probably already deployed equipement. This looks to me like a thight coupling between the PMIP and the (selected) L2 technologies. The IP layer approach is transparent to the L2 and affects only the MAG, which is a new node anyway.

domagoj

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Vijay Devarapalli
> Sent: 31. listopad 2008 18:40
> To: Giaretta, Gerardo; Christian Vogt; Kilian Weniger
> Subject: Re: [netlmm] PMIP6-MIP6 Interactions - Take 2
> 
> Christian, Gerardo,
> 
> On the topic of how the MAG knows what to set the 'HI' to, I 
> agree that RFC 5213 does not specify this. But that was deliberate. 
> 
> 3GPP, the only customer for handovers across interfaces using 
> PMIPv6, has specified this. The mobile node when it attaches 
> to the MAG indicates via a link layer mechanism whether it is 
> an initial attach or a handover. 
> 
> Proposals have been made in the past to the NETLMM WG during 
> the re-chartering process. There were proposals on indicate 
> mobile node capability, on conveying information on whether 
> it is a handover or an attach, etc.. They had quite a bit of 
> support, but were still not added to the charter. The MIPSHOP 
> WG is also working on a standards track document to transfer 
> context from the one MAG to the other. This would also help 
> in determining if the mobile node is performing a handover to 
> another interface or if it is an attach through another interface. 
> 
> I don't understand why we should make an assumption that the 
> MAG would be clueless on what to set 'HI' to. It would result 
> in specifications that won't get used by anyone. WE shouldn't 
> waste time on those.
> 
> Vijay
> 
> >> From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of
> >> Christian Vogt
> >> Sent: Thursday, October 30, 2008 10:25 AM
> >> To: Kilian Weniger
> >> Cc: NETLMM Mailing List; Mohana Jeyatharan
> >> Subject: Re: [netlmm] PMIP6-MIP6 Interactions - Take 2
> >> 
> >> Kilian -
> >> 
> >>> Multi-homing is such a broad topic. If you talk about 
> multihoming, 
> >>> what kind of multi-homing do you mean?
> >>> 1. Multiple interfaces are up, but only one CoA/Proxy-CoA 
> registered 
> >>> at HA/LMA 2. Multiple interfaces are used simultaneously to route 
> >>> traffic
> a.
> >>> 	Multiple CoA b. Multiple Proxy-CoA
> >> 
> >> I meant all of them. :-)  The example I gave illustrates your case 
> >> (1). And things don't seem to become any easier for your case (2).
> >> 
> >>>> consider a host with 3G and WLAN interfaces, of which 
> only the 3G 
> >>>> interface has a home address with mobility support.  The 
> host may 
> >>>> create a MIP binding to redirect traffic for its home 
> address from 
> >>>> 3G to WLAN. In that case, the host certainly wouldn't want the 
> >>>> network to remove that binding due to subsequent 
> movements of the 
> >>>> 3G interface.
> >>> 
> >>> I think this scenario can be solved even with approach 
> "b) forward 
> >>> using the most recently updated BCE" by considering other info in 
> >>> PBU such as Handoff Indicator.
> >> 
> >> You are assuming that a MAG has the knowledge to set the Handoff 
> >> Indicator correctly.  But in general it does not have this 
> knowledge 
> >> because it may not know about a mobile host's additional 
> interfaces.
> >> 
> > 
> > I think this is a key point Christian brought up. I understand 3GPP 
> > can assume that the HI is always set appropriately as it 
> controls the 
> > L2 protocols used for attaching to the network but we 
> cannot make that 
> > assumption in IETF.
> > 
> > Gerardo
> > 
> > 
> >>> The "subsequent movements of 3G interface" would be 
> "Handoff between 
> >>> mobile access gateways for the same interface". So the 
> HA/LMA would 
> >>> just not activate the PMIP BCE, if the MIP BCE is active and PBU 
> >>> arrives with HI flag set to "3: Handoff between mobile access 
> >>> gateways for the same interface".
> >> 
> >> Hold on, now you are back to case A ("Always use the MIP6 BCE and 
> >> only use the PMIP6 BCE when there is no MIP6 BCE"), aren't you?
> >> 
> >> - Christian
> >> 
> >>

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 03 Nov 2008 10:15:56 -0500

Hi Vijay,

Vijay Devarapalli wrote:
> Suresh Krishnan wrote:
>> Hi Vijay,
>> Vijay Devarapalli wrote:
>>>> Hi Vidya,
>>>> Narayanan, Vidya wrote:
>>>>> If there are additional concerns with either approach that
>>>> I have failed to note, please let me know.
>>>>
>>>> With b) an additional concern is that a reordered BU/PBU can result
>>>> in a complete loss of connectivity (absent any yet to be specified
>>>> mitigation measures).
>>>
>>> Suresh, you know very well that the solution for the singe BCE approach
>>> involves sending a binding revocation either to the MAG or the mobile
>>> node when the binding cache is being over-written. So I don't know what
>>> you are talking about.
>>
>> And hence the qualifier "(absent any yet to be specified mitigation 
>> measures)" in my statement. I consider the BRI a mitigation measure. 
>> What else would you call it?
> 
> Sending a binding revocation message *is* part of the solution to avoid 
> the race condition. The text that describes how to avoid the race 
> condition for scenario C in the single BCE approach was proposed more 
> than a year ago. You made it sound as if there is an additional concern 
> that has not been addressed yet.

I would like to know the details of the solution (which you presented in 
IETF72 Dublin) before I am convinced that this will work. Specifically, 
I would like answers to these two questions before you close this and 
file it as "Solved"

* What is a reasonable default value for RACE_CONDITION_PERIOD as 
defined in slide 9 of your slides?

* When does the LMA start forwarding packets when a BU/PBU is received
   a) Immediately after receipt of the latest BU/PBU
   b) After waiting for RACE_CONDITION_PERIOD

Cheers
Suresh

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 3 Nov 2008 20:03:20 -0500

Hi Domagoj, 

> From: Premec, Domagoj [mailto:[email-masked]] 
> Sent: Monday, November 03, 2008 5:42 AM
> To: Vijay Devarapalli; Giaretta, Gerardo; Christian Vogt; 
> Kilian Weniger
> In case where multiple access network are involved, 
> specifying this only on the 3GPP side is not enough. For 
> example, if 3GPP-WiMAX handover is to be supported, then a 
> mechanism is needed to indicate the attach type to the MAG 
> located in the WiMAX access network, and today there is no 
> such mechanism.

I assume one will be defined. WiMAX is still working on 3GPP-WIMAX
handovers using PMIPv6. A MAG-MAG context transfer mechanism can also be
used instead.

Vijay

> FWIW, I prefer the IP layer solution over the link layer. The 
> L2 solution requires going to different SDOs, making changes 
> to the L2 and then updating the probably already deployed 
> equipement. This looks to me like a thight coupling between 
> the PMIP and the (selected) L2 technologies. The IP layer 
> approach is transparent to the L2 and affects only the MAG, 
> which is a new node anyway.
> 
> domagoj
> 
>