Subject: Re: [netlmm] Today's discussion about multihomed MNs

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Mon, 30 Jul 2007 07:02:45 +0300

Hi Hesham,

I don't know if we can disallow it (unless we send the protocol police)...

I think we should put the appropriate health warnings, though. There might
be cases where the two access technologies are in a way or another made to
look like one link and the link driver takes care of the complexity - for
instance if the the two different access technologies are part of the same
access system (e.g. 2G-3G handover in some systems).

However, for the IP stack it looks like one interface.

Cheers,

Jonne.

On 7/30/07 5:00 AM, "ext Hesham Soliman" <[email-masked]> wrote:

> Hi Jonne,  
> 
>> I agree with Sri and Jouni. I don't think the advanced multihoming
>> scenario should be brought to the base spec - at least not in its
>> completeness. 
> 
> => Not only do I agree, I'd go further than that. I don't think we should be
> allowing this scenario. This scenario is not a problem because the MN is
> multihomed. It's a problem because people want to allocate the same prefix to
> more than one link. That's what we should not allow.
> 
> Hesham
> 
> Some text to indicate that if you do this you should
>> better be sure that you handle the consequences.
>> 
>> I think if some system would, however, like to use PMIP for
>> inter-technology handovers it should not be explicitly
>> forbidden. How 
>> that would work and what changes are needed to the MN stack
>> should be 
>> for them to investigate and not for us - at least for now.
>> 
>> Remember, this mail was sent as a participant and not as a chair.
>> 
>> </chair hat on>
>> 
>> Cheers,
>> 
>> Jonne.
>> ext [email-masked] wrote:
>>> I support Sri's view. Keep the base spec as simple as possible.
>>> 
>>> I also have one question for my clarification.. If there is no
>>> DHCP available, then a MN would configure a different MN-HoA for
>>> a new interface after a handover even if the MN-HNP remained the
>>> same, right? Or are folks assuming that we could somehow use the
>>> same interface identifier on all interfaces (could be doable over
>>> GPRS and any PPP link at least..)?
>>> 
>>> My 0.0145732€,
>>> Jouni
>>> 
>>> 
>>>   
>>>> -----Original Message-----
>>>> From: Sri Gundavelli [mailto:[email-masked]]
>>>> Sent: 25. heinäkuuta 2007 23:38
>>>> To: 'Ashutosh Dutta'; 'Jong-Hyouk Lee'
>>>> Cc: [email-masked]
>>>> Subject: RE: [netlmm] Today's discussion about multihomed MNs
>>>> 
>>>> 
>>>> Hi Ashutosh/Jong-Hyouk,
>>>> 
>>>> This scenario of mobile node attaching to multiple access
>>>> links, simultaneously, is an advanced issue.
>>>> This is not in the scope of the base document. These scenario
>>>> of simultaneous multi-access for PMIP should be solved in a
>>>> separate document and its a logical extension to the base
>>>> document. Also:
>>>> 
>>>> - It introduces some challenges from the host perspective,
>>>>   two interfaces being on the same home network prefix.
>>>>   Some host stacks may not be able to handle the same
>>>>   address configuration over multiple interfaces.
>>>> 
>>>> - There were some proposals in 3GPP on defining some virtual
>>>>   interface to handle such scenario's. It requires some
>>>>   investigation and a solution, it may require some changes
>>>>   to the host stack as well.
>>>> 
>>>> Bottom line, this requires some work and if the WG decides to
>>>> bring this into the charter, it should be solved in a
>>>> separate document.
>>>> 
>>>> Sri
>>>> 
>>>> 
>>>>     
>>>>> -----Original Message-----
>>>>> From: Ashutosh Dutta [mailto:[email-masked]]
>>>>> Sent: Wednesday, July 25, 2007 12:29 PM
>>>>> To: Jong-Hyouk Lee
>>>>> Cc: [email-masked]
>>>>> Subject: Re: [netlmm] Today's discussion about multihomed MNs
>>>>> 
>>>>> Agreed, we need to think about if any additional work is
>> needed to 
>>>>> support the multi-homed mobile and avoid such issues.
>> These issues 
>>>>> could
>>>>>   probably be covered in the base protocol document as
>>>>>       
>>>> raised during 
>>>>     
>>>>> the meeting.
>>>>> 
>>>>> Thanks
>>>>> Ashutosh
>>>>> 
>>>>> 
>>>>> Jong-Hyouk Lee wrote:
>>>>>       
>>>>>> Dear Colleagues.
>>>>>>  
>>>>>>> then LMA has to maintain binding with both the MAGs
>>>>>>         
>>>> (similar to  
>>>>     
>>>>>>> simultaneous binding update). In normal case, LMA should
>>>>>>>           
>>>>> overwrite
>>>>>       
>>>>>> the existing
>>>>>>> binding with MAG1 and replace it with the binding with MAG2.
>>>>>> 
>>>>>>>> I don't know how the LMA would know how to do that
>>>>>>         
>>>>> since neither MAG can
>>>>>       
>>>>>>>> know that the MN wants to maintain both connections
>>>>>>         
>>>>> without explicit
>>>>>       
>>>>>>>> signalling from the MN. So I don't think it's a
>> simultaneous 
>>>>>> bindings issue.
>>>>>>  
>>>>>>         
>>>>>       
>>>>>> Well, according to the current PMIPv6 specification, LMA
>>>>>>         
>>>>> will change the
>>>>>       
>>>>>> tunnel endpoint to MAG2. So, I think there would be
>>>>>>         
>>>>> addition works for
>>>>>       
>>>>>> multihomed MNs. As Soliman mentioned, LMA wouldn't know how
>>>>>>         
>>>>> to manage
>>>>>       
>>>>>> the tunnel for multihomed MNs without explicit signallings
>>>>>>         
>>>>> from MAG or MN.
>>>>>       
>>>>>> Cheers.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 7/26/07, *Hesham Soliman* <[email-masked]
>>>>>> <mailto:[email-masked]>> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Hesham,
>>>>>>>          I agree if you would like to use both the
>>>>>>> interfaces (interface
>>>>>>> anchored at MAG1 and interface 2 anchored with
>> MAG2) at the
>>>>>>> same time
>>>>>>> when the mobile is static, this is a typical problem.
>>>>>> 
>>>>>>     => Good, so we agree.
>>>>>> 
>>>>>>       But
>>>>>>> then LMA has
>>>>>>> to maintain binding with both the MAGs (similar to
>>>>>>> simultaneous binding
>>>>>>> update). In normal case, LMA should overwrite
>> the existing
>>>>>>> binding with
>>>>>>> MAG1 and replace it with the binding with MAG2.
>>>>>> 
>>>>>>     => I don't know how the LMA would know how to do that
>>>>>>         
>>>>> since neither
>>>>>       
>>>>>>     MAG can
>>>>>>     know that the MN wants to maintain both connections
>>>>>>         
>>>>> without explicit
>>>>>       
>>>>>>     signalling from the MN. So I don't think it's a simultaneous
>>>>>>     bindings issue.
>>>>>> 
>>>>>> 
>>>>>>     Hesham
>>>>>> 
>>>>>>> 
>>>>>>>      The following is the make-before-break scenario
>>>>>>         
>>>>> I had in mind:
>>>>>       
>>>>>>> 
>>>>>>> Assume that the mobile has two interfaces,
>> 802.11 and CDMA.
>>>>>>> While under
>>>>>>> MAG1 mobile is using WiFi Interface, LMA sends
>> traffic via
>>>>>>> MAG1, and the
>>>>>>> mobile is about to move out of WiFi hotspot and
>>>>>>         
>>>>> makes a move to CDMA
>>>>>       
>>>>>>> access that is controlled by MAG2. So, while the
>> mobile is
>>>>>>> still using
>>>>>>> WiFi access, it can start the PMIP procedure using the
>>>>>>> second interface
>>>>>>> (CDMA interface) with MAG2 (assuming the mobile is under
>>>>>>> CDMA coverage).
>>>>>>> Depending upon when the address gets configured on the
>>>>>>> second interface,
>>>>>>> there maybe potentially an overlap of time when both the
>>>>>>> interfaces can
>>>>>>> have the same addresses momentarily. If MN's address
>>>>>>         
>>>>> does not get
>>>>>       
>>>>>>> configured on CDMA interface, until the Proxy
>>>>>>         
>>>> Binding Update
>>>>     
>>>>>>> from MAG2
>>>>>>> is complete,  this problem maybe avoided by some smart
>>>>>>> algorithm at the
>>>>>>> mobile end.
>>>>>>> 
>>>>>>> Thanks
>>>>>>> Ashutosh
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Hesham Soliman wrote:
>>>>>>>>> 
>>>>>>>>> As discussed during the base draft specification, I
>>>>>>> think this is a
>>>>>>>>> general problem with multi-homed case when the
>>>>>>         
>>>>> mobile uses a
>>>>>       
>>>>>>>>> make-before-break scenario during handover
>> between two
>>>>>>> MAGs, as the
>>>>>>>>> mobile may end up having two same IP
>> addresses on the
>>>>>>> mobile's two
>>>>>>>>> interfaces for a while.
>>>>>>>> 
>>>>>>>> => I don't think that happens in a
>> make-before-break case
>>>>>>> that I've seen.
>>>>>>>> Please explain how this happens in your scenario. Also
>>>>>>> note that I wasn't
>>>>>>>> talking about a handover, this node can be still
>>>>>>         
>>>> for hours.
>>>>     
>>>>>>>> 
>>>>>>>> Hesham
>>>>>>>> 
>>>>>>>>>         However, in case of PMIP-PMIP handover,
>>>>>>         
>>>>> both MAG1 and
>>>>>       
>>>>>>>>> MAG2 having the
>>>>>>>>> ownership MN's binding may not be an issue, as PBU
>>>>>>> through MAG2 will
>>>>>>>>> effectively annul the binding at MAG1, as the
>>>>>>         
>>>>> LMA will be
>>>>>       
>>>>>>>>> updated and
>>>>>>>>> will forward the traffic to MAG2 destined for
>>>>>>         
>>>> interface
>>>>     
>>>>>>> 2 instead of
>>>>>>>>> forwarding the data traffic destined for
>>>>>>         
>>>> interface 1 via
>>>>     
>>>>>>>>> MAG1 before the
>>>>>>>>> handover.
>>>>>>>>> 
>>>>>>>>> Thanks
>>>>>>>>> Ashutosh
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Hesham Soliman wrote:
>>>>>>>>>> Hi,
>>>>>>>>>> 
>>>>>>>>>> I didn't get a chance to explain this at the
>>>>>>         
>>>>> mic so here's
>>>>>       
>>>>>>>>> a followup.
>>>>>>>>>> 
>>>>>>>>>> One of the problems I see with using the home
>>>>>>         
>>>>> prefix in
>>>>>       
>>>>>>>>> NETLMM (i.e.
>>>>>>>>>> scenario C in the
>>>>>>>>>> PMIP-MIP interaction draft) is the case where
>>>>>>         
>>>>> the MN is
>>>>>       
>>>>>>>>> multihomed. If you
>>>>>>>>>> have to allocate the same prefix in the local
>>>>>>         
>>>>> domain (i.e.
>>>>>       
>>>>>>>>> the permanent
>>>>>>>>>> home prefix) then we end up with a problem
>>>>>>         
>>>>> where MAG1 and
>>>>>       
>>>>>>>>> MAG2 both want to
>>>>>>>>>> own the MN's binding. This is obviously a
>>>>>>         
>>>>> broken scenario.
>>>>>       
>>>>>>>>> I don't know how
>>>>>>>>>> this can be solved.
>>>>>>>>>> 
>>>>>>>>>> Hesham
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> netlmm mailing list
>>>>>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/netlmm
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>     _______________________________________________
>>>>>>     netlmm mailing list
>>>>>>     [email-masked] <mailto:[email-masked]>
>>>>>>     https://www1.ietf.org/mailman/listinfo/netlmm
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Internet Management Technology Lab, Sungkyunkwan University.
>>>>>> Jong-Hyouk Lee.
>>>>>> 
>>>>>> #email: jonghyouk (at) gmail (dot) com
>>>>>> #webpage: http://www.hurryon.org
>>>>>>         
>>>>> _______________________________________________
>>>>> netlmm mailing list
>>>>> [email-masked]
>>>>> https://www1.ietf.org/mailman/listinfo/netlmm
>>>>>       
>>>> _______________________________________________
>>>> netlmm mailing list
>>>> [email-masked]
>>>> https://www1.ietf.org/mailman/listinfo/netlmm
>>>> 
>>>>     
>>>> 
>> -------------------------------------------------------------
>> -----------
>>>> 
>>>> _______________________________________________
>>>> netlmm mailing list
>>>> [email-masked]
>>>> https://www1.ietf.org/mailman/listinfo/netlmm
>>>>     
>> 
>> 
>> 
>> _______________________________________________
>> netlmm mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/netlmm
>> 
> 
> 

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

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

