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

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 28 Jun 2009 20:16:11 +0200

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

---

From: Xiangsong Cui <[email-masked]>
Date: Mon, 29 Jun 2009 09:27:01 +0800

Hi Marcelo,

I have a comment about the description.

> the established connection to a different interface of
                          ^^^^^^^^^
> a possibly different technology.

I think "move the established communication" is better than "move the 
established connection".
Because all the connections exist at the time if they have been established. 
What we move
is the session or traffic flow, but not the connection.  For example, there 
is a word from
draft-ietf-mext-flow-binding-01.txt:

 "A single connection is
   typically identified by the source and destination IP addresses,
   transport protocol number and the source and destination port
   numbers. " (This sentence is modified in 02txt, but I think it is right.)

Regards

Xiangsong

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
Cc: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>; "Jari Arkko" 
<[email-masked]>; <[email-masked]>
Sent: Monday, June 29, 2009 2:16 AM
Subject: [MEXT] 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
> -----------------------
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 29 Jun 2009 08:42:07 +0200

> I think "move the established communication" is better than "move the 
agree

regards, marcelo

> Because all the connections exist at the time if they have been 
> established. What we move
> is the session or traffic flow, but not the connection.  For example, 
> there is a word from
> ----- Original Message ----- From: "marcelo bagnulo braun" 
> <[email-masked]>
> Cc: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>; "Jari 
> Arkko" <[email-masked]>; <[email-masked]>
>> 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
>> -----------------------
>>

---

From: Frank Xia <[email-masked]>
Date: Mon, 29 Jun 2009 11:16:42 -0500

Hi Guys

I have comments on inter-technology handover.

IMHO, flow mobility could solve problems
which inter-tech handover is try to deal with.
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.

This is probably the reason why there is no
inter-tech handover solution standerdized
for client MIP.

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

> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 29 Jun 2009 17:48:09 +0100

Frank, your comment below is strange to say the least.

MIP handoffs can be between interfaces of the same or different
technologies. Since client MIP works at the IP layer (above the Link
Layer of any specific technology) there is nothing that client MIP
(and any of its features) need to specifically define for
inter-technology handoffs.

  >Did you so far think that this means that client MIP only works
intra-technology?<

For PMIP, this is an issue because currently there is no defined
protocol (on any layer) between MN and MAG...which is one of the
issues to be discussed in netext2 bof.

George

---

From: <[email-masked]>
Date: Mon, 29 Jun 2009 18:50:02 +0200

Frank,

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

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

> inter-tech handover solution standerdized

Client MIP inherently supports handovers across multiple interfaces.
Performance improvements to the handovers are accomplished using solutions
such as FMIP.

-Raj

---

From: Frank Xia <[email-masked]>
Date: Mon, 29 Jun 2009 12:20:00 -0500

Hi Gorge

It seems that  I did not make me clear.

1)Single radio handover.
   MN should disconnect from one BS , and connect
   to a second BS.   MN can't connect to the two BS
   at the same time.  Handover solutions (FMIP/PMIP)
   are needed.

2)Dual radio handover
   MN connects to the two BS'  at the same time.
   Flow mobility is sufficient when move a flow( or  all
   flows)  from  one interface to another.

BR
Frank

----- Original Message ----- 
From: "George Tsirtsis" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "marcelo bagnulo braun" <[email-masked]>; <[email-masked]>; "mext" 
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, June 29, 2009 11:48 AM
Subject: Re: [MEXT] [netlmm] NEXTEXT2: first draft of the bof description

intra-technology?<

George

On Mon, Jun 29, 2009 at 5:16 PM, Frank Xia<[email-masked]> wrote:
>> is

---

From: "MELIA TELEMACO" <[email-masked]>
Date: Mon, 29 Jun 2009 20:03:31 +0200

Frank,

I think you should not mix flow mobility and inter-tech handover. A MN might or might now use multiple connections at the same time...

