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

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 17 Jun 2008 14:52:57 -0700 (PDT)

Hi Raj,
  Pls. see inline.

Regards,

Behcet

----- Original Message ----
From: Basavaraj Patil <[email-masked]>
To: Charles Perkins <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, June 17, 2008 3:25:49 PM
Subject: Re: [netlmm] Scope of revised charter: MN impact

Hi Charlie,

I don't believe there really is an issue as to what type of devices are
capable or not of running IETF mobility protocols. It has more to do with
whether the mobility protocols are implemented on hosts, performance (or
perceived performance :) ), overhead on air interfaces etc. These factors
and others lead to deployment choices of either host based mobility or
network based mobility.
Network based mobility does add value since it can provide mobility to
unmodified hosts (which has been the basis of the work). However what we did
realize is that in order to support multihoming, intertech HO etc. some
interaction with the MN would be useful. 

[behcet] This was already pointed out way back in May 2006 in draft-soliman-netlmm-harmful
Your realization is nothing new, unfortunately.

And that is what I am suggesting
that the charter allow. As an example, it would be useful if the MN can
indicate when it moves between MAGs that the new MAG should set the HO Flag
which will enable the LMA to assign the same address/prefix and there is no
ambiguity about whether the MN is attaching via a new interface. Such
information can also be obtained within the network itself by context
transfer or other means. However having the MN indicate it would be the most
optimal.

I don't think there really is an issue of what can and cannot be implemented
on a wireless device; At least not in the scope of the Netlmm charter.

-Raj

On 6/17/08 3:12 PM, "Charles Perkins" <[email-masked]> wrote:

> 
> Hello Raj,
> 
> I'm curious about this.  I thought the entire point of [netlmm] was that
> some (or, quite a few) devices could not be expected to run IETF
> mobility protocols (e.g., Mobile IPv6) because they could not be
> modified.  If they can be modified, then the point of [netlmm] goes
> way, doesn't it?  I realize this is a somewhat simplistic view of the
> situation, but it would be nice to find out exactly why the devices
> can't run the expected IETF protocols.  Otherwise, we might design
> a solution requiring changes that, oops, still "could not" be implemented
> for the wireless devices.
> 
> Regards,
> Charlie P.
> 
> 
> 
> Basavaraj Patil wrote:
>> Hello,
>> 
>> The Netlmm charter (current) has expressly prohibited changes to the MN in
>> the context of mobility management. This limitation should be removed from
>> the revised charter. In order to enable inter-technology handovers or to
>> support mutihoming capability or other enhancements now being suggested, it
>> would be useful in the design process to have the ability to make
>> enhancements to the MN as well.
>> 
>> I hope the chairs will consider making the change in the revised charter.
>> 
>> -Raj
>> 
>> _______________________________________________
>> netlmm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netlmm
>> 
>> 
>>  
> 

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

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Thu, 19 Jun 2008 10:01:12 -0400

Hi Domagoj,

I don't dispute the foreseen benefits of having things at the IP layer.
Nor am I proposing to "violate layers" :-)
(Rich interaction between layers is interesting, albeit not necessarily
a standards topic here)
 
Whether we like it or not, some functionality is implemented at lower
layers based on the need. (MN attaching to a network after a handover is
one example.) This includes overriding whatever has been proposed at the
IP layer. That's my point.

Regards,

-Rajeev