---

From: "Hesham Soliman" <[email-masked]>
Date: Mon, 30 Jul 2007 15:11:05 +1000

> I don't know if we can disallow it (unless we send the 

=> Sure, we can't guarantee it, just like we can't guarantee that someone would not configure the same prefix on two different IP links. But we still consider that a misconfig.

 > 
 > I think we should put the appropriate health warnings, 
 > though. 

=> Agreed.

   There might
 > access system (e.g. 2G-3G handover in some systems).

=> Sure, that's one IP link, so it's not an issue for us.

Hesham

---

From: Julien Laganier <[email-masked]>
Date: Mon, 30 Jul 2007 10:59:38 +0200

Folks,

I agree with Jonne here, and this seems consistent with 
what our charter says on the matter: "The protocol 
will not attempt to hide handover between two separate 
interfaces on the mobile node."

--julien 

On Monday 30 July 2007, Soininen Jonne (NSN FI/Espoo) 
wrote:
> I think we should put the appropriate health
> warnings, though. There might be cases where the two
> access technologies are in a way or another made to
> look like one link and the link driver takes care of
> the complexity - for instance if the the two
> different access technologies are part of the same
> >> I agree with Sri and Jouni. I don't think the
> >> advanced multihoming scenario should be brought
> >> to the base spec - at least not in its
> >> completeness.
> >
> > => Not only do I agree, I'd go further than that.
> > I don't think we should be allowing this scenario.
> > This scenario is not a problem because the MN is
> > multihomed. It's a problem because people want to
> > allocate the same prefix to more than one link.
> > That's what we should not allow.
> >
> > Hesham