telemaco

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Frank Xia
Envoyé : lundi 29 juin 2009 19:20
À : George Tsirtsis
Cc : [email-masked]; [email-masked]; [email-masked]; mext
Objet : Re: [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

Hi Gorge

1)Single radio handover.

2)Dual radio handover

BR
Frank

----- Original Message ----- 
From: "George Tsirtsis" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "marcelo bagnulo braun" <[email-masked]>; <[email-masked]>; "mext" 

intra-technology?<

George

---

From: Frank Xia <[email-masked]>
Date: Mon, 29 Jun 2009 14:57:00 -0500

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,

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.

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.

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

---

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:
> ----- Original Message ----- From: <[email-masked]>
>>> It is
>>> 1) Understand the applicable scenarios, and the problem statement 
>>> related
>>> to
>>> those

-- 
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: Frank Xia <[email-masked]>
Date: Mon, 29 Jun 2009 15:22:31 -0500

Hi Telemaco

There are three use cases in my mind:

1)Two interfaces are active at the same time.

  This is the most common case.  Flow mobility
  can handle all the problems relating to handover.

2)One interafce is active while the other is dormant.

  The dormant interface is activated before handover.
  Flow mobility can also do with it.

3)One interafce is active while the other is dormant, and
  traffic must be offloaded from the active one even though
  the dormant one is not ready.

  This is a rare case.  If   "inter-technology handover"
  focuses on dealing with this scenario, I am fine.

BR
Frank

----- Original Message ----- 
From: "MELIA TELEMACO" <[email-masked]>
To: "Frank Xia" <[email-masked]>; "George Tsirtsis" 
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
"mext" <[email-masked]>
Sent: Monday, June 29, 2009 1:03 PM
Subject: RE: [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

Frank,

I think you should not mix flow mobility and inter-tech handover. A MN might 
or might now use multiple connections at the same time...

telemaco

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de 
Frank Xia
Envoyé : lundi 29 juin 2009 19:20
À : George Tsirtsis
Cc : [email-masked]; [email-masked]; [email-masked]; mext
Objet : Re: [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

Hi Gorge

1)Single radio handover.

2)Dual radio handover

BR
Frank

----- Original Message ----- 
From: "George Tsirtsis" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "marcelo bagnulo braun" <[email-masked]>; <[email-masked]>; "mext"

intra-technology?<

George

---

From: <[email-masked]>
Date: Mon, 29 Jun 2009 22:43:18 +0200

Hi Frank,

Comments inline:

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

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

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

> 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

> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: Frank Xia <[email-masked]>
Date: Mon, 29 Jun 2009 16:36:20 -0500

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: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, June 29, 2009 3:43 PM
Subject: Re: [netext] [netlmm] NEXTEXT2: first draft of the bof description

Hi Frank,

Comments inline:

-Raj

---

From: <[email-masked]>
Date: Tue, 30 Jun 2009 00:28:57 +0200

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

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 30 Jun 2009 10:12:19 +1000

It would be nice if postings are limited to one mailing list please!

Hesham

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 29 Jun 2009 17:43:39 -0700

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?

---

From: "Stuart W. Card" <[email-masked]>
Date: Mon, 29 Jun 2009 21:18:30 -0400

> device's access to the medium). 
Different approaches to make-before-break can be implemented in 
different layers.

For several years, our team has done it at Layer 3, because we have had 
the luxury
of multiple radios that can operate concurrently. We simply make a MIP 
registration
on every radio that policy says we are allowed to use at the moment and 
that can
hear a base station, and insert concurrent multipath routes into our 
routing table.

Traffic naturally gets divided among paths, which we weight according to 
their
recent performance, so as a link fades, less and less traffic is routed 
over that
path, and eventually we drop it from the routing table (generally when 
we can
no longer successfully renew our MIP registration over it).

This is fairly trivial if the load balancing is flow-by-flow. If it is 
packet-by-packet,
then most TCP implementations will blow up, so we use the SCPS-TP variant.