> -----Original Message-----
> From: Premec, Domagoj [mailto:[email-masked]]
> Sent: Thursday, June 19, 2008 5:30 AM
> To: Koodli, Rajeev; Basavaraj Patil; Sri Gundavelli; Charles Perkins
> Cc: [email-masked]
> Subject: RE: [netlmm] Scope of revised charter: MN impact
> 
> Rajeev,
> 
> > Whether providing such functionality at the IP layer will
> > actually be used. I am not questioning the usefulness, but
> > whether it will be over-ridden by the functionality, if
> > needed, at the lower layers.
> 
> The way I see it is that PMIP6 is a network feature at the IP layer
and
> hence the capability to detect PMIP6 service should also be part of
the IP
> layer. Having this information as part of the lower layer doesn't look
> like a clean layer separation. Another consideration is that lower
layer
> approach means upgrading the existing L2 equipement in the network if
the
> network chooses to make use of this functionality. By having it at the
IP
> layer only the MAG is affected, which is a new node anyway. Modifying
L2
> also means that different SDOs will be repeating basically the same
> change.
> 
> domagoj
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Koodli, Rajeev
> > Sent: 19. lipanj 2008 00:14
> > To: Basavaraj Patil; Sri Gundavelli; Charles Perkins
> > Cc: [email-masked]
> > I too can imagine scenarios where you could get benefits.
> > However, I am not clear about the following:
> >
> > Whether providing such functionality at the IP layer will
> > actually be used. I am not questioning the usefulness, but
> > whether it will be over-ridden by the functionality, if
> > needed, at the lower layers.
> >
> > >As an example the ability of the host to parse an RA and understand
a
> > PMIP6
> > > prefix vs a Local one. This is a small enhancement to the MNs IPv6
> > stack.
> >
> > [RKo:>] I am curious why NETLMM would be a good place for
> > this scenario.. We _could_ consider such issues, perhaps in a
> > separate WG, IMO. In fact, we could consider
> > "network-mobility optimizations" as a whole for such a WG.
> >
> > Regards,
> >
> > -Rajeev
> >
> >
> >
> >
> > >But it
> > > does enable the host to realize the access routers
> > capability as well
> > as
> > > in
> > > making a choice of mobility mode.
> > >
> > > So I believe that the Netlmm charter should change its perception
of
> > not
> > > making any changes to the host as being sacred. Because
> > some minimal
> > > changes are useful to the protcols efficient operation.
> > >
> > > -Basavaraj
> > >
> > >
> > > On 6/17/08 5:27 PM, "Sri Gundavelli" <[email-masked]> wrote:
> > >
> > > > Hi Charlie,
> > > >
> > > > The broad goal is not to involve the client in mobility
> > management
> > > > signaling. The examples cited here all confirm to this goal.
> > > > Providing certain hints, to the client either in the form
> > of RA's or
> > > > through other mechanisms only to improve either the
> > clients ability
> > > > to make a better decision or for the network to understand the
> > > > clients intent, are just optimizations. This cannot be a
> > difficult
> > > > or a controversial decision. We all can differentiate
> > between a an
> > > > optimization vs what is a client equivalent functional
> > addition to
> > > > the host.
> > > >
> > > >>
> > > >> I was going to ask how many blind rules we should have,
> > but then I
> > > >> thought maybe some people would not find it to be very funny.
> > > >> Nevertheless, I'd like to find out how
> > > >
> > > > :)
> > > >
> > > >> an impartial observer could distinguish between a blind rule
and
> > > >> charter mandate.
> > > >
> > > > This is clearly the job of the chairs and the AD. They
> > will ensure
> > > > new proposals meet this criteria.
> > > >
> > > >
> > > > Regards
> > > > Sri
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, 17 Jun 2008, Charles E. Perkins wrote:
> > > >
> > > >>
> > > >> Hello Sri,
> > > >>
> > > >> It seems to me that you have certain strong ways of classifying
> > > >> which changes are legitimate, based on whether they affect the
> > > >> client's "stack".  Can you be a bit more specific about
> > this?  How
> > > >> can I tell whether something affects the "stack"?  Will all
such
> > > >> client signals be handled over some UDP, TCP, or SCTP port?
> > > >>
> > > >> Regarding:
> > > >>
> > > >>>        .......      W.G should see the host stack changes
> > objectively
> > > >>>  and not go with one blind rule.
> > > >>
> > > >> I was going to ask how many blind rules we should have,
> > but then I
> > > >> thought maybe some people would not find it to be very funny.
> > > >> Nevertheless, I'd like to find out how an impartial
> > observer could
> > > >> distinguish between a blind rule and charter mandate.
> > > >>
> > > >> Regards,
> > > >> Charlie P.
> > > >>
> > > >>
> > > >>
> > > >> Sri Gundavelli wrote:
> > > >>>  Hi Charlie,
> > > >>>
> > > >>>  The basic assumption of the NETLMM, the non-involvment of the
> > client
> > > >>>  in mobility signaling should always hold true. That
requirement
> > > should
> > > >>>  not be relaxed. The protocol that is on the table today is
> > designed
> > > >>>  with that goal. All aspects of the protocol will
> > function with
> > > >>> absolutely zero changes to the host stack. This
> > includes even the
> > > >>> inter-technology handoff. There is some confusion that the
> > > requirement
> > > >>>  of virtual interface support on the host implies changes to
the
> > host
> > > >>>  stack. That is absolutely not true, Ryuji and me will
> > demonstrate
> > > this
> > > >>>  soon.
> > > >>>
> > > >>>  Now, w.r.t to the comment from Raj that we need allow
> > changes to
> > > host.
> > > >>>  These changes are minor optimizations. Examples of such
> > optimizations
> > > >>>  include:
> > > >>>
> > > >>>  - The ability for the host and the access router to perform
> > > capability
> > > >>>    exchange
> > > >>>  - Prefix colouring, the ability for the host to distinguish
> > between
> > > >>>    a prefix that has mobility properties to a local prefix
> > > >>>  - Some minor SEND related extensions
> > > >>>  - Optimizations w.r.t DNA, for improving the handoff latency
> > > >>>
> > > >>>  None of this can be equated to a client stack
> > requirement. These
> > fall
> > > >>>  in the scope of the general IPv6 host stack improvements and
in
> > the
> > > >>>  context of NETLMM. W.G should see the host stack changes
> > objectively
> > > >>>  and not go with one blind rule.
> > > >>>
> > > >>>  Regards
> > > >>>  Sri
> > > >>>
> > > >>

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Fri, 20 Jun 2008 08:55:57 +0800