---

From: "Kalin Getov" <[email-masked]>
Date: Mon, 30 Jul 2007 13:59:07 +0200

Hi all,

if inter-technology handoff == vertical handoff, I think that PMIP is likely to be used for vertical case. Is the issue only for multihomed case or for the standard break before make case also? I don't see why PMIP shouldn't work if there is no more than one active connection over one interface...Am I getting the thing right? Hiding the handover meaning hiding mobility is the default functionality of PMIP. Even between two interfaces (if not simultaneously supporting two active links) is acceptable...

Greetings Kalin

-- 
******************************************
Best Regards
Kalin Getov

[email-masked]
******************************************

GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

---

From: Julien Laganier <[email-masked]>
Date: Mon, 30 Jul 2007 14:27:31 +0200

Hi,

We are not discussing where PMIP is going to be used, 
that's a system level and/or deployment issue.

However, it is pretty clear that PMIP should not try to 
hide handover between two separate interfaces on the 
mobile node since:

   1) That would contradict our charter that 
      says: "The protocol will not attempt to hide
      handover between two separate interfaces on the
      mobile node."

   2) That would require host-support and our charter
      is to develop a protocol that works without host
      involvement. If the host is not involved, how 
      does it handle moving unconfiguring an IP address
      on one interface and assigning it to the other
      interface.