My point is not that everyone should use SCPS-TP over Concurrent Multipath
Routing, but that make-before-break is a cat that can be skinned many ways,
depending upon what you are making and breaking: a physical channel;
a logical link; an end-to-end path; etc.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 30 Jun 2009 09:02:30 +0700

> combination of access technologies in the context of a use-case.

I'm inclined to agree with you, though isn't the implementation of
make-before-break capability possible using any PHY & dual radios?  The
problem being the price of parts...

...

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 30 Jun 2009 11:49:33 +0100

Hi Charlie/Raj, et.al.,

In intra-technology handoffs, Make Before Break (MBB) is the ability
of the given technology to acquire a connection to the new BS/sector
while maintaining the connection to the existing BS/sector.

CDMA sited as an example of technology capable of MBB, is maybe not
the best one since the MBB functionality of CDMA is really at the PHY
layer i.e., the MN maintains a single link to a BS-Controller type box
over one or more PHY-layer connections to BSs. So this is PHY layer
MBB.

OFDMA on the other hand, at least as implemented in Flash-OFDM (a less
known technology), is capable of implementing link layer MBB where an
MN can create two independent link layer connections to two different
BSs (in Flash-OFDM playing the role of MIPv4 FAs), but that seems to
be an unusual case so far.

Most technologies, seem to hide intra-technology handoff from the IP
layer, and instead present a stable interface that to the IP layer it
does not appear to be moving. So often, intra-technology handoffs of
that kind (whether it is MBB or BBM) are transparent to the IETF.

Inter-technology handoffs are a bit different. In some cases, such
handoffs are still hidden from the IP layer, e.g., handoffs between
3GPP-specific technologies tends to be handled at lower layers.

In other cases, however, such handoffs are visible to IP. This happens
when each of the technology-specific interfaces present a different
interface to the IP layer. In this case the interfaces tend to come up
and down independently from each other (e.g., WLAN and 3G), but that
is often also limited by the capabilities of the device e.g., a lot of
devices can only transmit/receive over one radio at the time (strictly
an implementation issue).

People also often forget inter-domain handoffs. These, whether intra-
or inter-technology, can also in some cases be visible to the IP
layer.

The bottom line is that at the *network layer* we should not be making
too many assumptions about the capabilities of the lower layers. We
should instead define generic mechanisms that can be widely applied,
so for example, MIP+MCoA+FlowBindings, says nothing about MBB/BBM (and
it says even less about inter/intra-technology/domain) and it works
with all of the above. When I say it works, I mean the protocol is
self-consistent in all of these cases, but obviously when you can only
do BBM handoffs, MCoA and FlowBindings are not as useful; which is
fine.

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.

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.

George

On Tue, Jun 30, 2009 at 1:43 AM, Charles E.
Perkins<[email-masked]> wrote:
>>>>>> It

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 30 Jun 2009 14:39:28 +0200

George,

great summary

just one comment below...

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

> signalling is needed, and at which layer they intend to implement such

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

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 30 Jun 2009 23:19:00 +1000

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

great summary

George Tsirtsis
> escribió:
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 
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

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

> certainly isn't PHY, and I wouldn't think it
>>> Hi
> 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
>>>> To:
> <[email-masked]>; <[email-masked]>; <[email-masked]>;
>>>>
>>>> Subject: Re:
> [netext] [netlmm] NEXTEXT2: first draft of the bof
>>>>
> description
>>>>
>>>>
>>>>
>>>> Hi Frank,
>>>>
>>>> Comments
> inline:
>>>>
>>>>
>>>>> Hi
> Raj
>>>> 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
>>>>> 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
>>>>>>
>>>>> 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
>>>>> 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
>>>>> Possibly.. But the point is to
> identify what extensions (possibly to the
>>>>> MN)
>>>>> are needed in order
>>>> See above. Flow mobility is a
> feature that can work across multiple
>>>> mobility
>>>> sessions within the
>>>>> Client
> MIP inherently supports handovers across multiple interfaces.
>>>>>
> Performance improvements to the handovers are accomplished using
>>>>>
> solutions
>>>>> such as FMIP.
>>>> 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
>>>> PFMIP6 (ref. MIPSHOP WG I-D). But I don't
> think we are looking at
>>>> optimizing
>>>> handovers in this
> discussion.
>>>> 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
>>>>>>
>>>>>> To:
> <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
>>>>>> Cc:
> <[email-masked]>; "Ralph Droms" <[email-masked]>
>>>>>> Sent:
>>>>>>> still very open so, feel free to
> comment on whether the proposed
>>>>>>> approach
>>>>>>> seems appropriate or
> not.
>>>>>>>
>>>>>>> NETEXT2 BOF description
>>>>>>>
> -----------------------
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> the
> communication to another interface is because of the MNs
>>>>>>> mobility and
> attaching via a different interface. Basically
>>>>>>> the ability to perform
>>>>>>> -
> Multihoming support. The MN with multiple interfaces of possibly
>>>>>>>
>>>>>>> In order to provide the
> support for these capabilities, different
>>>>>>> approaches can be
> envisioned, namely:
>>>>>>> - 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
>>>>>>> IETF in this area. In order to do so, during the BOF,
> we will attempt
>>>>>>> to:
>>>>>>>
>>>>>>> 3)
> Get an overview of the proposed solutions
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> netlmm mailing
> list
>>>>> netext mailing
> list

netlmm mailing
> list
[email-masked]

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 30 Jun 2009 15:29:14 +0200

Hesham,

I am not commenting on whether we should do this in the IETF or not,
I am just stating that we first need to understand what are the needs of 
the people that are running these networks.
So, among the things i would like to understnad is that when they say 
they need to support intertechnology handovers, whether they need to do 
it for any L2 combination, or just a limited/defined set of technologies 
that have some special characteristics?

I think it is relevant to understnad this point in order to understnad 
the problem better.

Regards, marcelo

Hesham Soliman escribió:
>>> qualifies as MAC (i.e., it
>>>       
>> doesn't control the
>>     
>>> PS. Which is the proper mailing list for this
>>>       
>> discussion?
>>     
>>>> 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.
>>     
>>>> combination of access technologies in the
>>>>         
>> context of a use-case.
>>     
>>>> -Raj
>>>>
>>>>
>>>> On 6/29/09 4:36 PM, "ext Frank
>>>>         
>> Xia" <[email-masked]> wrote:
>>     
>>>>       
>>>>         
>>>>> Hi Raj
>>>>>
>>>>>
>>>>>           
>>>>> , 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
>>>>>           
>> -----
>>     
>>>>> Cc: <[email-masked]>;
>>>>>           
>> <[email-masked]>
>>     
>>>>> On 6/29/09 2:57 PM, "ext Frank Xia"
>>>>>           
>> <[email-masked]> wrote:
>>     
>>>>>         
>>>>>           
>>>>>> Hi
>>>>>>             
>> Raj
>>     
>>>>>> is the best
>> way to solve multi-radio handover.
>>     
>>>>>>           
>>>>>>             
>>>>> The IETF cannot
>>>>>           
>>>>>> Please see my inline
>> response.
>>>>>> From:
>> <[email-masked]>
>>     
>>>>>> To: <[email-masked]>;
>>>>>>             
>> <[email-masked]>; <[email-masked]>;
>>     
>>>>>> <[email-masked]>;
>>>>>>             
>> <[email-masked]>
>>     
>>>>>> Cc: <[email-masked]>;
>>>>>>             
>> <[email-masked]>
>>     
>>>>>>> I have comments on inter-technology
>>>>>>>               
>> handover.
>>     
>>>>>>> which
>> inter-tech handover is try to deal with.
>>     
>>>>>>>             
>>>>>>>               
>>>>>> Flow
>>>>>>             
>>>>>> scope of a single interface. Hence flow mobility and
>>>>>>             
>> inter-technology
>>     
>>>>>> one interface to
>> another 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.
>>     
>>>>>>>             
>>>>>>>               
>>>>>> 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.
>>     
>>>>>>           
>>>>>>             
>>>>> 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
>>>>>>             
>>>>>> 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
>>     
>>>>> use FMIP to optimize handovers in such a
>>>>>           
>> scenario... Yes. Not FMIP, but
>>     
>>>>> handovers in this
>> discussion.
>>>>> As per the current PMIP6 specification wherein no changes to
>>>>>           
>> the host are
>>     
>>>>>>> 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
>>>>>>>> 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
>>     
>>>>>>>> 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 ability to perform
>> handovers that span different access
>>     
>>>>>>>> technologies.
>>>>>>>>
>>>>>>>> -
>>>>>>>>                 
>>>>>>>> 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
>>     
>>>>>>>> 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
>>     
>>>>>>>> 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
>>     
>>>>>>>> 1) Understand the applicable
>>>>>>>>                 
>> scenarios, and the problem statement
>>     
>>>>>>>> related
>>>>>>>> to
>>>>>>>>
>>>>>>>>                 
>> those
>>     
>>>>>>>> 2) Understand the restrictions and requirement imposed to
>>>>>>>>                 
>> solutions to
>>

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 30 Jun 2009 23:48:40 +1000

> I think it is relevant to understnad this point in order to understnad

=> I think the important question to ask is why this is an issue in the
first place? If you have a solution for the superset (all link layers) and
there is a question about whether you need a solution for a subset, then the
question we should ask is "why?". This has to be part of the discussion. "we
want ....*because*..."

Hesham

---

From: "Davis, Terry L" <[email-masked]>
Date: Tue, 30 Jun 2009 06:45:06 -0700

Glen

Right, cost, weight, and drag, in our case.  If you are using links to geos, it definitely takes two antenna's to do make before break.  

However a single antenna, as Connexion by Boeing used, can move from one geo and lock onto another and have layer 3 routing flowing in well under 30 seconds; a short enough time that almost none of the TCP timers trigger.  The user sees a short "loss of QOS" if they are actively typing or talking which appears to be no more than a web server not responding for a few seconds or your VoIP losing a few seconds of conversation.

As far as aviation goes, you will see both types of handoff's made with a make before break probably more common with air-to-ground links than satellite.

Coordination capabilities between layer 2 and layer 3 for the handoffs though are critical.

Take care
Terry

PS: Until the IPSec, PKI, and IKEv2 interoperability between vendors (I mean dozens of different vendors!) progresses such that it actually can be dynamically done, deciding which security associations belong to which link providers and auto-configuring the links, I would expect that establishing link authentication and security will remain a primary challenge to mobility services.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Glen Zorn
> Sent: Monday, June 29, 2009 7:03 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [MEXT] [netext] [netlmm] NEXTEXT2: first draft of thebof
> description
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 30 Jun 2009 16:46:53 +0200

Hesham Soliman escribió:
> first place? If you have a solution for the superset (all link layers)
you are assuming and answer here, i.e. that the answer is that the 
requirement is a subset, which i don't know if it is the case

>  and
sure, "why?" is a valid question, but before asking ourselves "why?", we 
need to answer "what?"

So, let's first provide an detailed answer of what is being required to 
support and and that point we will be in good shape to ask "why?"
i don't think you can ask "why? until a proper answer has been provide 
to "what?"

agree?

Regards, marcelo

---

From: Frank Xia <[email-masked]>
Date: Tue, 30 Jun 2009 10:10:57 -0500

Hi Marcelo

I agree that we should make sure business
requirements before talking about solutions
whether they are based on inter-tech handover,
flow binding, layer 2, or layer 3.

Tentatively, I prepared the following use cases:
1)Michael has a 3GPP&WiFi  terminal.  At first, Michael uses
   3GPP access for p2p download and VoIP call

2)Then Michael gets into his home where WiFi access is available.
   Michael prefers running p2p download through WiFi,
   and leaving the VoIP call still on 3GPP networks.

