Subject: Re: [netlmm] RE: Solution proposal for accommodating multihomed IP nodesin PMIP6

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 17 Oct 2007 10:17:24 -0700 (PDT)

Hi Jonne,
  Many of us also would like to see the base draft go for WGLC. My suggestion is to reduce the solution proposal text to just a few sentences by removing all prefix assignment statements which should be done future work. Maybe saying that MN ID based BCE management which is adopted in this specification has  limitations as for MNs with multiple interfaces and may be revisited in future work.
would suffice.

  Thanks for your hard work.

Behcet
----- Original Message ----
From: Soininen Jonne (NSN - FI/Espoo) <[email-masked]>
To: "ext Tsirtsis, George" <[email-masked]>
Cc: Netlmm <[email-masked]>
Sent: Wednesday, October 17, 2007 7:03:28 AM
Subject: Re: [netlmm] RE: Solution proposal for accommodating multihomed IP nodesin PMIP6

Geoge et al.,

I understand the worry of using PMIP in a situation, which may cause 
suboptimal performance for the  MN, would be an issue. However, I don't 
see that it would currently break anything. Or at least I couldn't find 
anything in your mail that would suggest that something wouldn't work.

I think we can solve further optimization issues in future work. I would 
hope that the proposal on multihoming, which has gotten at least some 
support on the list, could be incorporated to the base draft, and we 
could move forward towards a WG LC.

Cheers,

Jonne.
ext Tsirtsis, George wrote:
> inline
>
> -----Original Message-----
> From: Basavaraj Patil [mailto:[email-masked]] 
> Sent: Tuesday, October 16, 2007 6:57 PM
> To: Tsirtsis, George; Ahmad Muhanna; Narayanan, Vidya; Netlmm
> Subject: Re: [netlmm] RE: Solution proposal for accommodating multihomed
> IP nodesin PMIP6
>
>
> Hi George,
>
> Just as an FYI, I do believe that it makes sense to let the MN know if
> the
> AR that it is attaching to is a MAG (PMIP6 capable) via the RA. By doing
> so
> a MIP6 capable MN can choose to request a prefix which is local to the
> AR
> and use that as the CoA in a BU.
> Please refer to I-D: draft-damic-netlmm-pmip6-ind-discover-01.txt
>
> GT> Good, I agree that MAG capabilities need to be advertised to end
> nodes, but why would the MIP6 capable MN need to request the obvious?
> MIPv6 has no need for the MAG functionally and the default behavior of
> an AR is to provide a local prefix. If MAG is viewed as a "service" then
> MAG services must be requested by entities that need it. Expecting
> entities that do not need MAG services to indicate that fact is
> backwards logic, and backwards incompatible. 
>
> The issue that you are raising is orthogonal to the original problem of
> dealing with multihomed hosts. There is no assumption that PMIP6 is
> always
> used or available in every MAG/AR to support mobility. The default
> fallback
> to support mobility for a host is Mobile IP. Network based mobility
> would
> only be applicable in networks that have MAG functionality in the AR and
> are
> associated with an LMA which may also be the HA for the MN.
>
> GT> Yes, I understand that the base specification defines what happens
> when PMIPv6 IS used, without saying WHEN it is used. I think this is
> dangerous since it makes protocol misuse very easy, but I understand
> that this is how the work has been split. 
>
>
> -Raj
>
>
> On 10/16/07 10:28 AM, "ext Tsirtsis, George" <[email-masked]>
> wrote:
>
>   
>> Hi Ahmad,
>>
>> I believe the application of PMIPv6 as intra-technology and
>> inter-technology mobility management mechanisms presents different
>> challenges.
>>
>> In the intra-technology case, it is common that a single mobility
>> management mechanism is defined on a per technology basis. The only
>> potential issue in this case is multi-homing using the same technology
>> interface in the same PMIP domain.
>>
>> In the inter-technology case, the only available mobility management
>> mechanism that has been available for long time is Mobile IP. With the
>> introduction of PMIPv6, there is an issue of how mobiles and networks
>> figure out what is going to be used and when.
>>
>> The issue I am raising with the latest solution is that it assumes
>>     
> that
>   
>> PMIP is always used to interconnect a MAG to the LMA, and then some
>> logic defines whether the HNP is assigned to the MN again or not. This
>> is clearly not ideal if the MN supports Mobile IP, in which case the
>> address assigned should come from the MAG rather than the LMA.
>>
>> To solve this problem, for example, the logic described by Vidya
>> earlier, when no specific knowledge exists at the MAG WRT to PMIP
>> support in the MN, should "default" to not running PMIP at all, but
>> instead the MAG should allocate a new local prefix to the MN.
>>
>> Regards
>> George
>>
>> -----Original Message-----
>> From: Ahmad Muhanna [mailto:[email-masked]]
>> Sent: Tuesday, October 16, 2007 3:47 PM
>> To: Tsirtsis, George; Narayanan, Vidya; Netlmm
>> Subject: RE: [netlmm] RE: Solution proposal for accommodating
>>     
> multihomed
>   
>> IP nodesin PMIP6
>>
>>     
>>> Putting that aside, however, this behavior is entirely
>>> unacceptable to MNs that handle inter-technology mobility
>>> with MIPv6! What such a mobile needs is that each AR it
>>> connects to (whether a PMIP MAG or not), assigns it a new
>>> local IP address, so that the MN can handle mobility by
>>> itself. Unless I am missing something, the proposed solution
>>> is not compatible with an "unmodified MIPv6 host", since the
>>> solution is designed to default to using PMIPv6.
>>>
>>> Thoughts?
>>>       
>> Hi George,
>>
>> How is this different from how PMIPv6 handles the MN initial attach
>>     
> and
>   
>> inter-MAG handoff within the same technology?
>>
>> If we accepted how PMIPv6 solution handles the MIPv6 MN in the initial
>> attach and inter-MAG handoff, then I do not see any issue for the same
>> concept to work for inter-technology handoff. However, if we have a
>> problem accepting the original argument, then that is a different
>>     
> story.
>   
>>> George
>>>
>>>
>>> -----Original Message-----
>>> From: Narayanan, Vidya [mailto:[email-masked]]
>>> Sent: Monday, October 15, 2007 10:17 PM
>>> To: Netlmm
>>> Subject: [netlmm] RE: Solution proposal for accommodating
>>> multihomed IP nodesin PMIP6
>>>
>>> Correcting one typo below.
>>>
>>>       
>>>> -----Original Message-----
>>>> From: Narayanan, Vidya
>>>> Sent: Monday, October 15, 2007 2:12 PM
>>>> To: Netlmm
>>>> Subject: Solution proposal for accommodating multihomed IP nodes in
>>>> PMIP6
>>>>
>>>>
>>>> All,
>>>> Jonne, Jari and myself had a call with some of the key
>>>>         
>>> people involved 
>>>       
>>>> in the two solution proposals to see if common ground can
>>>>         
>>> be achieved.  
>>>       
>>>> After discussion, we have settled on a solution that all
>>>>         
>>> the people on 
>>>       
>>>> the call could agree upon.
>>>> The following write-up captures that discussion.  Please review and
>>>> comment on it.
>>>>
>>>> If there is consensus, we will move forward with
>>>>         
>>> documenting this in
>>>       
>>>> the base spec.  Please note that this write-up only captures the
>>>> concept in reasonable detail for discussion purposes and
>>>>         
>>> the authors 
>>>       
>>>> will work on the exact wording and details to be captured in the
>>>> document once there is agreement.
>>>>
>>>> Thanks,
>>>> Vidya
>>>>
>>>> -------------------------------------------------------
>>>>
>>>> The goal is to limit the assignment of a given prefix to
>>>>         
>>> one interface 
>>>       
>>>> of an MN at a time.  In other words, when multiple interfaces are
>>>> simultaneously in use on an MN, different prefixes should
>>>>         
>>> be assigned 
>>>       
>>>> to each of those interfaces.
>>>> However, in a handoff situation, the same prefix may be
>>>>         
>>> assigned to a 
>>>       
>>>> different interface (with the understanding that the other
>>>>         
>>> interface 
>>>       
>>>> is either shut down or not using this prefix).
>>>>
>>>> - The MAG carries the following pieces of information in the PBU to
>>>> the LMA - the MN ID, the access technology type, an
>>>>         
>>> interface ID and a
>>>       
>>>> Handoff Indicator (HI) field.
>>>> - The MN ID may be the NAI or anything else that
>>>>         
>>> identifies the MN
>>>       
>>>> uniquely in the PMIP domain (as currently specified in the
>>>>         
>>> document).  
>>>       
>>>> This is a mandatory field.
>>>> - The access technology type indicates the access
>>>>         
>>> technology using
>>>       
>>>> which the MN connects to the MAG (e.g., Ethernet, WLAN, IPsec, PPP,
>>>> LTE, etc.).  This is a mandatory field.
>>>> - The interface ID uniquely identifies the interface of
>>>>         
>>> the MN and is 
>>>       
>>>> typically an L2 identifier (e.g., MAC address, Link ID,
>>>>         
>>> etc.).  When 
>>>       
>>>> no interface ID is available for a given access technology,
>>>>         
>>> this field 
>>>       
>>>> is set to 0 (or omitted, if defined as an option).  When an
>>>>         
>>> interface 
>>>       
>>>> ID is available, it MUST be present in the PBU.
>>>>
>>>> - The Handoff Indicator (HI) field** in the PBU indicates
>>>>         
>>> if the PBU 
>>>       
>>>> is meant for an interface that is a handoff from a
>>>>         
>>> different interface
>>>       
>>>> corresponding to an existing BCE
>>>> - When the new MAG is aware of the handover, it sets
>>>>         
>>> this field to 
>>>       
>>>> indicate a "handoff"; when the new MAG knows that this PBU is
>>>> unrelated to other interfaces of the MN, it sets it to "no
>>>>         
>>> handoff" or 
>>>       
>>>> "distinct interface"; when the new MAG has no information,
>>>>         
>>> it sets it 
>>>       
>>>> to "no information"
>>>> - When this field is set to "no information" and the
>>>>         
>>> situation is 
>>>       
>>>> actually a handoff case, the old MAG should send a
>>>>         
>>> deregistration PBU
>>>       
>>>> with this field set to "handoff" for the LMA to accept the PBU from
>>>> the new MAG with the same HNP assignment; if not, a new HNP must be
>>>> assigned for that PBU
>>>>
>>>> - The LMA, upon receiving a PBU, does the following:
>>>>
>>>> Case 1: Interface ID is present in the PBU:
>>>>
>>>> - If the interface ID contained in the PBU matches the
>>>>         
>>> interface ID 
>>>       
>>>> stored for a given BCE (for a given MN ID), it MUST update that BCE
>>>> with the new PBU and keep the HNP associated with that BCE
>>>> - If the interface ID is different from an existing BCE
>>>>         
>>> for a given 
>>>       
>>>> MN ID and the HI field is set to "no handoff", it MUST assign a new
>>>> HNP for the interface and create a new BCE for the HNP
>>>> - If the interface ID is different from an existing BCE
>>>>         
>>> for a given 
>>>       
>>>> MN ID and the HI field is set to "no information", the LMA
>>>>         
>>> SHOULD wait 
>>>       
>>>> for a deregistration message for an existing BCE before
>>>>         
>>> accepting the 
>>>       
>>>> new PBU with the same HNP; if no deregistration is received
>>>>         
>>> within a 
>>>       
>>>> given time, the LMA SHOULD assign a new prefix for the
>>>>         
>>> received PBU.  
>>>       
>>>> The LMA MAY assign a new HNP and accept the PBU without
>>>>         
>>> waiting for a 
>>>       
>>>> deregistration message.
>>>> - If the interface ID is different from an existing BCE
>>>>         
>>> for a given 
>>>       
>>>> MN ID and the HI field is set to "handoff", the LMA MUST assign the
>>>> same HNP associated with the BCE corresponding to the old interface
>>>> and update the BCE
>>>>
>>>> Case 2: No interface ID is present in the PBU:
>>>>
>>>> - If there is no corresponding BCE for that MN ID with a NULL
>>>> interface ID value, the LMA MUST assign a new HNP
>>>>         
>>> corresponding to the
>>>       
>>>> incoming PBU
>>>> - If there is a BCE with NULL interface ID value for
>>>>         
>>> that MN ID and 
>>>       
>>>> the HI field is set to "handoff", the LMA MUST assign the same HNP
>>>> associated with the BCE corresponding to the old interface
>>>>         
>>> and update 
>>>       
>>>> the BCE
>>>> - If there is a BCE with NULL interface ID value for
>>>>         
>>> that MN ID and 
>>>       
>>>> the HI field is set to "no handoff", the LMA MUST assign a new HNP
>>>> corresponding to the incoming PBU
>>>> - If there is a BCE with NULL interface ID value for
>>>>         
>>> that MN ID and 
>>>       
>>>> the HI field is set to "no information", the LMA SHOULD wait for a
>>>> deregistration message for an existing BCE before accepting the new
>>>> PBU with the same HNP; if no deregistration is received
>>>>         
>>> within a given 
>>>       
>>>> time, the LMA SHOULD assign a new prefix for the received PBU.  The
>>>> LMA MAY assign a new HNP and accept the PBU without waiting for a
>>>> deregistration message.
>>>>
>>>> How the LMA is notified about a handoff situation for address
>>>> continuity is out of scope of the specification.  This may
>>>>         
>>> be based on 
>>>       
>>>> L2 triggers or other means that may be defined by the
>>>>         
>>> appropriate SDO 
>>>       
>>>> or deployment.  With such information,
>>>>         
>>> s/With/Without
>>>
>>>       
>>>> the LMA must treat it an interface as a "distinct" one,
>>>>         
>>> unless there 
>>>       
>>>> is an exact match of parameters with an existing BCE.
>>>>
>>>> One other point to note here is that a given PMIP session
>>>>         
>>> is now tied 
>>>       
>>>> to the tuple {MN-ID, Interface ID, Access technology type} and not
>>>> just to the MN-ID; there may be only one HNP associated with any
>>>> unique value of the tuple, but, multiple HNPs (and hence, BCEs)
>>>> corresponding to the same MN-ID itself.
>>>>
>>>>         
>>> _______________________________________________
>>> 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
>   

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

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