Finally, as Jonne noted, "There might be cases where 
the two access technologies are in a way or another
made to look like one link and the link driver
takes care of the complexity - for instance if
the the two different access technologies are
part of the same access system (e.g. 2G-3G
handover in some systems). However, for the IP stack it 
looks like one interface."

When that is the case, what we actually have is a shim 
layer (or virtual link layer) between the IP layer and 
the link layers (i.e. IP sees only one "virtual" 
interface even though there are really two physical 
interfaces to two different access technologies"). 
In such a scenario NETLMM does not "hide handover 
between two separate interfaces on the mobile node", 
the shim layer does. For such scenarios to be made to 
work would require additional mechanisms to coordinate 
between different *link* layers. 

That is out-of-scope of NETLMM and IETF work. The issue 
can be solved in specific system architectures.

--julien

On Monday 30 July 2007, Kalin Getov wrote:
>  Hi all,
>
> if inter-technology handoff == vertical handoff, I
> think that PMIP is likely to be used for vertical
> case. Is the issue only for multihomed case or for 
> the standard break before make case also? I don't
> see why PMIP shouldn't work if there is no more than
> one active connection over one interface...Am I
> getting the thing right? Hiding the handover meaning
> hiding mobility is the default functionality of
> PMIP. Even between two interfaces (if not
> simultaneously supporting two active links) is
> acceptable...
>
> Greetings Kalin
>
> > Folks,
> >
> > I agree with Jonne here, and this seems consistent
> > with what our charter says on the matter: "The
> > protocol will not attempt to hide handover between
> > two separate interfaces on the mobile node."
> >
> > --julien
> >
> > > warnings, though. There might be cases where the
> > > two access technologies are in a way or another
> > > made to look like one link and the link driver
> > > takes care of the complexity - for instance if
> > > the the two different access technologies are
> > > part of the same access system (e.g. 2G-3G
> > > handover in some systems).
> > >
> > > On 7/30/07 5:00 AM, "ext Hesham Soliman"
> >
> > <[email-masked]> wrote:
> > > > Hi Jonne,
> > > >
> > > >> advanced multihoming scenario should be
> > > >> brought to the base spec - at least not in
> > > >> its completeness.
> > > >
> > > > => Not only do I agree, I'd go further than
> > > > that. I don't think we should be allowing this
> > > > scenario. This scenario is not a problem
> > > > because the MN is multihomed. It's a problem
> > > > because people want to allocate the same
> > > > prefix to more than one link. That's what we
> > > > should not allow.
> > > >
> > > > Hesham
> >

---

From: "Kalin Getov" <[email-masked]>
Date: Mon, 30 Jul 2007 17:08:23 +0200

Hi,

thanks for the clarification. Well maybe I'm understanding the term "to hide handover" in another way...Lets say the MN does inter-technology handoff. I see two possibilities: 1) MN starts MIPv6 precedure (if capable) or 2) PMIP gives the same HNP to the MN and the IP address is reconfigured (both stateless and statefull address configuration models could configure the same IP address), but the IP configuration procedure must be made. 

1) is definitely "not hiding the handover", but what is 2)?