3)After a while, Michael moves out of his home and loses the WiFi
   connectivity.  All the services through the WiFi access need to be
   moved back to the 3GPP access which is the only  access available.

BR
Frank

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Hesham Soliman" <[email-masked]>
Cc: "mext" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, June 30, 2009 8:29 AM
Subject: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the 
bofdescription

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

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 01 Jul 2009 00:54:25 +1000

> i don't think you can ask "why? until a proper answer has been provide

=> Ok, you're right about my assumption about the answer but it's not coming
from vaccuum :), it's not the first time this is discussed. But ok, I'm
happy to go through this exercise from the beginning. Let's ask "what" and
regardless of the answer ask "why" as well. Because requirements always need
to be justified. 

Hesham

---

From: <[email-masked]>
Date: Tue, 30 Jun 2009 18:20:57 +0200

Hi George,

> that kind (whether it is MBB or BBM) are transparent to the IETF.

Agree. No doubt that the intricacies of the underlying technologies are not
something that we should be worrying about in the IETF or building solutions
for specific cases.

> an implementation issue).

Wifi/3G at least the way they are implemented give the illusion of both
radios being capable of Tx/Rx simultaneously... At least from the IP layer
perspective. But as you said, implementations vary and form factors of
devices such as handhelds vs notebook computers also make a difference.

> or inter-technology, can also in some cases be visible to the IP

Sure.

> do BBM handoffs, MCoA and FlowBindings are not as useful; which is

I agree about the fundamental view that at the network layer, we should be
agnostic to the lower layer capabilities and not design a protocol that
works only for specific L1/2s. However as you are well aware the network
layer does work much more optimally if it is aware of the lower layer
capabilities and such aspects have crept into the protocol specifications in
the IETF. I agree that in certain cases BBM is just fine and there is really
not a need to be able to accomplish MBB only in all cases.

> "generic" solutions can be.

I guess you have a different view about PMIP. But the goal is to develop
solutions that are "generic". I believe your point has been that developing
such a generic solution will be equivalent to basically reinventing host
based mobility protocol capability between the MN and MAG. I guess if the
conclusion boils down to such, then we can simply state the obvious. But at
this time I believe it is not a given and hence this exercise.

> signalling is needed, and at which layer they intend to implement such

Yes.. I think the BoF is intended to clarify these questions.

-Raj

---

From: "MELIA TELEMACO" <[email-masked]>
Date: Tue, 30 Jun 2009 18:21:34 +0200

Hello,

Please see below.

>  focuses on dealing with this scenario, I am fine.
Still inter-tech handover is different from flow mobility. Also 
complexity-wise.
For inter-technology handover the mobile may only provide hints about 
the nature of
the handover (inter-tech HO etc), maybe about handover target or source 
to the network.
If you want flow mobility, you need to handle flow descriptions and 
signal appropriate
filters, hence much more to be done by the mobile and by the network.
Not sure the PMIPv6 protocol should handle flow filters..

If you move all flows during a handover, we're back at inter-tech 
handover, say we
move the complete mobility session with the intention to shut down the 
previous
mobility session (and with mobility session I mean the MN's binding 
between the
HNP and the pMAG at the LMA). Moving the associated flows is implicit.

Hence, requirement on the mobile is very different for flow mobility and 
inter-tech handover
(shouldn't we say dual radio handover here?)

TELE: pretty much agree
Telemaco

marco

>
> BR
> Frank
>
> ----- Original Message ----- From: "MELIA TELEMACO" 
> <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; 
> <[email-masked]>; "mext" <[email-masked]>
> I think you should not mix flow mobility and inter-tech handover. A MN 
> might or might now use multiple connections at the same time...
>
> telemaco
>
> ----- Original Message ----- From: "George Tsirtsis"

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 30 Jun 2009 17:28:40 +0200

agree

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 30 Jun 2009 17:37:25 +0200

Frank,

marco