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

["Koodli, Rajeev" <[e-mail]>]

 

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

Okay.

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

I do not think we should work any L2 signaling here; perhaps this is obvious.

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

Some extensions may be done with L2. Others may need host configurations (such as use of virtual interfaces). If we cannot do away with L2/host-configurations alone, we need to look at L3 signaling - obviously we need to scope this carefully.

-Rajeev



> > 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"
> >> <[e-mail]> 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<[e-mail]> 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?
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>> [e-mail] 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" <[e-mail]> 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: <[e-mail]>
> >> >>>>>>>>>> To:
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> <[e-mail]>; <[e-mail]>; 
> >> >>>>>>> <[e-mail]>;
> >> >>>>>>>
> >> >>>>>>> <[e-mail]>; <[e-mail]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> Cc: <[e-mail]>;
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> <[e-mail]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> 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"
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> <[e-mail]> 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:
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> <[e-mail]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> To: <[e-mail]>;
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> <[e-mail]>; <[e-mail]>;
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> <[e-mail]>;
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> <[e-mail]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> Cc: <[e-mail]>;
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> <[e-mail]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> 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" <[e-mail]> 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" <[e-mail]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>> To:
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>> <[e-mail]>; "mext" <[e-mail]>; 
> <[e-mail]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>> Cc:
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>> <[e-mail]>; "Ralph Droms"
> >> <[e-mail]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>> 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
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> [e-mail]
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>> _______________________________________________
> >> >>>>>>>>>>> netext mailing
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> list
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> [e-mail]
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> https://www.ietf.org/mailman/listinfo/netext
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> _______________________________________________
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>> MEXT mailing list
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>> [e-mail]
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>> _______________________________________________
> >> >>>>>>>> MEXT mailing list
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>> [e-mail]
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>> https://www.ietf.org/mailman/listinfo/mext
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>> _______________________________________________
> >> >>>>>>> netlmm mailing list
> >> >>>>>>>
> >> >>>>>>> [e-mail]
> >> >>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> _______________________________________________
> >> >>>>>> netlmm mailing
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> list
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> [e-mail]
> >> >>>>>> https://www.ietf.org/mailman/listinfo/netlmm
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>
> >> >>
> >> >>
> >> >
> >> >
> >> _______________________________________________
> >> netext mailing list
> >> [e-mail]
> >> 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 [e-mail] -- and destroy all 
> copies of this message and any attachments without reading or 
> disclosing their contents. Thank you.
> >
>