According to an earlier discussion with Sri, he said:

>If Statefull Address Configuration using DHCP is supported on the >link,when the the mobile node sends a DHCPv6 Request message, the relay >agent function on the access router will set the link-address field in the >DHCPv6 message to the mobile node's home network prefix and that serves as >a prefix hint. Now, the specific identifier that the DHCP server allocates >depends on the client identifier option sent by the mobile. If the MAC >address of the mobile changes from link to link, the client-identifier >option in the DHCP request will allow the DHCP server to offer the same >address. So, the client identification as per 3315 is not just based
>on the MAC address, its an identifier that is used as the key.
>
>If the mobile node uses Stateless Auto Address Configuration using 3041 >based scheme, the mobile node can generate multiple addresses from its >home network prefix, using them as ephemeral addresses, vista does this. >In this mode of address configuration, the mobile is in charge of the >identifier selection and so it can always obtain the same address across >handoffs.
>
>Bottom line, the mobile can obtain the same global address across >handoffs.
>
>Regards
>Sri

Well my point is that PMIP should be capable of handling inter-technology handoff (and I think Sri meant such handoffs also), if 2) means not to hide the handover from the MN I'm OK with that. If the procedure of IP address reconfiguration leads to session interruptions is a question of analysis and an issue, but if for each inter-technology handoff MIPv6 must be used, this is a serious draw back in the possible deployment scenarios of PMIPv6 on the whole (IMHO).

Kalin

[email-masked]

Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger