Subject: Re: [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

From: "Stuart W. Card" <[email-masked]>
Date: Mon, 29 Jun 2009 16:11:32 -0400

IMHO, inter-technology handoff and flow mobility
overlap: neither is a strict subset of the other; but
neither are they entirely independent.

Make-before-break is certainly highly desirable,
but perhaps should not be specified as required.

Inter-technology handoff could be specified as
moving _all_ flows from one interface to another,
but that would needlessly over-constrain it: there
clearly are cases where one might wish to move
a sub-set of the flows (for instance, an old path
may be losing capacity while a new one is gaining
strength, but both are likely to remain usable for
some time, so just shift some of the load).

Frank Xia wrote:
> Hi Raj
>
> My main point is make-before-break strategy
> is the best way to solve multi-radio handover.
>
> Please see my inline response.
>
> BR
> ----- Original Message ----- From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
> <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> 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" <[email-masked]> 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.
>
>> 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.
>
>>
>> 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?
>
> -Raj
>
>>
>> BR
>> Frank
>>
>> ----- Original Message -----
>> From: "marcelo bagnulo braun" <[email-masked]>
>> To: <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
>> Cc: <[email-masked]>; "Ralph Droms" <[email-masked]>
>> 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
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/netlmm
>>
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>

-- 
Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc.
* Creativity * Diversity * Expertise * Flexibility * Integrity *
Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501
315-793-0248 x141 FAX -9710 <[email-masked]> www.critical.com

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 30 Jun 2009 14:19:45 -0700

Raj,

>> c)  that you want network layer software in the  mobile but not MIP;
>> (This clearly makes no sense given your "why")
>
> Again, I don't think I said that what I said equates to creating new network
> layer software in the host other than MIP. If the conclusion of the
> discussion results in the understanding that to accomplish these features
> the only option is to develop network layer protocols/software, then I think
> it would be logical to say "Use MIP". But I don't know if we are there yet.
> At least there is a view that there are things other than developing new
> network layer protocols/SW to achieve this functionality.

Are you saying that if we do develop an extension in L3, that would
equate to MIP?

You could have a functionality in L3 independent of the actual
mobility model, no?

-Rajeev

>
>>
>> Would you rather revise your "why" ? :-)
>
> Not yet... But I am keeping an open mind :)
>
> -Raj
>
>>
>> George
>>
>
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>