Subject: [netext] Policy assumptions in draft-bernardos-netext-pmipv6-flowmob

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 9 Feb 2011 06:36:45 +0000

I want to go back to the point raised by Stefano which was somehow lost in the long thread.

I need some clarifications on which is the assumption in terms of policies in the draft. In particular:

- Is it correct that there is an assumption that MN and LMA have the same policies and behave accordingly? 

- Does the MN need to have knowledge of the policy at all? 

Thanks
Gerardo

---

From: Tran Minh Trung <[email-masked]>
Date: Wed, 9 Feb 2011 17:31:15 +0900

> - Is it correct that there is an assumption that MN and LMA have the same policies and behave accordingly?

Yes, they should have the same policies.

> - Does the MN need to have knowledge of the policy at all?

Yes, it needs to have knowledge of the policy.
It is necessary for the MN to send the packet of a NEW flow (not
ongoing flow) to the right interface.

Regards,
TrungTM

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

-- 
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: Wed, 9 Feb 2011 09:56:09 +0100

I think a pragmatic and basic behaviour could be defined in a first round. I'd suggest the following: The LMA enforces its decision to the MN, which is just expected to mirror LMA routing decision, i.e. the MN sends a packet on the same interface it receives the packet. However, The MN needs to have a default policy to select the interface when initiating a flow. If the MN's policy does not match the LMA policy, the LMA trigger flow handover and the MN follows that decision.

Obviously, more sophisticated policies models could be defined. But, even if not optimal, this model is quite simple and does not require to synchronize policies.

BR,
Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part
> de Giaretta, Gerardo
> Envoyé : mercredi 9 février 2011 07:37
> À : [email-masked]
> Objet : [netext] Policy assumptions in draft-bernardos-netext-pmipv6-
> flowmob
>

---

From: Tran Minh Trung <[email-masked]>
Date: Wed, 9 Feb 2011 18:02:03 +0900

Hi Pierrick,

> I think a pragmatic and basic behaviour could be defined in a first round. I'd suggest the following: The LMA enforces its decision to the MN, which is just expected to mirror LMA routing decision,…

It is exactly what we have in the logical interface I-D as well as
Bernardos' I-D.

Regards,
TrungTM

---

From: "Youn-Hee Han" <[email-masked]>
Date: Wed, 9 Feb 2011 20:19:40 +0900

Hi all,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Wednesday, February 09, 2011 5:56 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [netext] Policy assumptions in draft-bernardos-netext-
> pmipv6-flowmob
> 
> 
> I think a pragmatic and basic behaviour could be defined in a first
> round. I'd suggest the following: The LMA enforces its decision to the
> MN, which is just expected to mirror LMA routing decision, i.e. the MN
> sends a packet on the same interface it receives the packet. However,
> The MN needs to have a default policy to select the interface when
> initiating a flow. If the MN's policy does not match the LMA policy, the
> LMA trigger flow handover and the MN follows that decision.

I second this statement.
 
> Obviously, more sophisticated policies models could be defined. 

I also agree it. Additionally, we need to discuss what component can manage
the network-side policy. MAG, LMA, or Both?

Youn-Hee

---

From: "Stefano Faccin" <[email-masked]>
Date: Wed, 9 Feb 2011 11:24:35 -0600

Gentlemen,
A question for clarification. How does a MN that supports both this solution and the current state of the art behave when roaming between networks that support different solutions? How doe sthe MN know what it should do?

Also, let's consider the roaming case. I guess a subscriber of operator A is paying for a certain service from operator A and expects a certain consistency in the service it is receiving. If now policies for the control of the IP flow mobility resides in the LMA, and if the MN is roaming, and if the MN wants local connectivity (i.e. without the need to go back to the home operator core network), then a local LMA is needed. This implies that the LMA of the visited operator needs to be provided with the correct policies by the home operator. Now, I already find it hard to believe that the LMAs in the home network can be provided with the correct and up to speed per-subscriber policies to provide the expected service to the MN. But, if LMAs in the visited operator needs to be provided the same, then I see a scalability issue and for the solution to work we need to make rather large system-level assumptions. I believe it is essential that the solution can work both for MNs connected to their home networks and roaming MNs. In the host-based model, since the decision are made in the MN based on policies that can be provisioned/controlled by the home operator, the MN can make the appropriate decisions on how to route traffic both if the MN is in the home network and if it is in the visited network. I believe we need to match the same ability in a scalable way.

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 Youn-Hee Han
Sent: Wednesday, February 09, 2011 3:20 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [netext] Policy assumptionsin draft-bernardos-netext-pmipv6-flowmob

Hi all,

I second this statement.

Youn-Hee

---------------------------------------------------------------------
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: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 9 Feb 2011 22:27:00 +0000

Hello,

> From: Tran Minh Trung [mailto:[email-masked]]
> Sent: Wednesday, February 09, 2011 12:31 AM
> To: Giaretta, Gerardo
> Cc: [email-masked]

Then, the scenario of change of policy in the LMA is conflicting with this assumption unless policies changed also on MN.

Gerardo

---

From: [email-masked]
Date: Fri, 11 Feb 2011 09:26:29 +0800

Hello,

[email-masked] 写于 2011-02-10 上午 06:27:00:

> Then, the scenario of change of policy in the LMA is conflicting 
> with this assumption unless policies changed also on MN.
> 
As mentioned by Pierrick, a pragmatic and basic way on policy can be 
appplied on MN in first round. For current flow, the MN should follow the 
LMA's change of traffic routing. And the MN initates any flow according to 
the default policy configuration. No dynamic policy maintenance is needed 
on MN.

Regards,

Joy Zhou
ZTE Corporation

---

From: Tran Minh Trung <[email-masked]>
Date: Fri, 11 Feb 2011 17:40:09 +0900

Hi Joy Zhou,

[Snip.]
> the default policy configuration. No dynamic policy maintenance is needed on
> MN.
>

If the network blocks some service on default interface then how MN
will do. Just try and try again on default interface?

For a real example: AT&T (in the past) or KT network blocks VoIP over
3G. Then how can you do if the default interface is 3G?. The MN Just
tries again and again or it should better syn. with the network policy
to know that it can be done via WiFi?.

Regards,
TrungTM

---

From: [email-masked]
Date: Fri, 11 Feb 2011 17:18:56 +0800

Hi Trung,

Tran Minh Trung <[email-masked]> 写于 2011-02-11 下午 04:40:09:

> > the default policy configuration. No dynamic policy maintenance 
isneeded on
> to know that it can be done via WiFi?.
I understand your concern. But what I said is on active IP connectivity. 
Whether the MN should remember the change happened during the connection 
is implementation dependent with the assumption that the service can be 
initiated on the default interface. The example you mentioned is on how 
the MN get the network policy before initiating the service traffic. Seems 
not easy for LMA to covey this info since a gap exists on how to covey 
this from MAG to MN. Maybe the third party can help e.g. ANDSF defined in 
3GPP while that is another story.

Regards,
Joy

---

From: Julien Laganier <[email-masked]>
Date: Fri, 11 Feb 2011 10:10:04 -0800

Hello -

> the default policy configuration. No dynamic policy maintenance is needed on

This is neither pragmatic nor practical.

An LMA has no basis to unilaterally instruct a MN to route traffic on
a different interface, as the MN is the only network node that really
knows how good or bad that interface is. If my MN is attached to a bad
WiFi (say overloaded IETF meeting hotel WiFi) and a reasonable 3G
network, I don't want the LMA to force me to use the overloaded WiFi.

What's pragmatic and practical is that the MN is provisioned with
policies (e.g., ANDSF in 3GPP) that indicates e.g. that WiFI should be
preferred over 3G, and based on this policy and the operating
environment, if WiFi is considered as working by the MN (not
overloaded to a point where one can barely run TCP), then the MN
decides to use WiFi over 3G. Based on this, the LMA should mirror the
MN's flow routing decision.

--julien

---

From: "Stefano Faccin" <[email-masked]>
Date: Fri, 11 Feb 2011 13:51:17 -0600

Hello Joy,

The approach you suggest is anything but pragmatic. Let me give you a clear example. Many smartphones today are owned by enterprises and provided to their employees. Enterprises have strict rules on how a device shall use the various access networks and for what traffic. These are enterprise-specific policies, not operator policies, therefore, we cannot expect any operator LMAs to have such policies. Therefore, dynamic policies in the MN are absolutely needed. As a matter of fact, if you pay attention to the use case of 3GPP, it has already been defined that even in the host-based model with policies in the MN, user settings (e.g. enterprise policies) can take priority over the operator policies. Therefore, concluding that “No dynamic policy maintenance is needed on MN” implies that the current use cases (including currently commercial ones deployed today) get excluded. 

Cheers,

Stefano Faccin

Standards Manager

Irving, Texas 75039 USA 
Office: (972) 910 3451  

Internal: 820.63451

 : (510) 230 8422

www.rim.com <outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.rim.com> ; www.blackberry.com <outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.blackberry.com>  

  <http://www.blackberry.com/> 

P Consider the environment before printing.

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, February 10, 2011 5:26 PM
To: Giaretta, Gerardo
Cc: [email-masked]; [email-masked]
Subject: [netext] 答复: Re: Policy assumptions in draft-bernardos-netext-pmipv6-flowmob

Hello, 

> with this assumption unless policies changed also on MN.
As mentioned by Pierrick, a pragmatic and basic way on policy can be appplied on MN in first round. For current flow, the MN should follow the LMA's change of traffic routing. And the MN initates any flow according to the default policy configuration. No dynamic policy maintenance is needed on MN. 

Regards, 

Joy Zhou 
ZTE Corporation

---

From: [email-masked]
Date: Sat, 12 Feb 2011 09:41:52 +0800

Hi Julien,

Julien Laganier <[email-masked]> 写于 2011-02-12 上午 02:10:04:

> >> > > I want to go back to the point raised by Stefano which was 
somehow
> >> > lost in the long thread.
> >> > > - Is it correct that there is an assumption that MN and LMA have 
the
> >> > same policies and behave accordingly?
> >> > >
> >> >
isneeded on
> MN's flow routing decision.
Thanks for explaination. I get your point. Yes, the MN should make the 
final decision of the traffic routing according to the real local 
environment. At this point the receiveing policies is taken as reference. 
Apologize for What I said previous is not clear. My concern is that 
whether the MN needs to update local policies when finding flow Y is 
moving from interface 1 to interface 2. There is no explicit statement  in 
the draft now.

Regards,
Joy

---

From: <[email-masked]>
Date: Mon, 14 Feb 2011 10:23:06 +0100

Hi,
> de Julien Laganier
> Envoyé : vendredi 11 février 2011 19:10
> À : [email-masked]
> Cc : [email-masked]; [email-masked]
> Objet : Re: [netext]答复: Re: Policy assumptions in draft-bernardos-
> netext-pmipv6-flowmob
> 
> Hello -
> 

In that case, there is few added value to PMIP; with such a terminal centric decision, MIP should be preferred.

If LMA controlled decision has limitation, a terminal centric decision model has also drawbacks. Actually, a good trade-off is a model where the network can assist the MN in its decision (the MN makes the final decision, but gets info from the network to make that decision), so avoiding the MN to attach an access with bad condition. But such a model bring couple of issues in PMIP context; these issues has been raised up in the ML MN/network interaction, policy synchronization... For sure we should address these issues, but in the meantime and in the scope of current next dratfs, a decision model where the LMA enforces its decision to the MN can be considered, knowing that LMA decision enforcement cannot be the only answer.  

Pierrick

---

From: Julien Laganier <[email-masked]>
Date: Mon, 14 Feb 2011 10:34:54 -0800

Hi Pierrick -

> In that case, there is few added value to PMIP; with such a terminal centric decision, MIP should be preferred.

IMHO, while designing a PMIP-based system, having a working system
should prime over PMIP having added value relative to MIP.

In other words, correctness trumps features.

> If LMA controlled decision has limitation, a terminal centric decision model has also drawbacks. Actually, a good trade-off is a model where the network can assist the MN in its decision (the MN ma…

What would be the basis for an LMA to enforce that flows are routed on
a given interface if the LMA has no availability on the MN's
interfaces availability?

Absent that, it seems to me that the LMA will never be in a position
to enforce anything... I am missing something?

--julien

---

From: <[email-masked]>
Date: Mon, 14 Feb 2011 18:46:52 +0000

Hi Julien,

On 2/14/11 12:34 PM, "ext Julien Laganier" <[email-masked]> wrote:

>
>> If LMA controlled decision has limitation, a terminal centric decision
>>model has also drawbacks. Actually, a good trade-off is a model where
>>the network can assist the MN in its decision (the MN makes the final
>>decision, but gets info from the network to make that decision), so
>>avoiding the MN to attach an access with bad condition. But such a model
>>bring couple of issues in PMIP context; these issues has been raised up
>>in the ML MN/network interaction, policy synchronization... For sure we
>>should address these issues, but in the meantime and in the scope of
>>current next dratfs, a decision model where the LMA enforces its
>>decision to the MN can be considered, knowing that LMA decision
>>enforcement cannot be the only answer.
>

Good question. The LMA only knows that an MN is registered via multiple
MAGs (lets assume over different interfaces). Hence it can route traffic
via either of these MAGs based on just that information.
If the MAG via which the packets are routed cannot deliver the packets to
the MN over the relevant interface, it MAY indicate failure which causes
the LMA to route packets via the other MAG (interface).

From the point of specifying flow mobility w.r.t PMIP6, is it not
sufficient that the ability to route packets via another MAG/prefix is
enabled for an ongoing flow? Without an explicit indication if the MN is
actually attached to that MAG and the link conditions of the interface via
which the MN is attached to that MAG.

>to enforce anything... I am missing something?

The LMA may simply route the packets to the other MAG/interface based on
the policy. 
Whether it will result in dropped packets is a separate issue.

-Raj

---

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

Hi Raj,

2011/2/14  <[email-masked]>:
> Good question.

Thanks :)

> The LMA only knows that an MN is registered via multiple
> MAGs (lets assume over different interfaces).

Right.

> Hence it can route traffic via either of these MAGs based on just that information.

This is where we disagree.

> the LMA to route packets via the other MAG (interface).

How would the MAG knows that the MN doesn't receive packets over said interface?

> enabled for an ongoing flow?

Delivery of an ongoing flow started of MAG X thru MAG Y is flow
mobility sure (please let's not bring the prefix discussion in there,
it's something different.) That being said, I am not aware of any
systems where the choice of radio interfaces is done by a hierarchical
mobility anchor, and I've also pointed why that doesn't work.

>                                              Without an explicit indication if the MN is

No.

> the policy. Whether it will result in dropped packets is a separate issue.

If the "separate issue" result in the LMA routing all traffic through
a WiFi interface where none of the packets are making it to the MN, I
have to say that the separate issue makes the whole system useless,
and thus unless we have a solution to the separate, there is little
point in designing the system.

--julien

---

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

Inline:

>This is where we disagree.

Why? The LMA can route packets to the MN either via MAG1 or MAG2. If some
policy indicates that some traffic needs to be routed via MAG2, it can do
that as long as it is aware that the MN is registered via MAG2.
Not sure I understand your disagreement on this point.

>How would the MAG knows that the MN doesn't receive packets over said

It would not. Unless there are some other out-of-band means which are
beyond the PMIP6 protocol itself to do so.

>mobility anchor, and I've also pointed why that doesn't work.

So I guess we agree that switching a flow from MAGx to MAGy is flow
mobility. 
The choice of which anchor (MAG) thru which traffic routed is a choice of
policy that could be simply configured at the LMA. The LMA knows that the
MN is attached via MAGy over a wifi interface via the Access type
indication in the PBU. So it could simply make the decision to route some
traffic types from MAGx to MAGy.
Why is this not doable?

>> which the MN is attached to that MAG.

??? The MN attaches via MAGy (wifi) which results in it being registered
at the LMA. Now there is no way to indicate continued attachment thru MAGy
or link conditions. So unless there is a dereg from MAG2, the LMA will
presume that the MN is attached via MAGy.
Of course on a wifi access, the MN may explictly deregister/disassociate
which would cause the MAGy to send the deregister notification to the LMA
at which time the LMA would switch traffic back to MAGx.

>point in designing the system.

Okay. Understand your concern about the lack of clarity from a system
level solution perspective.
Lets see if we can find some answers or options of how to solve the
problem.

-Raj

---

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

Inline as well:

> Not sure I understand your disagreement on this point.

As per what follows. The MAG2 can register the MN based on the MN
being attached there, but if the radio link is terrible and MN
receives nothing from MAG2, there's little point in routing traffic to
MAG2.

Or does offload means we're developing a solution blackholes part of
the traffic?

> It would not.

So LMA would send part of the traffic into a blackhole.

> Unless there are some other out-of-band means which are

They are not only beyond the PMIPv6 protocol, they do not exist!

So we'd be designing a PMIPv6 extension that doesn't work in the real
world, really?

> So I guess we agree that switching a flow from MAGx to MAGy is flow

Yes.

> traffic types from MAGx to MAGy.

Because beyond the fact that MN is attached at MAGy, the LMA know
nothing about actual connectivity beyond MN and MAGy.

It's not a policy choice that has to be made, it is a contextual
choice, with policy as input to the decision. In the current state of
affair the only entity that has the context is the MN. Thus, the LMA
deciding all by himself based on policy is not doable.

> presume that the MN is attached via MAGy.

And possibly send traffic into a blackhole. You're proving my point.

> at which time the LMA would switch traffic back to MAGx.

In which case the MN has the final say. So in the system you're
advocating, the only way by which a MN can avoid having traffic
blackholed on a bad WiFi is by not attaching the WiFi at all... But
then we don't need flow mobility do we?

> level solution perspective.

Ok you see my point. Good.

> Lets see if we can find some answers or options of how to solve the

Thanks, I'm waiting.

--julien

---

From: <[email-masked]>
Date: Tue, 15 Feb 2011 09:33:03 +0100

> De : Julien Laganier [mailto:[email-masked]]
> Envoyé : lundi 14 février 2011 19:35
> À : SEITE Pierrick RD-RESA-REN
> Cc : [email-masked]; [email-masked]; [email-masked]
> >> >> > > I need some clarifications on which is the assumption in terms
> of
> >> >> > policies in the draft. In particular:
> >> >> > >
> >> > LMA's change of traffic routing. And the MN initates any flow
> according
> >> to
> > In that case, there is few added value to PMIP; with such a terminal
> centric decision, MIP should be preferred.
> 
> model has also drawbacks. Actually, a good trade-off is a model where the
> network can assist the MN in its decision (the MN makes the final decision,
> but gets info from the network to make that decision), so avoiding the MN
> to attach an access with bad condition. But such a model bring couple of
> issues in PMIP context; these issues has been raised up in the ML
> MN/network interaction, policy synchronization... For sure we should
> address these issues, but in the meantime and in the scope of current next
> dratfs, a decision model where the LMA enforces its decision to the MN can
> be considered, knowing that LMA decision enforcement cannot be the only
> answer.
> 

Exactly, PMIP, or MIP, or whatever the handover execution is, must interact with decision framework. Mobility management is made of different functions, PMIP deals only with execution.