Subject: [netext] On the flow mobility discussion

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 14 Feb 2011 11:00:07 +0100

Hi all,

First of all, thanks for the active and lively discussion. I think that
we are slowly making some progress. For the sake of making progress, let
me try to summarize the discussion (well, actually, my view of it), pose
some questions and propose some next steps:

- Trigger for flow mobility. We have heard at least two main opinions on
this: a) triggers can only come from the MAG (based on L2 signaling from
the MN), and b) triggers can come from the MAG or from the LMA. Strong
points of a): strictly follows current RFC 5213 and allows to support
scenarios in which the MN can signal to the MAG events relevant to flow
mobility via L2-specific signaling. Here it is my first question: to me
L2 triggers and L2 signaling are not the same thing, RFC5213 requires L2
triggers to be in place (AFAIK, it can also work based on IPv6 ND, with
some assumptions on how to get the MNID and set the HI) for example to
detect when a MN has attached. However, L2 signaling between the MN and
MAG are a bit different (it implies the existence of a communication
channel for control purposes between MAG and MN that is able to convey
information relevant/relative to a L3 protocol). Do we want to restrict
the solution to the scenarios in which this L2 signaling channel is
present? To cite one example, one of the approaches that has been
proposed in the ML requires the MN to signal via L2 (over an attachment
through iface X) about events of iface Y.

Regarding b) Julien (and other folks) have asked about scenarios that
require that. I think 3G offloading is one of the scenarios that
requires that to be supported. If an operator has an MN that is attached
to WLAN and 3G simultaneously wants (because of network load conditions)
to offload some flows from 3G to WLAN on demand, I think this should be
supported, and LMA initiated flow mobility is the way to do it. Some
folks have said that the MN is the only one that knows the quality of
the signal it receives and this is mostly true (note that there are
solutions than allows the owner of the WLAN to know of the quality and
status of the network), but it is also true that in current celular
networks handovers are controlled by the network (based on signal
quality reports from the MN). To me PMIPv6 follows the same model:
network controlled __IP__ mobility.

- On the RFC5213 model and extensions to it. We can debate (as we are
doing) on the pros and cons of different technical approaches, that's
what we can do. However, I disagree with the idea that adding new
messages between LMA and MAG (if they are necessary) is fundamentally
changing the protocol and that we need to change the charter, ask the
ADs, etc. Current charter says on this regard:

"The working group will determine what protocol extensions are
required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs)
to support the ability for an interface (at the IP layer) to
transmit packets over different media, the ability to distribute
specific traffic flows on different media components of that
interface, and making this work with the handover hints in the base
protocol. The relevant protocol extensions will be developed as
necessary."

I think all technical approaches discussed so far are fine with the
above text. Even one could read that text as preventing from adding new
handover hints (which has been proposed as one of the solutions), though
that's not my reading.

- On the technical approach itself. If we forget for a second about the
LMA-triggered event, and we just think of MAG triggered ones, there have
been two fundamental approaches proposed so far. I think Tran summarized
them very well in a previous e-mail. Let me try it again for the sake of
this discussion: a) extensions to RFC5213 to support dynamically adding
and removing interfaces to mobility sessions, and b) extensions to
RFC5213 (based on standardized solutions developed in the MEXT WG) to
allow dynamic prefix management (and use that as a way to enable flow
mobility). Option a) does requires to modify conceptual data structures
defined in RFC5213 as well as state machines (to support the new
behavior). Option b) does not require modifications to the mobility
session related data structures, but on the other hand adds new ones
(related to flow bindings) and also modifies state machines. Option b)
leverages on existing MEXT work.

To me, in order to enable flow mobility in PMIPv6, there are two main
things needed (on the network side): the ability for the LMA to perform
flow routing (i.e. not just routing based on IP destination prefix) and
to allow the MAG to route prefixes that have not been delegated by the
LMA on the initial interface attachment of the MN (i.e. to support the
dynamic modification of the prefixes -- associated to a particular MN --
that the MAG is aware of). Of course, we need on the mobile side the
ability to receive and send packets simultaneously through different
physical interfaces (regardless of the IPs used). IMO, both technical
approaches a) and b) above meet the technical requirements without
posing any issue related to implementation complexity (both follows the
KISS principle) or charter compliance.

To sum up this long e-mail, I see two main issues that need to be
resolved to be able to progress:

- Trigger issue. I see the need for both LMA and MAG initiated.
Therefore I propose to work on a solution that supports BOTH. Different
people have expressed their preferences to support both and I don't see
any major issue on that. The only required change to support both is the
addition of some signaling between LMA and MAG.

- Technical approach issue (interface adding to mobility sessions vs
"flow bindings based" approach). I don't see major issues in any of
them. Current draft follows the second and I prefer to keep using it,
unless there is a clear advantage (that I don't see at this point) of
using the first.

Comments?

Thanks,

Carlos

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Mon, 14 Feb 2011 18:50:58 +0000

Hi Carlos,

Thanks for summarizing the discussion. Few points below.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Carlos Jesús Bernardos Cano
> Sent: Monday, February 14, 2011 2:00 AM
> To: [email-masked]
> Subject: [netext] On the flow mobility discussion
> 
> Hi all,
> 
> First of all, thanks for the active and lively discussion. I think that we are
> slowly making some progress. For the sake of making progress, let me try to
> summarize the discussion (well, actually, my view of it), pose some questions
> and propose some next steps:
> 
> this: a) triggers can only come from the MAG (based on L2 signaling from the
> MN), and b) triggers can come from the MAG or from the LMA. Strong points of
> a): strictly follows current RFC 5213 and allows to support scenarios in which
> the MN can signal to the MAG events relevant to flow mobility via L2-specific
> signaling. Here it is my first question: to me
> triggers to be in place (AFAIK, it can also work based on IPv6 ND, with some
> assumptions on how to get the MNID and set the HI) for example to detect when
> a MN has attached. However, L2 signaling between the MN and MAG are a bit
> different (it implies the existence of a communication channel for control
> purposes between MAG and MN that is able to convey information
> relevant/relative to a L3 protocol). Do we want to restrict the solution to
> the scenarios in which this L2 signaling channel is present? To cite one
> example, one of the approaches that has been proposed in the ML requires the
> MN to signal via L2 (over an attachment through iface X) about events of iface
> Y.
> 
> Regarding b) Julien (and other folks) have asked about scenarios that require
> that. I think 3G offloading is one of the scenarios that requires that to be
> supported. If an operator has an MN that is attached to WLAN and 3G
> simultaneously wants (because of network load conditions) to offload some
> flows from 3G to WLAN on demand, I think this should be supported, and LMA
> initiated flow mobility is the way to do it. Some folks have said that the MN
> is the only one that knows the quality of the signal it receives and this is
> mostly true (note that there are solutions than allows the owner of the WLAN
> to know of the quality and status of the network), but it is also true that in
> current celular networks handovers are controlled by the network (based on
> signal quality reports from the MN). To me PMIPv6 follows the same model:

I asked few questions in an email which I think was directed to Telemaco and others but never got a reply. The basic point is that nobody has answered how the LMA knows if the MN is still in a reasonable WLAN coverage, how loaded WLAN is, etc. There is a huge different between cellular networks and WLANs: in cellular networks the handovers are controlled by the network because the MN always provides measurement reports about what the MN sees to the network. This is not in place for inter-technology handovers between WLAN and 3G and this is why you cannot safely assume the LMA will take the correct decision. 

I don't think this approach b) brings any value and I actually think it creates a lot of problems. 

> doing) on the pros and cons of different technical approaches, that's what we
> can do. However, I disagree with the idea that adding new messages between LMA
> and MAG (if they are necessary) is fundamentally changing the protocol and
> that we need to change the charter, ask the ADs, etc. Current charter says on
> this regard:
> 
> "The working group will determine what protocol extensions are required
> between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to support the
> ability for an interface (at the IP layer) to transmit packets over different
> media, the ability to distribute specific traffic flows on different media
> components of that interface, and making this work with the handover hints in
> the base protocol. The relevant protocol extensions will be developed as
> necessary."
> 
> I think all technical approaches discussed so far are fine with the above
> text. Even one could read that text as preventing from adding new handover
> hints (which has been proposed as one of the solutions), though that's not my
> reading.
> 
> - On the technical approach itself. If we forget for a second about the LMA-
> triggered event, and we just think of MAG triggered ones, there have been two
> fundamental approaches proposed so far. I think Tran summarized them very well
> in a previous e-mail. Let me try it again for the sake of this discussion: a)
> extensions to RFC5213 to support dynamically adding and removing interfaces to
> mobility sessions, and b) extensions to
> RFC5213 (based on standardized solutions developed in the MEXT WG) to allow
> dynamic prefix management (and use that as a way to enable flow mobility).
> Option a) does requires to modify conceptual data structures defined in
> RFC5213 as well as state machines (to support the new behavior). Option b)
> does not require modifications to the mobility session related data
> structures, but on the other hand adds new ones (related to flow bindings) and
> also modifies state machines. Option b) leverages on existing MEXT work.
> 
> To me, in order to enable flow mobility in PMIPv6, there are two main things
> needed (on the network side): the ability for the LMA to perform flow routing
> (i.e. not just routing based on IP destination prefix) and to allow the MAG to
> route prefixes that have not been delegated by the LMA on the initial
> interface attachment of the MN (i.e. to support the dynamic modification of
> the prefixes -- associated to a particular MN -- that the MAG is aware of). Of
> course, we need on the mobile side the ability to receive and send packets
> simultaneously through different physical interfaces (regardless of the IPs
> used). IMO, both technical approaches a) and b) above meet the technical
> requirements without posing any issue related to implementation complexity
> (both follows the KISS principle) or charter compliance.
> 

I think comments were made that you don't need any additional prefix management for the purpose of flow mobility, in particular if you consider the MAG triggered scenarios.

> To sum up this long e-mail, I see two main issues that need to be resolved to
> be able to progress:
> 
> Therefore I propose to work on a solution that supports BOTH. 

As mentioned above, I don't see why we should support something which is based on wrong assumptions and it does not provide any benefit. Therefore I disagree to support the LMA-triggered solution. 

Thanks
Gerardo 

> Different people
> have expressed their preferences to support both and I don't see any major
> issue on that. The only required change to support both is the addition of
> some signaling between LMA and MAG.
> 
> - Technical approach issue (interface adding to mobility sessions vs "flow
> bindings based" approach). I don't see major issues in any of them. Current
> draft follows the second and I prefer to keep using it, unless there is a
> clear advantage (that I don't see at this point) of using the first.
> 
> Comments?
> 
> Thanks,
> 
> Carlos
> 
> --

---

From: Julien Laganier <[email-masked]>
Date: Mon, 14 Feb 2011 11:02:22 -0800

Hi Carlos,

I am trying to answer some of your questions inline below, but I am
afraid this comes at the cost of having to re-ask the same questions
again and again:

2011/2/14 Carlos Jesús Bernardos Cano <[email-masked]>:
> detect when a MN has attached.

Well, the L2 trigger has a cause, which is most certainly that some L2
signaling occured, or, did not occured (e.g. L2 timer goes off.) As
such, there is little sense in making distinction between the two in
the context of that discussion.

>                                          However, L2 signaling between the MN and
> present?

See my point above. When the L2 attaches (through L2 signaling, I
don't know of any wireless network attachment that happens by magic),
the MAG is triggered to attach this L2 interface to a PMIPv6 session.
So I don't know what restrictions we would be making by requiring L2
signaling / triggers. This is already there in RFC5213.

>                        To cite one example, one of the approaches that has been

The approach I've been proposing requires MN to signal via L2 iface X
that iface X be attached to a session. Nothing more, nothing less, all
of which is already required per 5213. In effect, the only added
requirement placed on L2 signaling compared to 5213 is that, in
addition the existing inter-interface handoff indicator (attach iface
X to session in lieu of iface Y), we add a new simutaneous attach
handoff indicator (that is, not really a handoff, attach iface X to
session along any existing ifaces Y, Z etc. that were already
attached.) We'd also need the ability to selectively detach an
interface and keep the other ifaces in the session attached. That
could be done through use of the same HI I just introduced, but in a
deregistration PBU.

> supported, and LMA initiated flow mobility is the way to do it.

As I've explained in other notes, there is no basis for the LMA to
unilateraly decide where to send flows. This simply doesn't work in a
variety of cases where a wireless L2 might be attached but provide no
meaningful connectivity.

>                                                                                                 Some

You cannot generalize what a cellular network does with a homogeneous
collections of radio access technologies that are all developed in the
same system, and include signaling for the terminal equipment to
report to a control network node what is the signal quality, to an IP
layer mobility management in which the radio techonologies were not
developed to fit together, and you do not have terminal to network
signaling  for radio signal quality.

Further, even if you could (but surely you can't), let me point out
that in the network controlled cellular systems that are deployed
and/or specified, the entity that takes the decision is an edge entity
(e.g. SGSN, MME) which is closer to MAG rather than a hierarchical
entity (e.g., GGSN, PGW) similar to LMA.

Thus your statement that the LMA being in control would make PMIPv6
following the same model than cellular network seems to be factually
incorrect.

> protocol. The relevant protocol extensions will be developed as

The point I have relentlessly making is that, in order to provide flow
mobility, you do NOT need to change the basics of RFC 5213 session
management, and thus, from out charter item it follows that we have
determined that this needs not to be changed, and thus you need not to
extend it.

That, is unless somebody comes up with the killer usecase, which would
have to involve more than: "I want to allocate a different prefix"
because this has nothing to do with flow mobility.

> handover hints (which has been proposed as one of the solutions), though

Truly no.

Instead of doing charter exegesis, let's have those who favor the
alternative model come up with a valid and motivated usecase....
Please....

> leverages on existing MEXT work.

Option b) is dynamic prefix management and is not necessary per se to
do flow mobility so I am starting to really wonder why we are still
discussing it in the first place.

Option a) works. Unless it is not sufficient to support a motivated
and real usecase, there is no reason for us to even discuss anything
else.

> KISS principle) or charter compliance.

a) works. b) is unecessary unless proven otherwise, which hasn't happen.

> addition of some signaling between LMA and MAG.

There is a major issue that there is no basis for an LMA to decide
where to send flows, and nobody was able to refute the argument I put
forth why this doesn't work.

So I propose we work on a solution that works, that is, MAG initiated.

> unless there is a clear advantage (that I don't see at this point) of

The clear advantage of using the first is that it supports flow
mobility. You don't need to have two ways of doing something in a
standards, unless you have to.

And you don't have to it seems, or I missed the email describing the
valid and motivated use case to do dynamic prefix management in lieu
of simple flow mobility.

If we want to move forward, we have to settle for simple single model
I've proposed, or the proponent of doing otherwise have to come up
with answers to the questions I've put forth eventually. I'll let them
choose.

--julien

---

From: <[email-masked]>
Date: Mon, 14 Feb 2011 19:09:23 +0000

Gerardo,

On 2/14/11 12:50 PM, "ext Giaretta, Gerardo" <[email-masked]> wrote:

>
>> 
>
>I asked few questions in an email which I think was directed to Telemaco
>and others but never got a reply. The basic point is that nobody has
>answered how the LMA knows if the MN is still in a reasonable WLAN
>coverage, how loaded WLAN is, etc. There is a huge different between
>cellular networks and WLANs: in cellular networks the handovers are
>controlled by the network because the MN always provides measurement
>reports about what the MN sees to the network. This is not in place for
>inter-technology handovers between WLAN and 3G and this is why you cannot
>safely assume the LMA will take the correct decision.
>

Regarding the question about whether the LMA knows the status of the MNs
connectivity to a MAG and the wifi link characteristics that it is using
to attach to a MAG:
The LMA has no awareness of the MNs connectivity/link status to a MAG. It
only knows that the MN has attached via a MAG. And if the policy indicates
that traffic be routed via that MAG/interface, it will do so.

It could result in packets being dropped if the MN has moved out of that
wifi coverage or the link is congested. In terms of the scope of this
work, the intent is on specifying how the traffic associated with a
session is switched to an alternate MAG. The points that you raise are
outside the scope of this work.

-Raj

---

From: Julien Laganier <[email-masked]>
Date: Mon, 14 Feb 2011 15:17:35 -0800

Raj,

> outside the scope of this work.

I apologize if I start to sound sarcastic, but the only thing that
seems in scope of this work is how to realize a function
(LMA-initiated  flow handoffs) that cannot be possibly used
meaningfully without a bunch of other mechanisms (MN-LMA policy
coordination, MN-LMA radio quality reporting, etc. ) that do not exist
in any form and are also out of scope of this work...

As I said, absent these mechanisms, or a usecase and proof of
feasibility, developing an LMA-initiated flow handof function makes no
sense to me.

--julien

---

From: "Stefano Faccin" <[email-masked]>
Date: Mon, 14 Feb 2011 17:25:39 -0600

Julien,
As one can imagine considering my previous comments I fully support your point below. As I indicated previously, there is in addition the fact that what is being developed will not be able to support current development scenarios, which restricts the applicability of the solution. 
Cheers,

Stefano Faccin

Standards Manager
Research In Motion Corporation 
5000 Riverside Drive 
Building 6, Brazos East, Ste. 100
Irving, Texas 75039 USA 
Office: (972) 910 3451  
Internal: 820.63451
: (510) 230 8422
www.rim.com; www.blackberry.com 

 Consider the environment before printing.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julien Laganier
Sent: Monday, February 14, 2011 3:18 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [netext] On the flow mobility discussion

Raj,

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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 15 Feb 2011 11:02:24 +1100

+1. I can't say I'm surprised we're still talking about this issue in 2011
but I think it's disappointing to see the exact same arguments being made
again and again while the proponents of this proposal keep pushing in the
same direction, while being totally indifferent to reason.

Hesham

On 15/02/11 10:25 AM, "Stefano Faccin" <[email-masked]> wrote:

> Julien,
> As one can imagine considering my previous comments I fully support your point
> below. As I indicated previously, there is in addition the fact that what is
> being developed will not be able to support current development scenarios,
> which restricts the applicability of the solution.
> Cheers,
> 
> Stefano Faccin
> 
> Standards Manager
> Julien Laganier
This
> transmission (including any attachments) may contain confidential information,
> privileged material (including material protected by the solicitor-client or
> other applicable privileges), or constitute non-public information. Any use of
> this information by anyone other than the intended recipient is prohibited. If
> you have received this transmission in error, please immediately reply to the
> sender and delete this information from your system. Use, dissemination,
> distribution, or reproduction of this transmission by unintended recipients is
> not authorized and may be unlawful.
netext mailing
> list
[email-masked]

---

From: <[email-masked]>
Date: Tue, 15 Feb 2011 00:10:07 +0000

Julien,

I understand the issue about the fact that an MN may have moved out of
wifi coverage after registering thru MAGy.
Or for that matter the wifi network via which the MN is attached (thru
MAGy) is congested or the link quality is poor.
And this could happen.

But on the flip side, the MN may be attached to a wifi network and is able
to send/recv packets thru MAGy with no issues, In which case switching the
flow at the LMA would work just fine.

Does it not make sense to have a solution for this case? The error case
when the packets sent to the MN via MAGy into oblivion cannot be ignored.
But neither can you say that there is no way this would work at all.

-Raj

---

From: "Stefano Faccin" <[email-masked]>
Date: Mon, 14 Feb 2011 18:13:18 -0600

Raj,
I apologize for being slow, but I really do not understand what you are saying. Do we really want to develop a solution that works only in the best case scenario and utterly disregards realistic scenarios like the ones Julien and others have mentioned? Is this good engineering work by IETF? What you are saying below is literally that we are OK if the solution does not work in scenario that can indeed happen and rather often already today. I cannot believe we are seriously willing to settle for that. 

Cheers,

Stefano Faccin

Standards Manager

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, February 14, 2011 4:10 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [netext] On the flow mobility discussion

Julien,

-Raj

---

From: <[email-masked]>
Date: Tue, 15 Feb 2011 00:13:51 +0000

Hi Stefano,

I think deployment scenarios could vary. Lets not consider that this
solution is applicable only in the context of 3GPP networks and
architectures. 
As an example (I am not saying that this is something other SDOs care
about. Its just an example):

Lets take the case of an MN with an EV-DO and WiMAX interface that is
attached to an LMA via MAGx and MAGy.
Could you not make a case where the flow could be switched between either
of these interfaces at the LMA?
What would be the issues in such a deployment?
Lets presume that the policies regarding which flows are routed via EV-DO
or WiMAX are configured at the LMA itself.

Cheers,
-Raj

On 2/14/11 5:25 PM, "ext Stefano Faccin" <[email-masked]> wrote:

>Julien,
>As one can imagine considering my previous comments I fully support your
>point below. As I indicated previously, there is in addition the fact
>that what is being developed will not be able to support current
>development scenarios, which restricts the applicability of the solution.
>Cheers,
>
>Stefano Faccin
>
>Standards Manager
>This transmission (including any attachments) may contain confidential
>information, privileged material (including material protected by the
>solicitor-client or other applicable privileges), or constitute
>non-public information. Any use of this information by anyone other than
>the intended recipient is prohibited. If you have received this
>transmission in error, please immediately reply to the sender and delete
>this information from your system. Use, dissemination, distribution, or
>reproduction of this transmission by unintended recipients is not
>authorized and may be unlawful.

---

From: <[email-masked]>
Date: Tue, 15 Feb 2011 00:18:34 +0000

Hi Stefano,

I am not saying that we solve the problem only for the best case scenario.
I am hoping that some of the folks who are actively involved with the
solution development can provide answers about how the concerns raised by
Julien et al. can be dealt with.
How do you handle the case when the LMA switches flows to a MAG that
cannot deliver packets reliably to the MN? Given that there is no feedback
mechanism to the LMA, there are no easy answers or mechanisms. But I want
to make sure that we get a chance to let the authors provide a response.

-Raj

On 2/14/11 6:13 PM, "ext Stefano Faccin" <[email-masked]> wrote:

>Raj,
>I apologize for being slow, but I really do not understand what you are
>saying. Do we really want to develop a solution that works only in the
>best case scenario and utterly disregards realistic scenarios like the
>ones Julien and others have mentioned? Is this good engineering work by
>IETF? What you are saying below is literally that we are OK if the
>solution does not work in scenario that can indeed happen and rather
>often already today. I cannot believe we are seriously willing to settle
>for that. 
>
>Cheers,
>
>Stefano Faccin
>
>Standards Manager

---

From: "Stefano Faccin" <[email-masked]>
Date: Mon, 14 Feb 2011 18:21:08 -0600

Raj,
As Hesham has indicated, there are several questions that have not been answered, and I have not seen anybody blocking the authors from answering those ...

Stefano Faccin

Standards Manager

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 14, 2011 4:19 PM
To: Stefano Faccin; [email-masked]
Cc: [email-masked]
Subject: Re: [netext] On the flow mobility discussion

Hi Stefano,

-Raj

---

From: "Stefano Faccin" <[email-masked]>
Date: Mon, 14 Feb 2011 18:29:25 -0600

Raj,
You raise an interesting example. Since you mention 3GPP, please note that any sort of interworking between EV-DO and WiMAX is completely out of scope of 3GPP, therefore 3GPP would not be a customer for this protocol for the scenario you mention. 

I am also wondering if anybody has indicated the deployment scenario of parallel EV-DO and WiMAX as one of interest. 

As for other deployment scenarios, you are correct, but I believe that the issues raised applied as well to other deployments since they are completely independent of the decisions 3GPP has taken. The issues exist anyway.

Cheers,

Stefano Faccin

Standards Manager

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 14, 2011 4:14 PM
To: Stefano Faccin; [email-masked]
Cc: [email-masked]
Subject: Re: [netext] On the flow mobility discussion

Hi Stefano,

Cheers,
-Raj

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 15 Feb 2011 01:41:03 +0100

Hi Julien

Thanks for your reply. Some comments below.

> the context of that discussion.

To me an L2 trigger at the MAG that says "an interface has attached"
based on L2 messages that are there regardless of whether PMIPv6 is
being used or not is actually very different from L2 signalling from the
MN conveying the message "I want this interface added to this PMIPv6
mobility session". I must be missign something, cause I see huge
differences there.

> signaling / triggers. This is already there in RFC5213.

True, that L2 signal triggers to add this interface to a new PMIPv6
session (or to a existing one for the case of handover). Here you are
proposing a new hint based on L2 indications for flow mobility purposes,
right?

> of which is already required per 5213. In effect, the only added

Well, you are requiring that an interface that is already attached has
to generate L2 signaling (that otherwise would not be generated) to
support the flow mobility scenario. I see that as posing new
requirements to a scenario that not require that.

> could be done through use of the same HI I just introduced, but in a

Sure if we can put all that semantics on the L2 signaling, MAG triggered
flow mobility can be supported (as well as with the "flow bindings"
based approach that we describe in our draft) . LMA triggered remains to
be the issue.

> variety of cases where a wireless L2 might be attached but provide no

Even in your approach, the LMA would be the one deciding where to send
flows, right? a mobility session would have different interfaces
attached, and the LMA would always be the one deciding through which MAG
(i.e. through which MN interface) the traffic will be delivered.

> signaling  for radio signal quality.

To me generalizing that is as generalizing the existence of L2 signaling
that does all what is missing to support flow mobility.

> determined that this needs not to be changed, and thus you need not to

My point is that we don't change the basics of RFC 5213 session
management. Actually we don't introduce any change, but we just put the
flow bindings support on top to be able to route flows.

> because this has nothing to do with flow mobility.

Sorry, but I see both approaches equivalent.

> alternative model come up with a valid and motivated usecase....

This only applies to the need of the LMA triggered scenario, not on the
technical approach itself. Both yours and the one included in our draft
provides the same functionality.

> discussing it in the first place.

Why do you call it prefix management? I call it flow bindings over RFC
5213 mobility sessions.

> and real usecase, there is no reason for us to even discuss anything

Why? I can say the same for your solution.

> forth why this doesn't work.

But this applies to any solution, right? The LMA is always the entity
that has to decide to which MAG it should send the traffic.

Kind Regards,

Carlos

---

From: "Youn-Hee Han" <[email-masked]>
Date: Tue, 15 Feb 2011 10:38:04 +0900

Hi Julien and Stefano,

> > requires that to be supported. If an operator has an MN that is
> > attached to WLAN and 3G simultaneously wants (because of network load
> > conditions) to offload some flows from 3G to WLAN on demand, I think
> > this should be supported, and LMA initiated flow mobility is the way
> to do it.
> 
> > Some folks have said that the MN is the only one that knows the
> > quality of the signal it receives and this is mostly true (note that
> > there are solutions than allows the owner of the WLAN to know of the
> > quality and status of the network), but it is also true that in
> > current celular networks handovers are controlled by the network
> > (based on signal quality reports from the MN). To me PMIPv6 follows
> the same model:
> same system, and include signaling for the terminal equipment to report
> to a control network node what is the signal quality, to an IP layer
> mobility management in which the radio techonologies were not developed
> to fit together, and you do not have terminal to network signaling  for
> radio signal quality.
> 
> Further, even if you could (but surely you can't), let me point out that
> in the network controlled cellular systems that are deployed and/or
> specified, the entity that takes the decision is an edge entity (e.g.
> SGSN, MME) which is closer to MAG rather than a hierarchical entity
> (e.g., GGSN, PGW) similar to LMA.
> 

The procedural sequence of two initiation ways seems to be as follows: 1)
MAG/MN initiation: L2 trigger to MAG -> MAG sends PBU to LMA -> LMA
redistribute flows, 2) LMA initiation: L2 trigger to SGSN/MME -> SGSN/MME
sends a signaling to LMA -> LMA redistribute flows. Based on such procedural
sequence, I am not able to find any technical reason that rejects one way,
while accepting the other way. Of course, the signaling between SGSN/MME and
LMA is implementation-specific and out of scope. However, if operators
install PMIPv6 function in their networks, they know well that LMA is the
topological anchor (i.e., all traffic pass through the LMA), and thus they
will consent to implement such signaling to support flow mobility. 

There is another scenario to go well with LMA initiation. It can be setup
with a policy provisioning based on a kind of contract formed between a
mobile client and operator. We don't need to stand firmly by that a policy
will be made only based on L2 triggers. We can expect that a policy will be
made based on many reasons, such as spatial, temporal, environmental, or
even social events. Should do we restrict such various events to be brought
by MN or L2 trigger between MN and MAG? I think that a network-controlled
flow mobility should allow them to directly stimulate the LMA to
redistribute flows across MAGs/interfaces. 

Youn-Hee

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 15 Feb 2011 14:13:52 +1100

Hi Raj, 

The questions are not left unanswered due to lack of enthusiasm; if anything
there is too much enthusiasm here. They're not being answered because there
are no good answers to the issues raised. We've seen this discussion before
more than once, there is _nothing_ new being discussed. The basic concept of
doing flow mobility based only on network entities' knowledge is broken and
will not be used in today's networks.

But lets continue talking about it....

Hesham

netext mailing
[email-masked]

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 15 Feb 2011 14:17:51 +1100

> Does it not make sense to have a solution for this case?

=> No it doesn't make sense. Because those cases are not deployment
scenarios, they're runtime changes within any deployment. This would be a
solution that "may" work. In other words a useless solution.

Hesham

The error case
This
netext mailing
[email-masked]

---

From: [email-masked]
Date: Tue, 15 Feb 2011 15:49:53 +0800

Hi,
IMHO, initiating flow mobility by either terminal side or network side 
itself is a kind of helpless choice. People surely want stable flows other 
than "flexible" flows. So in most cases, we use flow mobility only when we 
have to do.
In case of host-based flow mobility, terminal decides to move specific 
flows due to e.g. out of the wifi coverage by sending BU to notify the 
network. However, the network will reject this request if network does not 
support transporting this flow through other accesses.  Then, the flow 
will be killed. It is not a terrible thing if a flow can not survive the 
same in network-based scenario. I believe it does make sense to study on 
LMA-initiated flow mobility although the flow may be dead due to e.g. MN 
out of the targer access. Anyway, no solution is perfect.
I disagree the thoughts about no basis existing for the LMA to unilateraly 
decide where to send flows. LMA is usually connected with network 
management system such as traffic monitoring deployed in the operator's 
internal network. When serious congestion occurs in some access system, 
the LMA is reported  this info by monitoring system. Then, it is LMA to 
decide which flows should be moved from the congested system. After all 
the LMA knows that which MNs connecting multiple MAGs simultaneously and 
can make flow policies according to current situation. If the packet 
belonging to the moved flow dropped by the target MAG, what we can do is 
just let it go cause the network has done its best to avoid bad user 
experience. Morever, before deciding the flow routing to which MAG, a 
health status check  between terminal and LMA can be performed which is 
implementation dependent. Policy Basis for LMA needs to be further studied 
and should  not be specified in this draft.

Regards,
Joy

Hesham Soliman <[email-masked]> 
发件人:  [email-masked]
2011-02-15 上午 11:17

收件人
Stefano Faccin <[email-masked]>, <[email-masked]>, 
<[email-masked]>
抄送
[email-masked]
主题
Re: [netext] On the flow mobility discussion

Hesham

The error case
>>>> I don't think this approach b) brings any value and I actually think 
it
>>>> creates a lot of problems.
>>> 
>>> 
This
netext mailing
[email-masked]

---

From: Julien Laganier <[email-masked]>
Date: Tue, 15 Feb 2011 11:01:01 -0800

Raj,

> But neither can you say that there is no way this would work at all.

The IETF designs protocol that have to be robust in the Internet,
which is in line with your statement that the error case cannot be
ignored. Thus unless someone comes up with appropriate handling to
recover from the error case, we do not have a robust protocol / the
protocol doesn't work (robustly) in the Internet.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Tue, 15 Feb 2011 11:06:09 -0800

Hi Raj,

I do not see how the specific case of EV-DO/WiMAX flow mobility
changes anything to the fact that unless the LMA has knowledge on both
these radio links quality and a way to compare them (which it has
not), the LMA has no basis to decide to move flows based solely on the
terminal being attached to both these technologies. I have certainly
be attached to cellular packet radio network that gave me abysmal data
rates. I am glad there were no LMA to force me to use those.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Tue, 15 Feb 2011 11:29:35 -0800

Hi Carlos,

Please see follow-up below:

> mobility session". I must be missign something, cause I see huge

If you actually look at the system level specification that uses
PMIPv6 to do inter-technology handovers, this is exactly what they
have, a L2 signaling from the MN that conveys the message "I want this
interface to replace the old one in this PMIPv6 mobility session",
which triggers the MAG to set the Handoff Indicator to "Handoff
Between Interfaces" in the PBU it sends. If the L2 signaling is a
simple attach and doesn't embed the MN intent to handoff between
interfaces, i.e., the MN is legacy IP host, then the MAG does set the
handoff indicator to this value and this result to a default of
creating a new PMIPv6 session for that interface.

Thus in terms of flow mobility, what we need to do is rely on an
extended L2 signaling from the MN that conveys the information that
the MN does support flow mobility across interfaces, as you put it: "I
want this interface added to this PMIPv6 mobility session".

This is pretty much inline with what's been already.

Yes, it does mean that in order to do inter-tech handoffs and/or flow
mobility, you do need extensions to the L2 signaling. Nothing new
here...

> proposing a new hint based on L2 indications for flow mobility purposes,

I am proposing that we rely on what has to be done anyway for this to
work (and has been done already for inter-tech handoffs), i.e.,
extensions of the L2 signalings to convey the MN intent (inter-tech
handoff, or simultaneous attach for flow mobility.)

> requirements to a scenario that not require that.

See my earlier points - this already has to be generated for
inter-tech handoffs. It is required already. You cannot build a
working system without these L2 signals from a MN with unmodified IP
layer.

> based approach that we describe in our draft) . LMA triggered remains to

As I'm explaining in couple of other notes, LMA triggered makes no
sense without mechanisms in place for the LMA to know the quality of
the various radio links the MN has. These mechanisms do not exist and
it is dubious that they will ever (because mobile networks are not
architect'ed in such a way.)

> (i.e. through which MN interface) the traffic will be delivered.

I don't think the LMA is in a position to decide where to send flow,
hence my statement that LMA-triggered isn't useful. I've given
arguments that substantiate this claims, none of which has been
rebutted so far.

> that does all what is missing to support flow mobility.

Except that you have no other choice than to suppose that the L2
signaling for adding/removing interfaces to session is in place.
Otherwise an unmodified IP layer on the MN will not work. The
signaling has to occur somewhere, if not at L3, then it has to be L2.
(I take if for granted that nobody on this list wants to have that
signaling at L4-7 ;-)

> flow bindings support on top to be able to route flows.

You change it with the ability for LMA to add/remove interfaces and
prefixes to sessions, which isn't in 5213. 5213 is entirely MAG
driven, except for purposes of revocation but that is an entirely
different matter.

> Sorry, but I see both approaches equivalent.

They are not.

The approach you're defending requires changes to the 5213 model to
support a useless LMA-tirggered flow mobility usecase.

My approach retains the original MAG-driven by L2 triggers approach
documented in 5213, and specified in various systems (e.g. 3GPP), and
supports the practical usecases.

> provides the same functionality.

So once again:
1) LMA triggered scenario has no real world applicability
2) my approach supports real world usecases. The one is the draft is
only required to support the imaginary LMA usecase.

> Why do you call it prefix management? I call it flow bindings over RFC

You can call it what you want. The fact is that, if we can agree that
there's no need to support LMA triggered flow movements, the only
incremental feature option b) has compared to option a) is that you
can add and remove prefixes to sessions, which seems to be exactly
dynamic prefix management...

But I don't care much about terminology. I care about meaningful
functions that supports real world usecases. Protocols are complex
enough without packing features that are unusable in practice.

> Why? I can say the same for your solution.

My solution has the minimum feature set required to support flow
mobility in real-world usecases, i.e. MAG driven based on L2 triggers.

Your solution has more feature (dynamic prefix management,
LMA-triggered flow movement) that applies to imaginary usecases (e.g.,
one in which a LMA in a core network somewhere knows how good or bad a
radio link is...)

> that has to decide to which MAG it should send the traffic.

My solution doesn't have added complexity to support a usecase that
does not happen in practice, i.e., the LMA knowing where to sends
flows.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Tue, 15 Feb 2011 11:39:43 -0800

Youn-Hee,

On Mon, Feb 14, 2011 at 5:38 PM, Youn-Hee Han <[email-masked]> wrote:
> sends a signaling to LMA -> LMA redistribute flows.

I don't see how your #2 above is possibly a case of LMA initiation as
it starts with a L2 trigger... Surely the LMA isn't terminating the L2
where this trigger occur....

>                                                                             Based on such procedural
> LMA is implementation-specific and out of scope.

I think I'm reaching the point where an indigestion of
out-of-scope-ness prevents meaningful technical discussions. Are you
saying that the LMA will have interfaces through which it can learn of
the link condition of each MN's radio access?

>                                                                                 However, if operators

I'd rather have operator express their consent than making prediction
on what they will consent if ...

> redistribute flows across MAGs/interfaces.

See my point above. I do not think it is realistic that the LMA is
aware of radio conditions for each interface of each MN it serving.
Corollary: there is a reason the radio access network is separate from
the core network in real systems...

--julien

---

From: Julien Laganier <[email-masked]>
Date: Tue, 15 Feb 2011 11:41:49 -0800

> solution that "may" work. In other words a useless solution.

With the full force of rhetoric: +1

--julien

---

From: "Youn-Hee Han" <[email-masked]>
Date: Wed, 16 Feb 2011 10:28:34 +0900

Julien,

Before seeing in-lined texts, please consider my point. Basically, I don't
think that the flow redistribution can start only based on L2 status (e.g.,
radio condition) change. Yes, the L2 status change is the most major source
to initiate flow redistribution, and thus, MAG/MN initiation way is
definitely needed. However, I don't agree that it is the only source. I
believe the followings can be the source: user's geographical location,
temporal events, financial (accounting) reason, etc. That is, we can build
many scenarios where flows can move across 3G and WLAN, even though both
interfaces (3G and WLAN) of a phone are connected in very stable manner and
their radio strength are enough good. Network can collect information about
such various sources, and decide where should a flow be delivered. 

> >> > Regarding b) Julien (and other folks) have asked about scenarios
> >> > that require that. I think 3G offloading is one of the scenarios
> >> > that requires that to be supported. If an operator has an MN that
> >> > is attached to WLAN and 3G simultaneously wants (because of network
> >> > load
> >> > conditions) to offload some flows from 3G to WLAN on demand, I
> >> > think this should be supported, and LMA initiated flow mobility is
> >> > the way
> >> to do it.
> >>
> >> > quality of the signal it receives and this is mostly true (note
> >> > that there are solutions than allows the owner of the WLAN to know
> >> > of the quality and status of the network), but it is also true that
> >> > in current celular networks handovers are controlled by the network
> >> collections of radio access technologies that are all developed in
> >> the same system, and include signaling for the terminal equipment to
> >> and/or specified, the entity that takes the decision is an edge
> entity (e.g.
> > The procedural sequence of two initiation ways seems to be as follows:
> > 1) MAG/MN initiation: L2 trigger to MAG -> MAG sends PBU to LMA -> LMA
> > redistribute flows, 2) LMA initiation: L2 trigger to SGSN/MME ->
> > SGSN/MME sends a signaling to LMA -> LMA redistribute flows.
> 
> I don't see how your #2 above is possibly a case of LMA initiation as it
> starts with a L2 trigger... Surely the LMA isn't terminating the L2
> > Based on such procedural sequence, I am not able to find any technical
> > reason that rejects one way, while accepting the other way. Of course,
> > the signaling between SGSN/MME and LMA is implementation-specific and
> out of scope.
> 
> I think I'm reaching the point where an indigestion of out-of-scope-ness
> prevents meaningful technical discussions. Are you saying that the LMA
> will have interfaces through which it can learn of the link condition of
> each MN's radio access?
> 

It is implementation-specific. That's all. 

Many technical discussion has been done based on reasonable assumption. As
you know well, RFC5213 was also made by a reasonable assumption that MAG can
know the status of MN handover and insert a proper HI value to PBU message.
How to get such handover status is also out-of-scope. 

> >
> > However, if operators install PMIPv6 function in their networks, they
> > know well that LMA is the topological anchor (i.e., all traffic pass
> > through the LMA), and thus they will consent to implement such
> signaling to support flow mobility.
> 
> I'd rather have operator express their consent than making prediction on
> what they will consent if ...
> 
> > There is another scenario to go well with LMA initiation. It can be
> > setup with a policy provisioning based on a kind of contract formed
> > between a mobile client and operator. We don't need to stand firmly by
> > that a policy will be made only based on L2 triggers. We can expect
> > that a policy will be made based on many reasons, such as spatial,
> > temporal, environmental, or even social events. Should do we restrict
> > such various events to be brought by MN or L2 trigger between MN and
> > MAG? I think that a network-controlled flow mobility should allow them
> > to directly stimulate the LMA to redistribute flows across
> MAGs/interfaces.
> 
> See my point above. I do not think it is realistic that the LMA is aware
> of radio conditions for each interface of each MN it serving.

The radio condition was not what I mentioned. Except radio condition, many
sources can stimulate flow redistribution, and network-side is better to
track such sources.

Youn-Hee

---

From: Julien Laganier <[email-masked]>
Date: Tue, 15 Feb 2011 18:04:45 -0800

Youn-Hee,

> such various sources, and decide where should a flow be delivered.

IMHO this is theoretical and does no fly in practice. See below -

> How to get such handover status is also out-of-scope.

Functionally speaking, the LMA being aware of radio conditions at the
MN is neither practical neither a reasonable assumption.

It is also not implementation specific as this is an external
interface between network nodes (LMA and MN), for which we have no
existing protocols.

Finally, note that there are no interfaces between an MME and a LMA in
real systems. The MME is interfaced to the MAG. The MAG is interfaced
to the LMA.

> sources can stimulate flow redistribution, and network-side is better to

Can we agree that, flow mobility or not, client-based or network
based, what ultimately primes is that the MN has actual connectivity?

If yes, given that connectivity is contingent of good radio
conditions, the entity that triggers flow mobility has to be aware of
connectivity and thus of radio conditions.

That is the case for the MN, and that is not the case for the LMA
unless the LMA is made aware of how good or bad radio links are which
I do not believe is a reasonable assumption.

--julien

---

From: Tran Minh Trung <[email-masked]>
Date: Thu, 17 Feb 2011 09:46:55 +0900

Hi Julien and all,

Actually the argument that "the LMA is not aware of MN's radio links then it
can send data to the black-hole" dose not work with me :-).
Is MAG aware of the MN's radio links status and inform it to the LMA?. The
only question here is how fast the MAG can update MN's link status to the
LMA.

It is two sizes of a coin!. We also can argue that the MN is not aware of
the network status (or network policy in some cases) so it can send data to
a congested road of forbidden road (kind of black-holes ^^) as well. And
also one question here is how fast the MN can keep update with Network
Status (or policy - can be a rarely case)?.

For me the only reason that  we do not need signaling message from the LMA
to the MAG is that we can setup the environment for flow mobility in
advance, relying on the L2 attachment/detachment event of the interfaces.

There are three cases can be occurred when the MN attach an interface to the
network as following:

MN attaches an interface IF-N to MAG-N:
Case 1: L2 informs MAG-N that it is a New attachment -> Create new Session
 (RFC5312)
Case 2: L2 informs MAG-N that it is a Hand-Off Attachment -> replace IF in
the existing session by IF-N.  (RFC5213)
Case 3: L2 informs MAG-N that it is a Simultaneous attachment (that can
support flow mobility)-> Add interface to existing sessions of the
interfaces in the same set.  (Extension for flow mobility)

The case 3 can always help us to setup the environment for flow mobility in
advance. After that the LMA can decide to move flow at anytime without any
extra signaling message.

That's all, we may not need more complicated protocol.

I understand the arguments from Rajeev, Carlos, Telemaco, and Youn that we
need to support different user cases as well as allowing LMA to send FMI to
MAG. However, up to now I did not see any reasonable reason during this
discussion. If we can not show out real cases and convince people that they
are necessary then I would suggest to skip these parts from baseline
document.

I am on checking carefully some real cases that may require signaling
message from LMA to MAG.
Two of them can be listed here is (1) Multiple PDP Contexts in UTMS system
(2) Creating a new VPN connection.
It needs more time to have final answer exactly.

Regards,
TrungTM

---

From: <[email-masked]>
Date: Wed, 16 Feb 2011 11:34:43 +0100

Hi,

Just a question for clarification... Could we say that if the MN attaches a new physical interface (i.e. the MN makes decision to use it), the LMA can consider this interface as valid candidate for IP flow mobility . In other words, can we consider that adding/removing interface to the session is a way to make the LMA aware about MN decision? The LMA is still the entity making the final decision (it should not be the only use-case, but can be the first...) but the LMA trusts MN's decision and is not required to compute MN's measurement.

BTW, I agree the LMA should not be provisioned with MN's radio measurements, or other local information; in the same way the MN should not be provisioned with information on accesses network load. It is generally preferable to share decision between entities rather than exchanging info. But it's another debate and application to PMIP architecture is not so obvious...

Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part
> de Julien Laganier
> Envoyé : mercredi 16 février 2011 03:05
> À : Youn-Hee Han
> Cc : [email-masked]
> Objet : Re: [netext] On the flow mobility discussion
> 
> Youn-Hee,
> 
> aware

---

From: Julien Laganier <[email-masked]>
Date: Thu, 17 Feb 2011 10:41:43 -0800

Hi Pierrick,

> Just a question for clarification... Could we say that if the MN attaches a new physical interface (i.e. the MN makes decision to use it), the LMA can consider this interface as valid candidate for…

I don't think that would fly: if I follow your line of thought it
could be that the interface doesn't provide meaningful connectivity to
the Internet but the MN doesn't know yet because it's not attached, MN
attaches it, then the LMA decides to route flows there but they're not
making it to the MN...

Given the time constant with which radio conditions varies, I think
the MN should be the one making the final decision.

> BTW, I agree the LMA should not be provisioned with MN's radio measurements, or other local information; in the same way the MN should not be provisioned with information on accesses network load.…

I am confused by this statement. If no information is ever exchanged
and decision is shared, wouldn't that lead to contradictory decisions
being taken by MN and NW side?

--julien

---

From: "Stefano Faccin" <[email-masked]>
Date: Thu, 17 Feb 2011 13:18:14 -0600

Julien, Pierrick,
I have to agree with Julien on the MN still and always being the best entity capable of making such decision. Based on device experience, in most cases the MN is the sole entity that can make an educated decision and avoid conflicts with the network. That's the main reason why, in 3GPP, for the interworking between cellular links and other non-cellular technologies, it has been left to the MN to device which access to connect to and when (though operators can control that through policy provisioning).

Cheers,
Stefano Faccin

Standards Manager

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julien Laganier
Sent: Thursday, February 17, 2011 10:42 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [netext] On the flow mobility discussion

Hi Pierrick,

--julien

---

From: Tran Minh Trung <[email-masked]>
Date: Fri, 18 Feb 2011 18:28:00 +0900

Hi Julien and Pierrick,

On Fri, Feb 18, 2011 at 3:41 AM, Julien Laganier <[email-masked]>wrote:

> > Just a question for clarification... Could we say that if the MN attaches
> a new physical interface (i.e. the MN makes decision to use it), the LMA can
> consider this interface as valid candidate for IP flow mobility . In other
> words, can we consider that adding/removing interface to the session is a
> way to make the LMA aware about MN decision? The LMA is still the entity
> making the final decision (it should not be the only use-case, but can be
> the first...) but the LMA trusts MN's decision and is not required to
> compute MN's measurement.
>

Dou you mean that the flow mobility decision?
If yes, then I disagree.

The MN just decides which interface can be used to attach to the network
basing on the availablity of access points (MAGs).
L2 trigger just helps the network to setup session to support flow mobility
(eg. add interface in the set to the same session).
L2 trigger can not be used to trigger the network to move flow.

Since we are proposing network-based flow mobility, the network (LMA) is the
one who decides to move a flow basing on the *network policy* and the
*available
attahcments* of the MN. The MN just follows the network's policy to send
uplink traffic.

Regards,
TrungTM

>
> > BTW, I agree the LMA should not be provisioned with MN's radio
> measurements, or other local information; in the same way the MN should not
> be provisioned with information on accesses network load. It is generally
> preferable to share decision between entities rather than exchanging info.
> But it's another debate and application to PMIP architecture is not so
> obvious...
>

-- 
Ph.D., Senior Member
Electronics and Telecommunications Research Institute
Standards Research Center
161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA
Tel : +82-42-860-1132,   Fax : +82-42-861-5404

---

From: <[email-masked]>
Date: Fri, 18 Feb 2011 10:34:26 +0100

Hi,

Just some thoughts inline....

> De : Julien Laganier [mailto:[email-masked]]
> Envoyé : jeudi 17 février 2011 19:42
> À : SEITE Pierrick RD-RESA-REN
> Cc : [email-masked]; [email-masked]
> > Just a question for clarification... Could we say that if the MN
> attaches a new physical interface (i.e. the MN makes decision to use it),
> the LMA can consider this interface as valid candidate for IP flow
> mobility . In other words, can we consider that adding/removing interface
> to the session is a way to make the LMA aware about MN decision? The LMA
> is still the entity making the final decision (it should not be the only
> use-case, but can be the first...) but the LMA trusts MN's decision and is
> not required to compute MN's measurement.
> 

Ok, I see. But, we could assume that the MN implements a connection manager (it seems a reasonable for a multiple interfaces). One of the function of the connection manager could be the "IP connectivity check". The idea is that this connection manager function could guarantee that the MN attaches to an interface with good radio condition. The only thing that the connection manager cannot take into account is accesses network load, but it's typically the role of the network to monitor accesses load and trigger mobility via the LMA.

> measurements, or other local information; in the same way the MN should
> not be provisioned with information on accesses network load. It is
> generally preferable to share decision between entities rather than
> exchanging info. But it's another debate and application to PMIP
> architecture is not so obvious...
> 

Actually, I meant that we avoid exchanging brute measurement between entities. But, of course, decision entities exchange information. This information can be partial decision (e.g. we have a decision architecture where different decision makers calculate, upon their local information, a score per access; then these scores are exchanged and compute by the entity making the final decision) or updated policies. Then the question is "where to put the final decision?". As Stefano pointed out, the MN used to make the final decision, and it's reasonable. Actually,  the only real added-value for network assisted decision (I'm not saying network enforced :-)) is on access overloaded condition. Network assistance avoids that the MN attach to an access network that cannot provide "good"  connectivity. Now, I don't know if, in the PMIP context, we should require to stick to this model and close the door to other decision model. 

Sorry for digressing on the decision model in the netext ML, but I think it was worth to be clarified.

---

From: Tran Minh Trung <[email-masked]>
Date: Fri, 18 Feb 2011 18:39:51 +0900

Hi Stefano,

On Fri, Feb 18, 2011 at 4:18 AM, Stefano Faccin <[email-masked]> wrote:

> Julien, Pierrick,
> I have to agree with Julien on the MN still and always being the best
> entity capable of making such decision. Based on device experience, in most
> cases the MN is the sole entity that can make an educated decision and avoid
> conflicts with the network. That's the main reason why, in 3GPP, for the
> interworking between cellular links and other non-cellular technologies, it
> has been left to the MN to device which access to connect to and when
> (though operators can control that through policy provisioning).
>

Ofcouse the MN has its right to decide which interface can be used to attach
to the network.
But the MN dose not have full right (or information) to send a flow via an
attachment.

For example in the pass, AT&T did not allow VoIP over 3G then MN can not
make VoIP call over 3G attachment.
Is that right?

In addition, to send downlink traffic, the LMA should check the available of
the MN's attachments first, then check the network policy to decide which
attachment that downlink traffic will be sent to.

The LMA sending downlink traffic to blackhole or not is totaly depend on
the information that is updated from MAG.
If the MAG can not update exatcly the attachment status of the MN then we
have no way to help the LMA not to send data to blackhole!

Could you show out another way?

Regards,
TrungTM

> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from your
> system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.