Re: [netlmm] [netext] [MEXT] NEXTEXT2: first draft of the bofdescription

inline

On Tue, Jun 30, 2009 at 5:31 PM, Koodli,
Rajeev<rkoodli@starentnetworks.com> wrote:
>
> Hi George, Raj,
>
>
>>
>> GT> This is good justification answering the "why" and it leads to an
>> obvious set of options for the "what". It implies something
>> about the solution space that I would like this BOF to be
>> specific about. i.e., if the reason to do this is to enable
>> inter-tech and multi-homing without client MIP in the mobile,
>> does it mean:
>> a)  you do not want any mobility software in the mobile? (this seems
>> unrealistic)
>
> What constitutes "mobility software" without which the above features are unrealistic?
>

GT2> Any software that enables an MN to signal to the MAG (or the PMIP
network) anything about inter-tech or flow movement.
I claim (see draft-tsirtsis-netext-controversy) that these features
are unrealistic without such MN signalling.
If you think that these features are realizable without signalling
from the mobile then by all means lets charter these items with a
"no-MN-changes" clause. Otherwise lets identify what kind of
signalling this  group intends to define.

>
>> b)  that you want L2 software in the client? (this is possible for
>> *some* technologies and I do not think that such work belongs
>> to the IETF...but the BOF could discuss this)
>
> Agree. Part of this exercise is to identify what is feasible in L2, so that we don't spend our time on such things.

GT> Which means that you do not think L2 signalling based solutions
should be worked on in the IETF?

>
>> c)  that you want network layer software in the  mobile but
>> not MIP; (This clearly makes no sense given your "why")
>>
>
> We can start by saying that MIP has the ingredients you need to support the features of interest. For an operator, it is one of the options.
>
> We also need to look at supporting mobile nodes without MIP. In other words, we can say for a feature X, 1) MIP is one of the options, and 2) use PMIP-extensions if your particular deployment does not permit you to use option 1).
>

GT> Which means that you think these PMIP-extensions involve L3
signalling from the MN or not?

