Subject: Re: [netlmm] Scope of revised charter: MN impact

From: Niklas Neumann <[email-masked]>
Date: Wed, 25 Jun 2008 11:58:57 +0200

Hey Mohanna,

I do agree that at the current stage CMIP and PMIP are two independent 
orthogonal mobility management protocols. However, in my opinion the 
distinction will start to fade very quickly the more signaling support 
PMIP will ask the MN to do. If the "extended PMIP" ends up requiring a 
client to do extensive signaling every time the client changes the MAG, 
for example to indicate an inter-access handover, or to indicate some 
sort of multihoming, or to speed up the handover to achieve acceptable 
latencies, then what is the distinction anymore?

But to stress my point of view again: I do agree that some sort of 
signaling can enhance the network connectivity for a mobile node. I was 
just proposing that the NETLMM group focuses on the network-based aspect 
of network-based mobility. This way, all the client-side enhancements 
could be kept generic and not bound to PMIP. But maybe this isn't as 
feasible in practice. Anyway, if the new charter allows for client 
modifications, I still suggest to keep them as generic as possible (i.e. 
the client shouldn't rely on the network providing PMIP support).

Best regards
   Niklas

Mohana Jeyatharan wrote:
> Hi Niklas,
> 
> I read your mail. Pls see reply in-line.
> 
> BR,
> Mohana 
> 
>> -----Original Message-----
>> From: Niklas Neumann [mailto:[email-masked]] 
>> Sent: Monday, June 23, 2008 9:53 PM
>> To: Mohana Jeyatharan
>> Cc: [email-masked]
>> Subject: Re: [netlmm] Scope of revised charter: MN impact
>>
>> Hello Mohana,
>>
>> reading the discussion I largely agree with Gerardo. It boils 
>> down to the question what the difference is between PMIP + 
>> "extensions" and MIP.
>> Even if the "generic support functions" whatever they may be 
>> are only optional to optimize things, why not just use MIP 
>> (or for what its worth some MIP light) inside the PMIP domain 
>> then? 
> 
> CMIP and PMIP are two independent orthogonal mobility management
> protocols.
> Do you agree with that? In that case, if the network(say 3GPP) is
> willing to provide
> Network based mobility mangement support, why shuld the MN switch back
> to CMIP
> to achieve better hand-offs and multihoming? (Another analysis that
> needs to be performed is switching to CMIP mode better for vertical
> hand-off or operating in PMIP mode is better for vertical hand-off)
> I agree multihoming has been developed to a considerable extent in MEXT
> working group. 
> But as you know they are additional functionalities for MIP. The same
> here. If a major mobility management protocol such as PMIP is going to
> be used, then we need to derive additional functions for it in the
> netlmm working group. I don't see why this should be handled in MEXT
> working group and why one should switch to MIP
> just because one needs to use some signaling. Even as Oliver pointed out
> in his last mail,
> MN can engage in signaling for better services. But still, it need not
> engage in updating
> its location to HA. That itself is a benefit to MN which wants to
> conserve on its
> Power usage. If you say it has to switch to CMIP then it does not make
> much sense....
> 
> 
> 
>> optimized but isn't that in the scope of other WGs (e.g. 
>> MIPSHOP or MEXT)?
>>
>> I understand that there are limitations to a network-based 
>> mobility approach. But they are inherent in the "network-based" part.
>> That being said, I do believe that there is room for some 
>> generic improvements on the IP layer to support mobility 
>> (e.g. multihoming and mobility). In my opinion the question 
>> is how tight you want to bind them to PMIP instead of making 
>> them more generic.
> 
> I think it should be bound to PMIP.
> MEXT working group works on core MIP protocol and all its derivatives.
> 
> NetLMM should work on PMIP and all its derivatives. MIPSHOP is a working
> group for signaling optimizations.
> I think what I am saying and many people are saying is just not
> signaling optimizations.
> Is having better hand-off delay or less packet loss during vertical
> hand-off a signaling optimization?
> NO. We want better hand-offs for UE's that want such services. We also
> want multihoming features
> In PMIP for nodes that want such services. The main thing is that the MN
> WANTS network based mobility management. Thus all these has to be
> handled in NetLMM working group, because this may need some additional
> functionalities in LMA, MAG and so on.
> 
>>
>> Best regards
>>    Niklas
>>
>>
>>
>> Mohana Jeyatharan wrote:
>>> Hello Charlie,
>>>
>>> Please see reply in-line. Many of your points are so valid. 
>> However, I 
>>> have tried to reply to you...
>>>
>>>> -----Original Message-----
>>>> From: Charles E. Perkins [mailto:[email-masked]]
>>>> Sent: Saturday, June 21, 2008 12:54 AM
>>>> To: Mohana Jeyatharan
>>>> Cc: Giaretta, Gerardo; [email-masked]
>>>> Subject: Re: [netlmm] Scope of revised charter: MN impact
>>>>
>>>>
>>>> Hello Mohana,
>>>>
>>>> I have questions about your answers to Gerardo...
>>>>
>>>> Mohana Jeyatharan wrote:
>>>>
>>>>> [Mohana] The current charter says that MN should not be 
>> involved in 
>>>>> mobility management signaling.  It does not restrict the MN from 
>>>>> participating in some support signaling.
>>>> Do you mean that it is O.K. for a MN to support mobility 
>> management, 
>>>> but that it is not O.K. for a MN to be involved with mobility 
>>>> management?
>>>>
>>>> I think such a distinction would be almost impossible to apply or 
>>>> evaluate in practice.
>>>>
>>> [Mohana] My true feeling is mobility support signaling is basic 
>>> location update signaling. Handoff optimization , 
>> multihoming related 
>>> siganling are support signaling and they are not directly 
>> related to 
>>> mobility management signaling.
>>> First of all, why is that a node that has MIP stack choose 
>> to operate 
>>> in PMIP mode. It does not want to engage in frequent 
>> signaling. But, 
>>> if such a node says I am not going to engage in any 
>> signaling then it 
>>> cannot have better services. But, all I am saying is that 
>> to achieve 
>>> some benefits in PMIP some signaling should be performed and 
>>> definitely it should not be high. For example, the MN wants 
>> to inform 
>>> its hand-off state to MAG or some thing like that. This can 
>> be tied in 
>>> Mn-AR inetrface by some flag or something to existing 
>> messages. These 
>>> are not completely New signaling. Basically it is like 
>> optimization of 
>>> existing messages to get better services.
>>>>>   I am not sure why
>>>>> you categorize inter-tech handover optimization signaling, or 
>>>>> multihoming Related signaling in PMIP to mobility management 
>>>>> signaling.
>>>> I would certainly characterize handover signaling as related to 
>>>> mobility management.  It's almost a tautology!!
>>>>
>>>>> I think mobility Management signaling is mainly to create routing 
>>>>> state.
>>>> As opposed to... what?  Forwarding state?  Bridging state?  
>>>> Location state?  or... ??
>>>>
>>>>> Also, having some infrequent AR interaction is very different to 
>>>>> updating your location at an HA (this is mobility management 
>>>>> signaling).
>>>> How infrequent?  Does the relatively long MIPv6 maximum binding 
>>>> lifetime (3 days, I think) lead to overly frequent signaling?
>>>> Compared to, say, what?
>>>>
>>> [Mohana] What I meant is that when you use CMIP then every time you 
>>> change your network you need to update the HA. But, in PMIP 
>> you don't 
>>> need to do that. What ever optimization Signaling should 
>> not be done 
>>> often. Thus all optimization signaling may be performed Once and 
>>> perhaps transferred via context transfer or should not be 
>> as frequent 
>>> as location update signaling.
>>> Definitely I agree on this. If one is going to perform lot of 
>>> signaling in PMIP mode, then there is no point in using 
>> PMIP, in that 
>>> case it is better to switch to CMIP mode.
>>>>> [Mohana] I am not sure why you are not satisfied with the problem 
>>>>> statement.
>>>>> We are not changing the charter goal. Definitely there is no 
>>>>> modifciation to unmodified host
>>>>>   
>>>> This, I can go along with :-)
>>>>
>>>>> All what we are saying is that for hosts that want some better 
>>>>> services in PMIP should be able to perform some signaling to the 
>>>>> network to achieve this.
>>>>>   
>>>> I can also go along with this :-)
>>>>
>>>>> This is not
>>>>> Mobility management signaling and thus I don't see why it
>>>> breaks the
>>>>> charter goals.
>>>>>   
>>> [Mohana] Charlie, My understanding of mobility management signaling 
>>> was merely location updates. I categorized the rest as some 
>> signaling 
>>> to achieve other services. Better handoff.....
>>> Any way, now we are into re-chartering. The old charter is mobility 
>>> mangement for unmodified hosts. I don't see why the old 
>> charter golas 
>>> should be carried so strictly to the new charter. The new 
>> charter can 
>>> perhaps work on MN's that want better service in PMIP. 
>> Future nodes or 
>>> mobile terminals will definitely want better services.
>>>
>>> Thanks.
>>>
>>> BR,
>>> Mohana
>>>> This is the part that has me stumped.
>>>>
>>>>
>>>> Regards,
>>>> Charlie P.
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> netlmm mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/netlmm
>>
>>
>> --
>> Niklas Neumann - University of Goettingen, Institute of 
>> Informatics http://user.informatik.uni-goettingen.de/~nneuman1/
>> Tel: +49 551 39-14419
>>

-- 
Niklas Neumann - University of Goettingen, Institute of Informatics
http://user.informatik.uni-goettingen.de/~nneuman1/
Tel: +49 551 39-14419
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Wed, 25 Jun 2008 16:07:47 +0300

Hello everybody,

I would like to add some of my thinking to this discussion. First of all, I
think the main thing is that an unmodified host can get mobility support in
a backwards compatible manner with PMIP. Otherwise, this whole exercise is
mostly useless. 

So, my take on this is "depends". I am a bit afraid that we are discussing
about a principle, where we should postpone this discussion to the point
where we have something concrete on the table that would need MN changes.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 25 Jun 2008 09:31:00 -0700

Hello Jonne,

Just a bit of follow-up on your point...

> a backwards compatible manner with PMIP. Otherwise, this whole exercise is

This I agree with.

> where we have something concrete on the table that would need MN changes.

Here I am not so sure.  I think the problem is fundamental
to the IETF's specifications for mobility management.
This could mean that [netlmm] might be wrong place for
the discussion.  But on the other hand it could mean that
[netlmm] cannot possibly get it right until the larger issues
have been discussed.  I have in mind a short Internet Draft
to lay out at least one perspective on the issues.  If you
think this would be worthwhile, please let me know.

Regards,
Charlie P.