Subject: [netlmm] 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: 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

>>> 1) Understand the applicable scenarios, and the problem statement 
>>> related
>>> to
>>> those

---

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: 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: 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:04:37 +0200

Hi Hesham,

> question we should ask is "why?". This has to be part of the discussion. "we

We (as in the people in NetExt) want PMIP6 to support inter-technology
handovers, flow binding/mobility and enhanced support for multihoming
*because* :
1. Not every host does or will include host based mobility protocols such as
(DS)MIP
2. An operator may choose to deploy a network with only network based
mobility protocol support

-Raj

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 30 Jun 2009 17:13:18 +0100

inline...

On Tue, Jun 30, 2009 at 4:52 PM, <[email-masked]> wrote:
>
>
> On 6/30/09 9:54 AM, "ext Hesham Soliman" <[email-masked]> wrote:
>
>>
>>
>>
>>>>
> I think there is a reasonably good understanding that for the problems (what
> aspects in the discussion here) that are being stated, (DS)MIP6 is able to
> provide a solution already. I don't think that it is a surprise to anyone.
> So the question is : Why? If the IETF already has a solution for dealing
> with inter-technology handovers, flow binding/mobility and multihoming (RFCs
> 3775/5555 and related I-Ds in MEXT WG) why do we need to develop the same
> capabilities for network based mobility protocol (RFC5213)?
>
> Quite simply, the answer is that in certain deployments it is not feasible
> to expect DS(MIP6) capability on hosts. An operator cannot expect that every
> host connecting to the network implements (DS)MIP6. The operator has no
> control of the hosts or their capabilities to a large extent. The only thing
> the operator can and does control is the network, and hence the
> consideration to add such capabilities to a deployment which used network
> based mobility protocol.
>

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)
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)
c)  that you want network layer software in the  mobile but not MIP;
(This clearly makes no sense given your "why")

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.

---

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: marcelo bagnulo braun <[email-masked]>
Date: Tue, 30 Jun 2009 18:22:43 +0200

> 1. Not every host does or will include host based mobility protocols such as
so what is the assumption requiremnent here?
Is the requriemnent that the solution must work wihtout requiring any 
host support? Or is there some level of host support that is acceptble? 
If so, why? (i mena, why some level of host support is accpetbale and 
other is not)

> mobility protocol support
right, what are the required functions that are provided by a network 
based mobility that are lacking in a host based mobility approach?

Regards, marcelo

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 30 Jun 2009 09:24:32 -0700 (PDT)

> mobility protocol support

Absolutely. These features enable many practical usecases and we should
be able to allow them in a network that has deployed only network-based
mobility management protocol, with simple clients.

Sri

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 30 Jun 2009 12:31:45 -0400

Hi George, Raj,

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

What constitutes "mobility software" without which the above features are unrealistic?

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

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

Regards,

-Rajeev

> > 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 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
> >>>>>>
> >>>>>>
> >>>>>>> talking about the *network layer*... and thus it is 
> not so clear 
> >>>>>>> how
> >>>>>>>
> >>>>>>> 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
> >>>>>>
> >>>>>>
> >>>>>>> make-before-break in certain cases. For example it is 
> possible 
> >>>>>>> to be
> >>>>>>>
> >>>>>>>>>>> My main point is make-before-break strategy is the best
> >>>>>>>>>>>
> >>>>>>>>>>>

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 30 Jun 2009 09:36:07 -0700 (PDT)

Hi Marcelo,

On Tue, 30 Jun 2009, marcelo bagnulo braun wrote:

> Is the requriemnent that the solution must work wihtout requiring any host 
> support? Or is there some level of host support that is acceptble? If so, 
> why? (i mena, why some level of host support is accpetbale and other is not)
>
>

The requirement is to have that intelligence on the network for supporting
these features, while allowing the mobile node to only express preferences
on network attachment/multihoming or flow mobility. The participation of
the client will be to minimal proportions. The goal is to have a simple
client, with a minimal software component such as for managing these
aspects and not require an extensive set of protocol stacks.

> right, what are the required functions that are provided by a network based 
> mobility that are lacking in a host based mobility approach?
>

I'm not sure, if we want to compare the missing features and say they
will be available in host mobility protocols and so we go that route.
We could have said that even before we standardized network-based
mobility approaches. But, there is interest to support network-based
mobility protocols and so we need to ensure we do that job completly.

Industry has accepted network-based mobility approaches in the form of
GTP/PMIPv6. We have to add the missing features and support that
accepted model completly. This is about completing the work.

Regards
Sri

---

From: Frank Xia <[email-masked]>
Date: Tue, 30 Jun 2009 11:38:41 -0500

Hi Marco

Could you describe the business scenarios that
only inter-handover technology can deal with?

BR
Frank

----- Original Message ----- 
From: "Marco Liebsch" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "MELIA TELEMACO" <[email-masked]>; "George Tsirtsis" 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; "mext" <[email-masked]>
Sent: Tuesday, June 30, 2009 10:37 AM
Subject: Re: [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

> Frank Xia wrote:
> 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

---

From: <[email-masked]>
Date: Tue, 30 Jun 2009 17:52:07 +0200

-Raj

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 30 Jun 2009 17:45:24 +0100

inline

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

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

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

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

> 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 [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you.
>

---

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

Hi Frank,

One possible scenario for basic inter-technology handover could be:

Move all sessions from 3G network to Wifi network to save resource on 3G.

My 2 cents.
BR,
Pierrick

> Envoyé : mardi 30 juin 2009 18:39
> À : Marco Liebsch
> Cc : MELIA TELEMACO; [email-masked]; [email-masked]
> signal
> >> De : [email-masked] [mailto:[email-masked]] De la
> part
> >> de Frank Xia
> >>>> nodes with multiple interfaces (of possible different technologies)
> in
> >>>> a
> >>>> PMIP6 network.
> >>>>

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 30 Jun 2009 18:05:17 +0100

Hey Sri,

So let me see if I understand.
You think that the MN will only have to signal during network
attachment, so, essentially out-of-band from PMIP perspective; is that
correct?
I assume by network attachment you mean on a per technology basis?
i.e., when WiFi IF attached to a given network, and when a 3G IF
attaches it signals again?

If yes, then what kind of network attachment signalling do you intend
to define in the IETF?  Could you elaborate a bit, keeping in mind
that network attachment is typically an L2 process (except PANA I
guess?)?

Also, if you only signal during attachment; does it mean that
multi-homing feature in PMIP will ONLY apply to different technologies
(i.e., you exclude multihoming on the same technology)?

Thanks

---

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

Frank,

marco

> part de Frank Xia
>>> in a

---

From: "MELIA TELEMACO" <[email-masked]>
Date: Tue, 30 Jun 2009 19:23:31 +0200

>mobility management protocol, with simple clients.

Especially considering that some Mobile Operators are not planning to
seriously deploy DSMIPv6

telemaco

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 30 Jun 2009 13:07:28 -0400

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

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

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

> >> >>>>>>> Re: [netlmm] NEXTEXT2: first draft of the bof description
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> Frank,
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> On 6/29/09 11:16
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> > 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 [email-masked] -- and destroy all 
> copies of this message and any attachments without reading or 
> disclosing their contents. Thank you.
> >
>

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 30 Jun 2009 10:33:31 -0700 (PDT)

Hi George,

> attachment, so, essentially out-of-band from PMIP perspective; is that

They can be  out-of-band from PMIP perspective, but act as triggers to
PMIP signaling.

> attaches it signals again?

Yes. When the mobile attaches to the network over a given interface,
it can identify the type of attachment (Handoff from Int-X, New
Attachment). It can be on a per-interface basis, on every attach event.

Lets take this example of host with 3G and WiFI interafaces. Possible
scenarios:

Host initially attaches over WiFI 
a.) Later brings up 3G interface for multihoming
b.) or, performs an handoff to 3G

Host attaches through 3G and Wifi interfaces and performs
an handoff from multihoming to single attach.
a.) WiFI 
b.) 3G

In all these cases, I need the host to be able to suggest the
following:

Event-1: NEW ATTACHMENT, Interface Type: WiFI, IfId: 1
Event-2: HANDOFF, FROM: 3G, IfIf:2   TO: WiFI, IfId: 1

Do I need more extensive attach preferences ?