> Regards,
>
> -Rajeev
>
>
>
>> Would you rather revise your "why" ? :-)
>>
>> George
>>
>> > One of the outcomes of this discussion is quite possibly
>> the fact that
>> > the IETF believes the use of host based mobile IP protocols is the
>> > right choice and recommends it as such. And that is fine.
>> But I think
>> > we should also consider the approaches to providing these
>> features for
>> > PMIP6 which would not necessarily result in reinventing host based
>> > mobile IP type of capabilities on the MNs.
>> >
>> > I don't know if the above justifies the reason why we are
>> having this
>> > discussion (yet again :) ).
>> >
>> > -Raj
>> >
>> >>
>> >> Hesham
>> >>
>> >>>
>> >>> Regards, marcelo
>> >>>
>> >>>> Hesham
>> >>>>
>> >>>>
>> >>>>> Regards, marcelo
>> >>>>>
>> >>>>>
>> >>>>> Hesham Soliman escribió:
>> >>>>>
>> >>>>>> A quick comment.
>> >>>>>> I don't see any reason for an IETF WG to look for a
>> solution that
>> >>>>>> works for a limited set of technologies and try to
>> solve that on
>> >>>>>> layer 2. This is clearly not our job. Similarly, there
>> is little
>> >>>>>> gain in solving this for a limited set of technologies on L3
>> >>>>>> given that we already have a layer 2 agnostic
>> solution. Why would
>> >>>>>> we want to develop another one for a limited set of
>> link layers?
>> >>>>>>
>> >>>>>> Hesham
>> >>>>>>
>> >>>>>>
>> >>>>>> On 30/06/09 10:39 PM, "marcelo bagnulo braun"
>> <marcelo@it.uc3m.es> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> George,
>> >>>>>>>
>> >>>>>>>
>> >>>>>> great summary
>> >>>>>>
>> >>>>>> just one comment below...
>> >>>>>>
>> >>>>>>
>> >>>>>> George Tsirtsis
>> >>>>>>
>> >>>>>>
>> >>>>>>> escribió:
>> >>>>>>> With PMIP things are not so clear....it is not even
>> clear we are
>> >>>>>>>
>> >>>>>>> talking about the *network layer*... and thus it is
>> not so clear
>> >>>>>>> how
>> >>>>>>>
>> >>>>>>> "generic" solutions can be.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> right, so one relevant question is how
>> >>>>>>
>> >>>>>>
>> >>>>>>> generic we want this to be.
>> >>>>>>>
>> >>>>>>>
>> >>>>>> For instance, it may be also sufficient to support
>> >>>>>>
>> >>>>>>
>> >>>>>>> inter technology
>> >>>>>>>
>> >>>>>>>
>> >>>>>> handovers for a subset of L2 technologies that can support
>> >>>>>>
>> >>>>>>
>> >>>>>>> it at the L2
>> >>>>>>>
>> >>>>>>>
>> >>>>>> as you stated.
>> >>>>>> So, one thing that we need to define is whether
>> >>>>>>
>> >>>>>>
>> >>>>>>> we are looking for a
>> >>>>>>>
>> >>>>>>>
>> >>>>>> solution that supports inter technology handover with
>> >>>>>>
>> >>>>>>
>> >>>>>>> any two L2
>> >>>>>>>
>> >>>>>>>
>> >>>>>> combiantios or are we looking for a solution that
>> supports inter
>> >>>>>>
>> >>>>>> technology handovers for a limited set of technologies?
>> >>>>>> I think this is a key
>> >>>>>>
>> >>>>>>
>> >>>>>>> requirements that we need to be explicit about.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> The challenge for the BOF
>> >>>>>>> is to throw some light on how PMIP can be compatible
>> with this
>> >>>>>>> extended functionality,  what type of additional
>> signalling is
>> >>>>>>> needed, and at which layer they intend to implement such
>> >>>>>>> signalling. Let's see.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> while i
>> >>>>>>
>> >>>>>>
>> >>>>>>> agree with that, i think a first step that this bof needs to
>> >>>>>>>
>> >>>>>>>
>> >>>>>> throw some light
>> >>>>>>
>> >>>>>>
>> >>>>>>> on is what are the functional requirements for the
>> >>>>>>>
>> >>>>>>>
>> >>>>>> support of the required
>> >>>>>>
>> >>>>>>
>> >>>>>>> features. I think the previous is a good example
>> >>>>>>>
>> >>>>>>>
>> >>>>>> of one requirement that we
>> >>>>>>
>> >>>>>>
>> >>>>>>> need to flesh out. There are many others.
>> >>>>>>>
>> >>>>>>>
>> >>>>>> Regards, marcelo
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> George
>> >>>>>>>
>> >>>>>>> On
>> >>>>>>> Tue, Jun 30, 2009 at 1:43 AM, Charles E.
>> >>>>>>>
>> >>>>>>> Perkins<charles.perkins@earthlink.net> wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> Hello Basavaraj,
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>> Isn't make-before-break a function performed
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> at the link layer?
>> >>>>>>>>
>> >>>>>>>> It
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>> certainly isn't PHY, and I wouldn't think it
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> qualifies as MAC (i.e., it
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>> doesn't control the
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> device's access to the medium).
>> >>>>>>>>
>> >>>>>>>> Regards,
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>> Charlie P.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> PS. Which is the proper mailing list for this
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>> discussion?
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> Basavaraj.Patil@nokia.com wrote:
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>> Hi
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>> Frank,
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>> Make-before-break is inherently supported in certain
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>> technologies such as
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>> CDMA/WCDMA (which has soft HO features built in). The
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>> same is not possible
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>> for example in TDMA (GSM) or OFDMA (802.16e and
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>> WiFi). 802.16e does have a
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>> contorted mechansim for achieving the same but
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>> that's besides the point.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>> So IMO it is a capability of the Phy/Mac.
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>> However it is possible to emulate soft-handovers and achieve
>> >>>>>>>
>> >>>>>>> make-before-break in certain cases. For example it is
>> possible
>> >>>>>>> to be
>> >>>>>>>
>> >>>>>>> simultaneously connected to HSPA and WiFi and accomplish a
>> >>>>>>>
>> >>>>>>> make-before-break
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>> HO. I guess the definition of the term depends on an
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>> access tchnology or
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>> the
>> >>>>>>>>> combination of access technologies in the
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>> context of a use-case.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>> -Raj
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> On 6/29/09 4:36 PM, "ext Frank
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>> Xia" <xiayangsong@huawei.com> wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>> Hi Raj
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> IMHO Make-before-break is not a link-layer technology.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> , but  a concept
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> (or a strategy).    Related to the topic we
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> are discussing, making target
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> interface ready before moving
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> traffic to it is kind of
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> make-before-break.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> BR
>> >>>>>>>>>> Frank
>> >>>>>>>>>>
>> >>>>>>>>>> ----- Original Message
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> -----
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> From: <Basavaraj.Patil@nokia.com>
>> >>>>>>>>>> To:
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> <xiayangsong@huawei.com>; <marcelo@it.uc3m.es>;
>> >>>>>>> <netext@ietf.org>;
>> >>>>>>>
>> >>>>>>> <mext@ietf.org>; <netlmm@ietf.org>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> Cc: <netext-chairs@tools.ietf.org>;
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> <rdroms@cisco.com>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> Sent: Monday, June 29, 2009 3:43 PM
>> >>>>>>>>>> Subject: Re:
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> [netext] [netlmm] NEXTEXT2: first draft of the bof
>> >>>>>>>
>> >>>>>>> description
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> Hi Frank,
>> >>>>>>>>>>
>> >>>>>>>>>> Comments
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> inline:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> On 6/29/09 2:57 PM, "ext Frank Xia"
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> <xiayangsong@huawei.com> wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>> Hi
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> Raj
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> My main point is make-before-break strategy is the best
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> way to solve multi-radio handover.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>> The IETF cannot
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> do anything about whether an MN has the ability to
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> accomplish
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> make-before-break connectivity. It depends on the link-layer
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> technology,
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> spectrum that they operate in, etc. So this approach is a
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> non-starter.
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> The IETF solution has to be agnostic to underlying access
>> >>>>>>>
>> >>>>>>> technologies.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>> Please see my inline
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> response.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> BR
>> >>>>>>>>>>> ----- Original Message -----
>> >>>>>>>>>>> From:
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> <Basavaraj.Patil@nokia.com>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> To: <xiayangsong@huawei.com>;
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> <marcelo@it.uc3m.es>; <netext@ietf.org>;
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> <mext@ietf.org>;
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> <netlmm@ietf.org>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> Cc: <netext-chairs@tools.ietf.org>;
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> <rdroms@cisco.com>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> Sent: Monday, June 29, 2009 11:50 AM
>> >>>>>>>>>>> Subject:
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> Re: [netlmm] NEXTEXT2: first draft of the bof
>> >>>>>>> description
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> Frank,
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> On 6/29/09 11:16
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> AM, "ext Frank Xia" <xiayangsong@huawei.com> wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>> Hi Guys
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> I have comments on inter-technology
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> handover.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>> IMHO, flow mobility could solve problems
>> >>>>>>>>>>>> which
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> inter-tech handover is try to deal with.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>> Flow
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> mobility also includes the ability to move a flow
>> from one mobility
>> >>>>>>>
>> >>>>>>> session to another. Multiple mobility sessions could
>> be established via
>> >>>>>>>
>> >>>>>>> a
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> single interface in which case flow mobility
>> would be achieved
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> within
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> the
>> >>>>>>>>>>> scope of a single interface. Hence flow mobility and
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> inter-technology
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> handovers are separate features.
>> >>>>>>>>>>> Frank=>IMHO,
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> inter-technology is trying to move all the traffic on
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> one interface to
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> another interface.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>> Right. I guess you answered the
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> question about the difference between
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> flow
>> >>>>>>>>>> mobility and
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> inter-technology handovers. You could extrapolate and say
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> that
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> inter-technology HO is the case where you move all
>> flows from one
>> >>>>>>>
>> >>>>>>> interface
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> to another and hence a variant of flow mobility.
>> While that is
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> true, you
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> should also recognize that the granularity of flow
>> mobility is
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> finer and
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> does not have to necessarily be a relocation of a
>> flow between
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> physical
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> interfaces.
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>>> I assume that two
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> heterogeneous interfaces are
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>> all active during the handover.  It is
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> easy to move
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>> a flow(or all flows) from an interface to
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> another.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>> Possibly.. But the point is to
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> identify what extensions (possibly to the
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> MN)
>> >>>>>>>>>>> are needed in order
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> to achieve handovers across interfaces.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> Frank=>If we see inter-tech
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> handover as a subset of flow mobility,
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> there is one problem left, that
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> is flow mobility.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>> See above. Flow mobility is a
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> feature that can work across multiple
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> mobility
>> >>>>>>>>>> sessions within the
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> scope of a single interface as well.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>>> This is
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> probably the reason why there is no
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>> inter-tech handover solution
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> standerdized
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>> for client MIP.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>> Client
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> MIP inherently supports handovers across multiple interfaces.
>> >>>>>>>
>> >>>>>>> Performance improvements to the handovers are
>> accomplished using
>> >>>>>>>
>> >>>>>>> solutions
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> such as FMIP.
>> >>>>>>>>>>> Frank=>Maybe, I am missing something.
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> However FMIP  is not applicable
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> to PAR/NAR collocated scenario.  For
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> example, a mobile node with two
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> interface connects to the same access
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> router (ASN-GW for WiMAX,
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> PDN-GW for LTE).   Does FMIP work when mobile
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> node handover from
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> one technology to another?
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>> Not sure I understand the question. In your
>> example above, I believe
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> the
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> MN
>> >>>>>>>>>> would connect to the ASN-GW via the WiMAX
>> interface and to an
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> S-GW via
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> the
>> >>>>>>>>>> LTE interface. The P-GW (LMA) may be the same. If the
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> question is, can
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> you
>> >>>>>>>>>> use FMIP to optimize handovers in such a
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> scenario... Yes. Not FMIP, but
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> PFMIP6 (ref. MIPSHOP WG I-D). But I don't
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> think we are looking at
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> optimizing
>> >>>>>>>>>> handovers in this
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> discussion.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> As per the current PMIP6 specification wherein no
>> changes to
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> the host are
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> required, it is not possible to do an inter-technology
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> handover. This is
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> a
>> >>>>>>>>>> limitation which implies that PMIP6 provides
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> host mobility to an MN
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> within
>> >>>>>>>>>> the scope of a single access
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> technology. Host based mobile IP does not
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> have
>> >>>>>>>>>> this
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> problem.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> -Raj
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>> -Raj
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>> BR
>> >>>>>>>>>>>> Frank
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> ----- Original Message -----
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> From: "marcelo bagnulo braun" <marcelo@it.uc3m.es>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>> To:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> <netext@ietf.org>; "mext" <mext@ietf.org>; <netlmm@ietf.org>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>> Cc:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> <netext-chairs@tools.ietf.org>; "Ralph Droms"
>> <rdroms@cisco.com>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>> Sent:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> Sunday, June 28, 2009 1:16 PM
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>> Subject: [netlmm] NEXTEXT2: first draft
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> of the bof description
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> Hi,
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> This is a first draft of the BOF description for your
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> consideration.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> It
>> >>>>>>>>>>>>> is
>> >>>>>>>>>>>>> still very open so, feel free to
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> comment on whether the proposed
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> approach
>> >>>>>>>>>>>>> seems appropriate or
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> not.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> NETEXT2 BOF description
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> -----------------------
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> a network based mobility
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> protocol built on Mobile IPv6 [RFC3775].
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> PMIP6 provides mobility to
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> IP hosts without requiring any protocol
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> enhancements or additional
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> capabilities on the host.
>> >>>>>>>>>>>>> Current
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> PMIP6 specification fully defines how to provide mobility
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> support for
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> mobile nodes with a single interface roaming in a PMIP6
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> domain. The
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> goal of this BOF is gain understanding of how to support
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> nodes with
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> multiple interfaces (of possible different technologies) in
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> a
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> PMIP6 network.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> In particular, this BOF assumes the following
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> scenario:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> We have a single PMIP6 domain that has deployed
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> multiple
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> access technologies and needs to support nodes that
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> have
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> multiple interfaces, possibly of different
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> technologies.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> In particular, the following capabilities are
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> needed:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> - Inter-technology handover support. The MN has
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> initiated a
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> communication over one interface and it needs to be able
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> to move
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> the established connection to a different interface of
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> a possibly different technology. The reason for moving
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> the
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> communication to another interface is because of the MNs
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> mobility and
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> attaching via a different interface. Basically
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> the ability to perform
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> handovers that span different access
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> technologies.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> -
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> Multihoming support. The MN with multiple interfaces
>> of possibly
>> >>>>>>>
>> >>>>>>> different technologies should be able to use them
>> simultaneously to
>> >>>>>>>
>> >>>>>>> exchange data and manage the mobility of communications
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> established
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> through the different interfaces.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> - Flow mobility. A MN with
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> multiple interfaces of possibly
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> different technologies must be able to
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> move a flow from
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> one interface to another. Moreover, the MN should be
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> able
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> to inform the network through which interface it wishes
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> to receive different types of flows.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> In order to provide the
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> support for these capabilities, different
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> approaches can be
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> envisioned, namely:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> - L2 only approaches. In this type of approaches,
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> the mechanisms
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> to provide the required capabilities are fully L2
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> mechanisms and
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> no modification of the IP layer is needed.
>> >>>>>>>>>>>>> - L3
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> only approaches. In this type of approaches, the mechanism to
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> provide
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> to required capabilities are located in the IP layer
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> - Hybrid L2/L3
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> approaches. In this case, some mechanisms are
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> located in L2 and other
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> mechanisms are located in L3.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> Now, the different possible approaches
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> vary greatly in their nature
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> and resulting capabilities. To
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> understanding the benefits and
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> suitability of these alternatives, the
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> requirements have to be
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> properly defined and
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> understood.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> The main goal of the BOF is understanding the need
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> for work in the
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> IETF in this area. In order to do so, during the BOF,
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> we will attempt
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> to:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> 1) Understand the applicable
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> scenarios, and the problem statement
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> related
>> >>>>>>>>>>>>> to
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> those
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> 2) Understand the restrictions and requirement
>> imposed to
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> solutions to
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> address the problem statement and scenarios
>> >>>>>>>>>>>>> 3)
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> Get an overview of the proposed solutions
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> netlmm mailing
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> list
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> netlmm@ietf.org
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>> _______________________________________________
>> >>>>>>>>>>> netext mailing
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> list
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> netext@ietf.org
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> https://www.ietf.org/mailman/listinfo/netext
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>> MEXT mailing list
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>> MEXT@ietf.org
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>> _______________________________________________
>> >>>>>>>> MEXT mailing list
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>> MEXT@ietf.org
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> netlmm mailing list
>> >>>>>>>
>> >>>>>>> netlmm@ietf.org
>> >>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> netlmm mailing
>> >>>>>>
>> >>>>>>
>> >>>>>>> list
>> >>>>>>>
>> >>>>>>>
>> >>>>>> netlmm@ietf.org
>> >>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >
>> >
>> _______________________________________________
>> netext mailing list
>> netext@ietf.org
>> https://www.ietf.org/mailman/listinfo/netext
>>
>
>
> This email and any attachments may contain legally privileged and/or confidential information of Starent Networks, Corp. and is intended only for the individual or entity named in the message.  The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you.
>