Hi Gerardo,

Some thoughts regarding your division as to whether it should be PMIP or
CMIP.

Changing MN to be aware of PMIP and making some small MN involvement in
the air
interface to enable better inter access technology handovers,
multihoming, route optimization and so on, does not really mean we are
re-inviting MIP.

 As to the debate into PMIP vs CMIP, this debate has been done years
ago, let's not restart it.  The consensus has always been CMIP and PMIP
are solving different problems, they are orthogonal and can be deployed
one besides the other (already 3GPP is doing that as you have pointed
out in one of your mails).  It has never been one or the other. Classic
case is HMIP and CMIP. HMIP/PMIP is mainly a local mobility management
mechansim. If you roam to foreign domain then it definitely needs both
operations (this you have highlighted in PMIP/CMIP interaction draft
scenario A). Unless one is talking about the 3GPP home routed case where
one see the home prefix all along(purely PMIP).

The current PMIP charter is that MN should not be involved in mobility
management signaling. For nodes that are legacy(IPv6) it works fine and
it can achieve mobility management without implementing MIP stack. For
nodes that have MIP then it eliminates the burden of constant mobility
management signaling. But, however "MN is not performing mobility
management" is different from "MN is not involved in mobility management
or Mn performing some minor optimizations". As long as MN is not
performing BU etc, and is not maintaining any state relevant to its
mobility, it can be said as MN is not performing mobility management.

What we are saying (same as many others in the mailing list), changing
MN to perform some support signaling in PMIP is not exactly reinviting
MIP. MIP is only a mobility management protocol. There needs to be some
mechansims to solve issues when MN is operating in the PMIP mode or the
3GPP has decided to only provide PMIp services. Ofcourse, such signaling
should not be high and it will not be high bcos, mobility managemnt
injects higher signaling load into the network when compared to some
minor non-frequent MN support signaling.

If you say that to achieve better interaccess technolgy hand-off,
multihoming, route optimization and so on one needs to completely switch
to MIP, then I would like to point out that (1) we may loose the nice
features of local mobility management as in PMIP(also HMIP) (2) you may
not be able to switch to CMIP as you please. IN TS 23.402 in section 4,
there is a static configuration of mobility management protocol that can
be used for a certain access type. In that case, if you have to use
PMIP, then how is an advanced UE that wants to have seamless handoff
optimization, advanced multihoming ....achieve all this. Definitely it
needs to operate in PMIP mode and perform some mechanisms to enable
this. Such mechanisms will not be like Mn perfoming mobility management
signaling(ie. Location updates).

This is how we feel. 

BR,
Mohana

> [mailto:[email-masked]] On Behalf Of Giaretta, Gerardo
> Sent: Thursday, June 19, 2008 6:12 PM
> To: Sri Gundavelli; Charles E. Perkins
> Cc: [email-masked]
> Hi Sri, Charlie, all,
> As Sri correctly stated, "The basic assumption of the NETLMM, 
> the non-involvement of the client in mobility signaling 
> should always hold true."
> 
> Then I am a bit confused by the classification made by Sri. 
> As soon as we extend SEND or ND or any other MN-MAG protocol 
> for multihoming or inter-tech HO support with NETLMM, we are 
> making the MN aware of the mobility and the mobility 
> protocol. Those changes would be introduced only because of 
> mobility and therefore must be seen as an involvement of the 
> client in the mobility management signaling. I see a lot of 
> contradictions in your classification and analysis below. 
> 
> I think the correct way of seeing the point is the following: 
> IETF has defined two mobility management protocols, one 
> involving directly the host and requiring support from the 
> host (MIP), and another for hosts who do not support any 
> mobility management signaling (NETLMM). The question from Raj 
> boils down to the following: should we extend NETLMM so that 
> the host is involved in mobility management and support 
> mobility management signaling?
> 
> If this is the case, wouldn't it mean we are re-inventing 
> MIP? If yes, what is wrong with the current version of MIP? 
> Which is the problem statement to change it or the 
> requirements not fulfilled by it?
> 
> Cheers
> Gerardo
> 
> 
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of Sri Gundavelli
> > Sent: Tuesday, June 17, 2008 3:27 PM
> > To: Charles E. Perkins
> > Cc: [email-masked]
> > The broad goal is not to involve the client in mobility management 
> > signaling. The examples cited here all confirm to this 
> goal. Providing 
> > certain hints, to the client either in the form of RA's or through 
> > other mechanisms only to improve either the clients ability 
> to make a 
> > better decision or for the network to understand the 
> clients intent, 
> > are just optimizations. This cannot be a difficult or a 
> controversial 
> > decision. We all can differentiate between a an 
> optimization vs what 
> > is a client equivalent functional addition to the host.
> > 
> > >
> > > an impartial observer could distinguish between a blind rule and 
> > > charter mandate.
> > 
> > This is clearly the job of the chairs and the AD. They will 
> ensure new 
> > proposals meet this criteria.
> > 
> > 
> > Regards
> > Sri
> > 
> > 
> > 
> > 
> > > can I tell whether something affects the "stack"?  Will all such 
> > >>  in mobility signaling should always hold true. That requirement
> should
> > >>  with that goal. All aspects of the protocol will function with  
> > >> absolutely zero changes to the host stack. This includes 
> even the  
> > >>  of virtual interface support on the host implies changes to the
> host
> > >>  Now, w.r.t to the comment from Raj that we need allow changes to
> host.
> > >>  None of this can be equated to a client stack requirement. These
> fall
> > >>  in the scope of the general IPv6 host stack improvements and in
> the

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 20 Jun 2008 01:58:45 -0700

Hi Mohana,

Thanks for the detailed explanation, but I am still missing something.

> From: Mohana Jeyatharan [mailto:[email-masked]]
> Sent: Thursday, June 19, 2008 5:56 PM
> To: Giaretta, Gerardo; Sri Gundavelli; Charles E. Perkins
> Cc: [email-masked]

But this does not make sense. If the MN includes information for
mobility related events (inter-tech handover, multihoming after
movements), it is involved in the mobility management procedures. It
does not make any difference if it is a AR extension or a BU. So,
probably you are not re-inventing MIP, just adding the FA capability in
MIPv6? 
As Charlie mentioned, if the BU is sent to the AR/FA as in MIPv4 than
you achieve what you want :-)

Basically, I am still missing the problem statement. I think you should
come up with one clear problem statement and an analysis of which
requirements the current IETF protocols do not solve. There was a
problem statement for PMIP: mobility for unmodified host. Please clarify
the issues you want to solve. Saying we want PMIP to better work with
inter tech HO with MN modifications is not a valid PS, imo.

Gerardo

requirement
the
in

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Tue, 24 Jun 2008 08:53:07 +0800

Hi Niklas,

I read your mail. Pls see reply in-line.

BR,
Mohana 

> From: Niklas Neumann [mailto:[email-masked]] 
> Sent: Monday, June 23, 2008 9:53 PM
> To: Mohana Jeyatharan
> Cc: [email-masked]
> 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...
> > 
> >> From: Charles E. Perkins [mailto:[email-masked]]
> >> Sent: Saturday, June 21, 2008 12:54 AM
> >> To: Mohana Jeyatharan
> >> Cc: Giaretta, Gerardo; [email-masked]
> >> 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.
> >>
> >>
> >>
> --
> Niklas Neumann - University of Goettingen, Institute of 
> Informatics http://user.informatik.uni-goettingen.de/~nneuman1/
> Tel: +49 551 39-14419
>