> that network attachment is typically an L2 process (except PANA I

Its too early to discuss the semantics of the signaling. Its at a L2
layer or L3-layer ... that leads to the solution discussion. I'm sure,
we can have detailed discussions on the semantics.

> (i.e., you exclude multihoming on the same technology)?

I dont follow completly.

Between multihoming and inter-tech handoff, we need the host to be
able to specify if a given attachment is as a result of bringup of
a new interface (simultaneous attach) or a result of a handoff. The
host and the network has the complete view of the hosts attachment
over all its interfaces. So, not sure why the multihoming features
will appear only across technologies.

Regards
Sri

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 30 Jun 2009 19:50:43 +0200

Sri Gundavelli escribió:
> mobility management protocol,
define what are the features that are fundamental to network mobilit 
management that must be required to a solution

> with simple clients.

please define what do you mena by simple clients

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 30 Jun 2009 19:52:47 +0200

> 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…
pleas describe what are the characteristics of the particular deployment 
that would not allow you to use option 1
these are the required features that need to be supported that will 
justify to make the work on an altenrative option

Regards, marcelo

>>> I don't know if the above justifies the reason why we are 
>>>       
>> having this 
>>     
>>>>>>>> On 30/06/09 10:39 PM, "marcelo bagnulo braun" 
>>>>>>>>                 
>> <[email-masked]> wrote:
>>     
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> George,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> great summary
>>>>>>>>
>>>>>>>>> With PMIP things are not so clear....it is not even 
>>>>>>>>>                   
>> clear we are
>>     
>>>>>>>> combiantios or are we looking for a solution that 
>>>>>>>>                 
>> supports inter
>>     
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>> 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
>>>>>>>>>>>> As per the current PMIP6 specification wherein no 
>>>>>>>>>>>>                         
>> changes to
>>     
>>>>>>>>>>>>                         
>>>>>>>>> the host are
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>> <[email-masked]>; "Ralph Droms" 
>>>>>>>>>                   
>> <[email-masked]>
>>     
>>>>>>>>>                   
>>>>>>>>>>>>>> Sent:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>> Multihoming support. The MN with multiple interfaces 
>>>>>>>>>                   
>> of possibly
>>     
>>>>>>>>> different technologies should be able to use them 
>>>>>>>>>                   
>> simultaneously to
>>     
>>>>>>>>>>>>>>> 2) Understand the restrictions and requirement 
>>>>>>>>>>>>>>>                               
>> imposed to
>>     
>>>>>>>>>>>>>>>                               
>>>>>>>>> solutions to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 30 Jun 2009 13:36:21 -0400

Hi Marcelo,

> > 1. Not every host does or will include host based mobility protocols

> > such as (DS)MIP
> Is the requriemnent that the solution must work wihtout 
> requiring any host support? Or is there some level of host 
> support that is acceptble? 

IMO, solutions that work without any new protocol extensions at the host
should be clearly preferred - note that this allows host configuration
changes (such as configuring a virtual interface). 

We should not rule out protocol extensions, but must be "very
parsimonious". 

> If so, why? (i mena, why some level of host support is 
> accpetbale and other is not)
> 

The extension must not dictate a change in paradigm of mobility. When we
say "use MIP if you need feature X" to an operator whose network is
based on PMIP, that represents a change of paradigm. A PMIP operator who
wishes to support features should be made aware that 1) MIP may already
have the capabilities, 2) that extensions are necessary to PMIP. Beyond
that, it is up to the operator.   

> right, what are the required functions that are provided by a 
> network based mobility that are lacking in a host based 
> mobility approach?

As a starting point, the host is not involved in mobility management
(aka, managing persistence and reachability).

What we are looking at here is not to change the mobility management
model (i.e., host does not know anything about mobility at L3), but to
consider MN - Network (MAG) interactions which *may* need L3 extensions.
  
Regards,

-Rajeev

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 30 Jun 2009 11:13:19 -0700 (PDT)

Hi Marcelo,

> please define what do you mena by simple clients

Difficult question.

A simple client, not a client which takes the efforts equivalent
to designing a mother board for columbia rocket.

Quantification is difficult, its easy to argue, even though the
difference is huge, a client that only expresses attach/flow
preferences to some thing that requires MCOA/DSMIP6/MIP6 stacks,
performs tunnel management and all aspects of mobility signaling
with the home agent. But, I'm sure George can argue on this.

Regards
Sri

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 30 Jun 2009 18:09:08 +0200

> consideration to add such capabilities to a deployment which used network
so, does the requirement for the solution you are looking for is "No 
host changes"?

(i mean, if the problem is that the operator has no control of the hosts 
so it cannot require the host to support a particular appraoch, i guess 
that no host changes would be the requirement that a solution would need 
to fullfill in order to comply with what you are looking for?

Regards, marcelo

---

From: <[email-masked]>
Date: Tue, 30 Jun 2009 21:54:50 +0200

Hi Marcelo,

> so what is the assumption requiremnent here?

I think the actual requirement on the host is to be

> host support? Or is there some level of host support that is acceptble?

In order to solve the listed problems, I think there is a need to have some
level of host support. So host support is not ruled out. However it is the
degree of changes on the host which are debatable? Implementing new protocol
software on the host for example is on one extreme vs configuring the host n
certain ways being the other.

> If so, why? (i mena, why some level of host support is accpetbale and

Because of the fact that adding some level of capabilities on the host is
easier to accomplish than others.

> based mobility that are lacking in a host based mobility approach?

Well, I am not sure I understand what you are asking here.
Obviously with a network based mobility approach, there are no protocol
changes expected on the host.
But if what you are asking is the functionality that is missing in the case
of a network based mobility approach as compared to a host based solution,
then the features such as flow binding/mobility and ability to indicate
handovers from one access to another etc. are missing.

-Raj

---

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

> a)  you do not want any mobility software in the mobile? (this seems

I think this is one of the things to be investigated. Obviously we do not
intend to develop something equivalent to a MIP client which would perform
signaling with the MAG. That does not make sense. But I think there are
possibilities other than a MIP client approach which would be worthwhile to
consider. 

> IETF...but the BOF could discuss this)

One of the possibile outcomes is that in order to accomplish the stated
functionality, there is a need for certain L2 capabilities. Obviously the
IETF is not going to be able to do anything about that. But the IETF could
state that in order to support inter-technology handovers (and others) in
the context of PMIP6, certain layer 2 capabilities are expected. It is upto
SDOs and others that design and standardize L2s if these capabilities are
relevant to them. 

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

> Would you rather revise your "why" ? :-)

Not yet... But I am keeping an open mind :)

-Raj

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 01 Jul 2009 10:34:01 +1000

Hi Raj, 

I told Marcelo I'll go through the exercise from the beginning again, but I
can't help respond to this comment.

> consideration to add such capabilities to a deployment which used network

=> No one I know can get a 3G data card to access the Internet from their PC
without having to install a piece of software  on their PC to make it work.
So I think your assumption that the operator cannot mandate software on the
host is questionable, because they already do (unfortunately).

Hesham

---

From: <[email-masked]>
Date: Wed, 1 Jul 2009 05:43:40 +0200

Hi Hesham,

>host is questionable, because they already do (unfortunately).

The situation that you describe above was the same when 802.11 first rolled around as well.
You had to install a piece of software that came with the PC card. But that has changed with 
wifi now being an integral part of the notebook computers. 
And I think you could expect 3G chipsets and access built-in as well in due course of time. At least I know of a few
operators in the US (as well as notebook manufacturers) who offer such net/notebook computers,
i.e with integrated 3G access. I do not know what additional sw is loaded on these but at least the end user
is not installing anything else. 
Does it imply that such hosts will include the software that would enable host mobility? Its an open question (i.e unknown)
and will depend largely on operator choices and vendors. 

-Raj

---

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

Hi Raj, 

I had a brief offline chat with Julien and thought that I could refine my
suggestion a bit more to make the point clearer. My point is that there are
currently two slightly different points being made about the requirement on
host involvement 1) no SW on the host and the more nuanced 2) no protocol
support on the host. I won't even get into the reasons for point 2) above
and I'll let the people who raise it provide those reasons, I can't figure
out any technical reasons there.

Anyway, my point is that 1) above is not an issue today because it already
happens on a very large scale, so requiring it for a specific feature like
multihoming is hardly a leap. I can imagine ads for "download your wireless
optimiser from wwww.operator.com and save money" (ok not very creative).
The subtle difference between 1) and 2) is IMO a moot point anyway because
2) simply says that operators don't want protocol support in the network,
but that support already exists in the form of PMIP and if you have PMIP you
have MIP. So, both motivations seem to be on shaky ground.
And yes, you can of course integrate 3G modems in computers, but you can
also integrate mobility code in the same computers with the 3G support. The
SW that is provided with the modems is not only connection SW it actually
provides a number of features (e.g. Receiving SMS, account information,
email ....etc) so it's a clear move by operators to be present on those
machines. I don't think it's anything like WLAN connctions SW.

Of course it's worth mentioning that the elephant in the room is the binary
requirement on host support of protocols. We need to have a yes/no answer as
to whether there is a requirement to NOT have protocol support in the host.
At the moment this is being kept very vague.

Hesham

> Does it imply that such hosts will include the software that would enable host
> mobility? Its an open question (i.e unknown)