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

Hi Gerardo,

Thanks for your reply. Please see reply in-line.

BR,
Mohana

> -----Original Message-----
> From: Giaretta, Gerardo [mailto:gerardog at qualcomm.com]
> Sent: Wednesday, April 08, 2009 10:12 PM
> To: Mohana Jeyatharan; Hesham Soliman; Koodli, Rajeev;
> netext at mail.mobileip.jp
> Subject: RE: [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?

What I meant is MN that does not have a client stack to handle mobility managemnt. Anyway, you would know better, but from what I have read,
the S-GW-P-GW interface is common to UTRAN, GERAN, HRPD access. All IP traffic via this interface. So it is not only LTE terminals but legacy terminals that have been there for couple of years.

> 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.

You are right. The session continuity is a configurable parameter. If needed then DSMIP or PMIP should support this. DSMIP can use BU and PMIP also has this HI flag=2. That is seemless handoff during inter technology switching.

> 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