[Netext] Keep missing the point .. Re: next steps for netext

Hi Mohana,

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp]
> On Behalf Of Mohana Jeyatharan
> Sent: Wednesday, April 08, 2009 12:36 AM
> To: Hesham Soliman; Koodli, Rajeev; netext at mail.mobileip.jp
> Subject: Re: [Netext] Keep missing the point .. Re: next steps for netext
> 
> Hi,
> 
> What I meant is a legacy MN attaching via multiple interfaces, then the
> default mechansim is GTP/PMIP via LTE and PMIP via non-3GP. Reference TS
> 23.401, TS 23.402. This is why I mentioned must for such MNs.
> 

Uhm, this sounds at least weird to me. How can a legacy MN supports LTE? 

Based on TS 23.402, the support of PMIPv6 for inter-technology handovers and the support of DSMIPv6 are both optional in the MN/UE.

If the MN/UE does not support either PMIPv6 for inter-technology handovers or DSMIPv6, then PMIPv6 is used for basic connectivity but no IP address preservation is provided.

Gerardo

PS: Yes, 3GPP recognized about two years ago that a MN needs to support something new to support inter-system handovers with PMIPv6

> If MN has CMIP, then the 3GPP spec TS 23.402 says the MN can possibly
> negotiate a preferred mobility management mode or in some static configuration
> the network may decide on the mobility mode. In this case, ok, CMIP can be
> used if the operator allows it.
> 
> 
> So I was just focusing on the first part.
> 
> BR,
> Mohana
> 
> > -----Original Message-----
> > From: Hesham Soliman [mailto:hesham at elevatemobile.com]
> > Sent: Wednesday, April 08, 2009 2:06 PM
> > To: Mohana Jeyatharan; Koodli, Rajeev; netext at mail.mobileip.jp
> > Subject: Re: [Netext] Keep missing the point .. Re: next steps for netext
> >
> >
> >
> >
> > On 8/04/09 4:41 PM, "Mohana Jeyatharan"
> > <Mohana.Jeyatharan at sg.panasonic.com>
> > wrote:
> >
> > > Hi Rajeev and All,
> > >
> > > I like the summary you have put forward here. As you have mentioned and
> > many
> > > others in the ML, this discussion is not about MIP6 , PMIPv6 comparison.
> > > Currently we have a scenario where the MN MUST use PMIPv6 for mobility
> > > management for its multiple interfaces. I do not want to quote SDO, but
> > > 3GPP has a valid scenario where PMIP via LTE and PMIP via s2a(WiMAX) or
> > > s2b(WLAN) interface.
> >
> > => If you're going to say "MUST" then yes you must quote that requirement.
> > If it came from an SDO then please send us a reference to that. Other 3GPP
> > people don't agree with you and stated that publicly on the list.
> >
> > Hesham
> >
> > Then if this MN wants multihoming, flow mobility etc, how
> > > can we do this? Are we going to run MIP6 ony for multihoimg purpose, on
> > top of
> > > PMIP being used in corenetwork. Is this a good idea or are we going to
> > do
> > > major multihoming work in MAG-LMA path and do some minor modifications
> > to MN
> > > to keep it light weight as far as protocol modification is concerned.
> > The
> > > second option seems more logical for pure PMIpv6 scenario. Reason is:
> > operator
> > > may not allov two mobility manamgement protocols running just to achieve
> > > multihoming and what if the MN does not have MIP6 stack implemented.
> > >
> > > For scenarios where MIP6 is used to handle mobility for all interfaces,
> > then
> > > client based multihoming given as extensions of MIP6 is excellent. No
> > one can
> > > deny this. For mixed scenarios such as PMIP and CMIP scenarios involving
> > > multiple inetrafces, then again probably MIP6 based multihoming may be
> > ideal.
> > > This is something we need to explore as well.
> > >
> > > But our discussion currently at Netext is, operator decides PMIPv6 for
> > all
> > > interfaces and what solution do we have for multihoming and flow
> > mobility? I
> > > think we should think along these lines. Is this PMIPv6 multihoming
> > solution
> > > identical to MIP6 Multihoming solution. I don't think so. So we need to
> > look
> > > at some drafts available that handles PMIPv6 multihoming and flow
> > mobility and
> > > see the changes in UE and some functional modules introduced in
> > architectural
> > > entities, to understand the differences. If same then no need of any new
> > work.
> > > If different then need to look at benefits. Can we reduce signaling in
> > MN-AR
> > > interface, can we make the protocol chnages of a leagcy MN minimal, can
> > we
> > > reduce core network signaling. All such criteria need to be taken into
> > account
> > > for comparision.
> > >
> > > Well if the operator does not mind CMIP running over PMIP fine and good.
> > > But, what if not....
> > >
> > > Thanks.
> > > BR,
> > > Mohana
> > >
> > >> -----Original Message-----
> > >> From: netext-bounces at mail.mobileip.jp [mailto:netext-
> > >> bounces at mail.mobileip.jp] On Behalf Of Koodli, Rajeev
> > >> Sent: Wednesday, April 08, 2009 7:46 AM
> > >> To: netext at mail.mobileip.jp
> > >> Subject: Re: [Netext] Keep missing the point .. Re: next steps for
> > netext
> > >>
> > >>
> > >>
> > >> Folks,
> > >>
> > >> Let's step back a bit..It doesn't help to pit one protocol against
> > another
> > >> like this, especially when they are both developed by us :-)
> > >>
> > >> If the problem is well-understood - i.e., how to selectively move flows
> > >> across interfaces for MIP, the same problem is being investigated here
> > for
> > >> PMIP6. Why? With multiple interfaces, there seems to be interest in
> > this
> > >> (so-called flow mobility). How will this work? We don't know yet, we
> > don't
> > >> have a standards spec, but there are a few drafts. We are only setting
> > the
> > >> stage for solution(s).
> > >>
> > >> Given this, we should try to focus on investigating the problem and
> > >> agreeing on how to go about working on a protocol specification. People
> > >> already know they could use MIP6 for this. We could re-state it surely,
> > >> but that cannot be the only approach.
> > >>
> > >> Thanks,
> > >>
> > >> -Rajeev
> > >>
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: netext-bounces at mail.mobileip.jp
> > >>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Hesham Soliman
> > >>> Sent: Tuesday, April 07, 2009 3:27 PM
> > >>> To: Vijay Devarapalli
> > >>> Cc: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
> > >>> Subject: Re: [Netext] Keep missing the point .. Re: next
> > >>> steps for netext
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On 8/04/09 10:12 AM, "Vijay Devarapalli" <vijay at wichorus.com> wrote:
> > >>>
> > >>>> Hesham Soliman wrote:
> > >>>>> I don't know which people you're talking about or on which planet
> > >>>>> this stuff is being deployed.
> > >>>>
> > >>>> Thats easy. Search for "LTE HRPD" at google.com. :)
> > >>>>
> > >>>>> In any case, I'm interested in discussing technical
> > >>> aspects of this
> > >>>>> work and I have zero interest in politics and projections.
> > >>>>
> > >>>> But I don't see that. You seem to want to tell people to use Mobile
> > >>>> IPv6 instead of PMIPv6. That doesn't help anyone, IMHO.
> > >>>
> > >>> => I'm not *telling* people to do it, I'm arguing that this
> > >>> is the best approach. All I'm getting back is "SDOx want
> > >>> this" and "people want this"
> > >>> and "the ship has sailed". It's very frustrating to have a
> > >>> discussion like this instead of showing a real PS.
> > >>>
> > >>>>
> > >>>> FWIW, the way I see it, the flow mobility solution for
> > >>> PMIPv6 does not
> > >>>> have to be that different from what we have for MIPv6.
> > >>> Instead of the
> > >>>> mobile node sending the service selection option (defined
> > >>> in RFC 5149)
> > >>>> and flow identification option in the BU, it?s the MAG that
> > >>> sends this
> > >>>> information in the PBU. The solution is the same. You tell
> > >>> the HA or
> > >>>> the LMA which flow filters to install.
> > >>>>
> > >>>> The solution could be along the lines I wrote in section 3.3 of
> > >>>> draft-devarapalli-netlmm-multihoming-01.txt (submitted in
> > >>> Nov 2007).
> > >>>> It says
> > >>>
> > >>> => If there is a solution to be had I don't care whether it
> > >>> uses our draft or something new. My point is that making
> > >>> those decisions in the network just doesn't work. Yes there
> > >>> bits on the wire that can do anything but the decision to
> > >>> trigger these actions in the network is flawed. And without
> > >>> getting into too much detail, before we decide to go one way
> > >>> or another, I think a technical argument needs to be made
> > >>> about "why" it's needed and not "how" it might work. This
> > >>> might sound old-fashioned these days but I find it difficult
> > >>> to rubber stamp things without understanding why.
> > >>> This is all I'm going to say about this BoF unless someone
> > >>> has a PS to discuss.
> > >>>
> > >>> Hesham
> > >>>
> > >>>>
> > >>>>     For this scenario to work, the mobile node must be able
> > >>> to indicate
> > >>>>     to the attached MAG which flow will be sent over the
> > >>> attachment to
> > >>>>     the MAG.  It may do this by indicating the service
> > >>> identifer during
> > >>>>     the layer 2 attachment to the MAG.  The service identifier is
> > >>>>     described in [4].  The MAG, in turn must include the
> > >>> flow information
> > >>>>     in the Proxy Binding Update sent to the LMA.  The MAG
> > >>> may use the
> > >>>>     Service Selection option [4] in the Proxy Binding
> > >>> Update to indicate
> > >>>>     the flow information.  The MAG may also contruct a flow
> > >>> filter and
> > >>>>     convey the information in the Proxy Binding Update.
> > >>> See [3] for more
> > >>>>     information on carrying flow filters in the proxy
> > >>> binding update.
> > >>>>
> > >>>>     The LMA processes the Proxy Binding Update from the MAG
> > >>> and creates a
> > >>>>     filter based on the flow information.  The flow filters
> > >>> may be stored
> > >>>>     in the binding cache entry for the mobile node.
> > >>>>
> > >>>>     [3]  Soliman, H., "Flow Bindings in Mobile IPv6 and Nemo Basic
> > >>>>          Support", draft-soliman-monami6-flow-binding-04 (work in
> > >>>>          progress), March 2007.
> > >>>>
> > >>>>     [4]  Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
> > >>>>          Selection for Mobile IPv6",
> > >>> draft-korhonen-mip6-service-04 (work
> > >>>>          in progress), October 2007.
> > >>>>
> > >>>> [4] got published as RFC 5149.
> > >>>>
> > >>>> Anyway, I don't think we should get into discussing
> > >>> solutions at this
> > >>>> point. The above is to just show that the MIPv6 solutions can be
> > >>>> re-used for PMIPv6. We don't have to re-invent what we have
> > >>> done in the IETF so far.
> > >>>>
> > >>>> I would prefer that we let the market decide whether they
> > >>> want to go
> > >>>> with MIPv6 or PMIPv6. Not for us lecture folks to use MIPv6
> > >>> or PMIPv6.
> > >>>> that would be a political discussion. :)
> > >>>>
> > >>>> Vijay
> > >>>>
> > >>>>>
> > >>>>> Hesham
> > >>>>>
> > >>>>>
> > >>>>> On 8/04/09 4:59 AM, "Vijay Devarapalli" <vijay at wichorus.com> wrote:
> > >>>>>
> > >>>>>> George, Hesham,
> > >>>>>>
> > >>>>>> I don't see the point in having philosophical discussions
> > >>> on whether
> > >>>>>> Mobile IPv6 or Proxy Mobile IPv6 should be used at this
> > >>> point. That
> > >>>>>> ship has sailed. What we have as a reality is folks deploying
> > >>>>>> systems with inter access technology handovers with PMIPv6 as the
> > >>>>>> mobility management protocol. Asking these folks to now
> > >>> use Mobile
> > >>>>>> IPv6 does not help anyone, IMHO.
> > >>>>>>
> > >>>>>> Vijay
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> NetExt mailing list
> > >>> NetExt at mail.mobileip.jp
> > >>> http://www.mobileip.jp/mailman/listinfo/netext
> > >>>
> > >>
> > >> _______________________________________________
> > >> NetExt mailing list
> > >> NetExt at mail.mobileip.jp
> > >> http://www.mobileip.jp/mailman/listinfo/netext
> > >
> > > _______________________________________________
> > > NetExt mailing list
> > > NetExt at mail.mobileip.jp
> > > http://www.mobileip.jp/mailman/listinfo/netext
> >
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext