Subject: [netext] Flow Mobility discussion - way forward?

From: Rajeev Koodli <[email-masked]>
Date: Tue, 22 Feb 2011 22:05:50 -0800

Hello folks,

I guess we all could agree that we have had plenty of discussion.
There are pros and cons of both L2 signaling and IP-based signaling
approaches. I would like to propose a way forward.

1) L2 signaling-based:
1. MN attaches to a (new) MAGy
2. MN indicates using (extended) L2 signaling that the attachment is for
flow mobility with a new HI=FM value
3. MAGy sends the PBU, and the LMA updates an existing session with the new
interface and MAGy 
4. The old and new prefixes are shared for the session
5. There is new L2 signaling between the MN and the (old) MAGx to trigger
the PBU from MAGx. 
6. This covers the case where we assume that L2 signaling and the associated
extensions are feasible. Keeps the existing RFC 5213 model

2) IP-based:
1. *If* the PBU from the new MAGy does not carry the new HI=FM value, the
LMA creates a new session (modulo handover^) per RFC 5213.
2. In this case, the LMA adds the prefix to the session(s) if the policy
requires/allows the MN for flow mobility
3. The LMA signals the relevant MAGs to provide the prefix(es) when flow
mobility is required
4. This covers the case where L2 signaling extensions for flow mobility are
not feasible or are not in place, or for any generic L2 technology
5. 2) will not come into play if 1) above is in place.

Comments? 

-Rajeev

^ HI=Handover will be similar to 1) above except that the forwarding state
for Proxy-CoA-MAGx is removed (and hence no flow mobility).

---

From: Tran Minh Trung <[email-masked]>
Date: Wed, 23 Feb 2011 17:52:30 +0900

Hi Rajeev,

Please see my inline comments.

On Wed, Feb 23, 2011 at 3:05 PM, Rajeev Koodli <[email-masked]> wrote:
> MN attaches to a (new) MAGy
> MN indicates using (extended) L2 signaling that the attachment is for flow
> mobility with a new HI=FM value
> MAGy sends the PBU, and the LMA updates an existing session with the new
> interface and MAGy
> The old and new prefixes are shared for the session

If HI=FM then the LMA just adds the new interface to the existing
session. No new prefixes are assigned.

> There is new L2 signaling between the MN and the (old) MAGx to trigger the
> PBU from MAGx.

Since no new prefixes are assigned, we do not need a new L2 signaling here.

> This covers the case where we assume that L2 signaling and the associated
> *If* the PBU from the new MAGy does not carry the new HI=FM value, the LMA
> creates a new session (modulo handover^) per RFC 5213.
> In this case, the LMA adds the prefix to the session(s) if the policy
> The LMA signals the relevant MAGs to provide the prefix(es) when flow
> mobility is required
> This covers the case where L2 signaling extensions for flow mobility are not
> feasible or are not in place, or for any generic L2 technology
> 2) will not come into play if 1) above is in place.

As my comments in 1), we do not need new L2 signaling.
The only thing we need is new value of HI to indicate that the new
attach can support flow mobility.
It is the same as hand-off indicator used in RFC5213.
So I think that the basic L2 signaling, as used in RFC5213, is enough
for the scenario that you described above.

The IP-Based may be needed when a new virtual interface is activated
on the fly (create new VPN connection or add new primary PDP contexts
in UMTS).

Let's consider the following scenario:

(1) MN attached interface 1 (IF1) and Interface 2 (IF2) to the MAG1
and MAG2 respectively.
- Session_A:[Prefixes_A | IF1,MAG1 | IF2,MAG2 ] was created to manage
both IF1 and IF2.
(2) A new virtual interface (eg. ppp) is created for a new VPN
connection via the physical interface IF1.
- A new IPv4 address/IPv6 prefix is assigned to the VPN interface ppp.
- Session_N{Prefix_N | PPP,MAG1 } is created to manage the virtual interface ppp

To allow VPN flows can be moved across physical interfaces, we need to
add IF1, IF2 to Session_N.
Is that right?

In this scenario I would rather follow IP-Based approach than rely on
a new L2 signaling message.

I hope that my description is clear enough.

Regards,
TrungTM

> _______________________________________________
> 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: "MELIA, TELEMACO (TELEMACO)" <[email-masked]>
Date: Wed, 23 Feb 2011 22:13:57 +0100

It captures very well the discussions so far. Agree and support.

telemaco

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Rajeev Koodli
Envoyé : mercredi 23 février 2011 07:06
À : [email-masked]
Objet : [netext] Flow Mobility discussion - way forward?

Hello folks,

I guess we all could agree that we have had plenty of discussion.
There are pros and cons of both L2 signaling and IP-based signaling approaches. I would like to propose a way forward.

1) L2 signaling-based:

 1.  MN attaches to a (new) MAGy
 2.  MN indicates using (extended) L2 signaling that the attachment is for flow mobility with a new HI=FM value
 3.  MAGy sends the PBU, and the LMA updates an existing session with the new interface and MAGy
 4.  The old and new prefixes are shared for the session
 5.  There is new L2 signaling between the MN and the (old) MAGx to trigger the PBU from MAGx.
 6.  This covers the case where we assume that L2 signaling and the associated extensions are feasible. Keeps the existing RFC 5213 model

2) IP-based:

 1.  *If* the PBU from the new MAGy does not carry the new HI=FM value, the LMA creates a new session (modulo handover^) per RFC 5213.
 2.  In this case, the LMA adds the prefix to the session(s) if the policy requires/allows the MN for flow mobility
 3.  The LMA signals the relevant MAGs to provide the prefix(es) when flow mobility is required
 4.  This covers the case where L2 signaling extensions for flow mobility are not feasible or are not in place, or for any generic L2 technology
 5.  2) will not come into play if 1) above is in place.

Comments?

-Rajeev

^ HI=Handover will be similar to 1) above except that the forwarding state for Proxy-CoA-MAGx is removed (and hence no flow mobility).

---

From: Julien Laganier <[email-masked]>
Date: Wed, 23 Feb 2011 14:43:31 -0700

Forgot to mention one thing below:

> I guess we all could agree that we have had plenty of discussion.

and I hope we can agree we' ve had a lot of valid questions in
alternative 2) that went unanswered.

> approaches. I would like to propose a way forward.

A way forward would be for the questions that were left unanswered to
be answered...

Thanks,

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 23 Feb 2011 14:40:45 -0700

Hi Rajeev -

> The old and new prefixes are shared for the session

There are no such thing as old and new prefixes in what I've been
advocating. We stick to 5213 model where the prefix _set_ is allocated
to a session when that session is first created.

> There is new L2 signaling between the MN and the (old) MAGx to trigger the

This is not needed. MAGx doesn't need to send a PBU since MAGx was
already registered for that session.

> extensions are feasible. Keeps the existing RFC 5213 model

The L2 signaling is a prerequisite to use PMIPv6 as per 5213 anyway.
There are no systems that can use PMIPv6 ala 5213 w/o the appropriate
L2 signal to trigger sending a PBU at initial attach and handoff.

> creates a new session (modulo handover^) per RFC 5213.

If the PBY doesn't carry the new HI=FM value, it's because the network
does not know whether or not the MN supports the flow mobility, in
which case a new session is to be created as per RFC 5213, to avoid
breaking a legacy host.

> requires/allows the MN for flow mobility

In this case we are in pure 5213 model and the LMA shouldn't be doing
anything special because it risks breaking a legacy host. This is
similar to what happens in 5213 and the same host attaching via two
different interfaces but the HI being set to unknown: two separate
sessions are maintained for each interface, to avoid breaking legacy
host. We cannot depart from this.

> The LMA signals the relevant MAGs to provide the prefix(es) when flow

No as this would break a legacy host.

> feasible or are not in place, or for any generic L2 technology

There are no such cases since 5213 requires L2 signaling already.

> 2) will not come into play if 1) above is in place.

True, thus 2) never comes into play since 5213 requires 1) already.

> Comments?

As above.

Thanks,

--julien

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 23 Feb 2011 14:15:56 -0800

Hi Trung,

> session. No new prefixes are assigned.

We have two cases here, right? A) the new attachment gets the exact same
prefix(es) as the previous one, and B) the new attachment gets one or more
new prefix(es) - per RFC 5213, any attachment can get multiple prefixes
which may or may not be the same as previously assigned ones. So, agree with
you on A). We need to also include B).

> Since no new prefixes are assigned, we do not need a new L2 signaling here.

I think you do, for B) above.

Regards,

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 23 Feb 2011 14:36:11 -0800

Hi Julien,

I am catching up after a travel break. So, pardon me if I have missed
something.

> to a session when that session is first created.

I understand your model, I think. You pre-assign a set and stick with it. No
new prefixes are ever-assigned on an attach. This IMO is a bit restrictive.
I don't think 5213 prohibits you from assigning a new prefix on attach which
is not (yet) assigned to a session.

My point is that you could do what you are suggesting (i.e., pre-assign all
the forseable prefixes beforehand) *and* do what I am suggesting (i.e.,
freely assign a prefix of my choice on attach).

> already registered for that session.

If the LMA assigned a prefix which was not assigned before, you need it,
right?

> L2 signal to trigger sending a PBU at initial attach and handoff.

For what it is today, yes. That does not mean that we necessarily want to
continue to rely on L2 extensions. If it's available, fine. But, we should
also be able to support, e.g., IP which is within the jurisdiction of this
WG and not dependent on other SDOs.

> which case a new session is to be created as per RFC 5213, to avoid

I assume by network you mean the MAG. The LMA can know whether the MN
supports flow mobility by other means, e.g., through AAA. See for instance:

http://tools.ietf.org/html/draft-koodli-netext-multiaccess-indicator-01

> host. We cannot depart from this.

See above regarding how the LMA might know whether the MN supports Logical
Interface.

> No as this would break a legacy host.

Not if the LMA knows otherwise.

> There are no such cases since 5213 requires L2 signaling already.

Requiring L2 signaling to do what is expected today is not the same as
continued reliance on it for anything else. I would like to be able to use
IP.

> True, thus 2) never comes into play since 5213 requires 1) already.

On a MN attach where HI=unknown, it does. It addresses this case without
relying on all L2's to provide the necessary extensions for flow mobility
signaling.

Thanks,

-Rajeev

---

From: Julien Laganier <[email-masked]>
Date: Wed, 23 Feb 2011 16:23:46 -0700

Hi Rajeev,

> is not (yet) assigned to a session.

In 5213 the prefix set is allocated once at session creation (i.e.,
first attach of an interface for that session) and remains unmodified
throughout that session duration. I haven't seen anything that
justifies departing from that model in the context of providing flow
mobility.

> freely assign a prefix of my choice on attach).

It's not what I'm suggesting, it's what 5213 does, and flow mobility
in itself ain't a reason to change that.

> If the LMA assigned a prefix which was not assigned before, you need it,

An LMA doesn't need to assign a prefix which wasn't assigned before to
do flow mobility. So we don't need it.

> WG and not dependent on other SDOs.

So right now PMIPv6 presuppose that MN-to-nework L2 signaling is there
for the PMIPv6 protocol to work. Specifying a MN-to-network IP layer
signaling has been put explicitely out of the jursiduction of this WG
when it was rechartered thus I am surprised by your statement above.

> http://tools.ietf.org/html/draft-koodli-netext-multiaccess-indicator-01

I think whether or not AAA can really knows what are the capabilities
of a network stack on a device is questionable, but let's skip on that
for now:

In 3GPP, the MAG in the ePDG has interfaces to AAA, so the MAG would
know from AAA that that MN supports flow mobility, and MAG sets HI=FM.
Goto 1) above. On the other hand in 3GPP the LMA has no interfaces
with AAA, so what you describe in your draft isn't applicable there.

> See above regarding how the LMA might know whether the MN supports Logical

I saw. The LMA would know because it is told by the MAG who's told by
AAA, and MAG would set HI=FM in PBU. Goto 1) :)

> Not if the LMA knows otherwise.

See above.

> continued reliance on it for anything else. I would like to be able to use

Relying on L2 signaling that is required anyway makes entire sense.
Doing something else brings no benefits in terms of that reliance on
L2.

> relying on all L2's to provide the necessary extensions for flow mobility

HI != unknown since AAA can tell MAG that HI = FM in your AAA-scenario.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 23 Feb 2011 16:37:31 -0700

Hi Rajeev,

I have a correction to make below on my earlier statement:

> with AAA, so what you describe in your draft isn't applicable there.

Regarding 3GPP I made a wrong statement, sorry about that: The LMA
indeed has an interface to AAA, but so has the MAG. So anything that
the LMA can know thru AAA, the LMA can know as well.

That being said, if we only assume 5213 and aren't specific to 3GPP,
if a PMIPv6 deployment relies on AAA, the entity that would be
required to be interfaced to a AAA system is the MAG, because it needs
to authenticate the MNID and pull the policy profile.

So in this AAA scenario it still holds that the MAG can know the MN's
capability from AAA and set the HI = FM.

Hope that clarifies my earlier statement.

--julien

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 24 Feb 2011 17:52:36 +1100

Julien, all,

> the LMA can know thru AAA, the LMA can know as well.

=> I think we need to be careful about using AAA as a potential silver
bullet for things we don't know how to do in our protocol. More
specifically, the property discussed above is a device attribute. AAA is
usually a user profile not a device profile unless you assume a 1:1 mapping
of device:user, which might be the case in some systems in the US but is
certainly not the case in the rest of the world. So assuming the device
properties will be stored in AAA and attributed to the user is not a good
way to go. 
Furthermore, users use devices that have not be "initialised" in AAA all the
time. A user doesn't ask for an operator's permission before they stick
their SIM in a device. So device properties are not known in advance.

Hesham

---

From: Julien Laganier <[email-masked]>
Date: Thu, 24 Feb 2011 09:05:58 -0700

Hesham,

>>> of a network stack on a device is questionable, but let's skip on that

but still I wanted to make the point that if to support scenario 2) in
Rajeev's mail one needs to assume LMA is told by AAA the device
capabilities, then the  MAG can be told that as well by AAA (e.g., at
same time it gets to know the MNID) and set HI = FM appropriately as
per case 1) thus there's no point in supporting case 2) as per my
earlier writings on the topic.

--julien

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 24 Feb 2011 09:42:05 -0800

Julien,

Please treat this as a combined response to your other e-mail as well.

> I agree with this entirely, which is why I said:

Good points. 
The purpose of the multi-access indicator ID is twofold: to enable the MN to
indicate its capability and willingness for flow mobility (through the
AT_MA_IND attribute). Second, to enable AAA to authorize the user for flow
mobility. So, it's the MN which is indicating the device capability, and the
AAA providing the authorization for the flow mobility service.

> earlier writings on the topic.

There are two parts to consider here. First, the issue of LMA knowing that
the MN is capable and willing to have flow mobility (I think you brought up
the issue of legacy host). Whether or not MAG is informed by the AAA, there
is LMA - AAA interaction. In other words, LMA will go to AAA anyway. So, the
AAA providing the attribute to the MAG is redundant exchange which we
thought unnecessary for the multi-access ID. And, whether the LMA will
actually accept the indicator provided by MAG is moot, since the
authorization should come from elsewhere (AAA).
 
Second, the issue of assigning prefixes at the LMA. The LMA should be able
to assign any prefix freely upon any attach. With HI=Handover, it returns
the previously assigned prefix, but there is no prohibition to also return a
hitherto unassigned prefix, AFAICT. Similarly, even with HI = FM, the LMA
can assign a new prefix which is not in the current set. This is not a new
feature which we need to support.

-Rajeev

---

From: Julien Laganier <[email-masked]>
Date: Thu, 24 Feb 2011 12:17:05 -0700

Rajeev,

Please see inline.

On Thu, Feb 24, 2011 at 10:42 AM, Rajeev Koodli <[email-masked]> wrote:
> is LMA - AAA interaction.

MAG has to be informed of an authenticated MNID for PMIPv6 to work.
When authentication of the MNID is based on AAA, the MAG already
receives information from AAA. So in a basic 5213 deployment that uses
AAA for authentication, there is MAG-AAA interaction.

On the other hand LMA - AAA interaction isn't required per se in the 5213 model.

>                                  In other words, LMA will go to AAA anyway. So, the
> thought unnecessary for the multi-access ID.

This backward: As above, if AAA is used the MAG will go to AAA, so the
AAA providing the attribute to the LMA is the redundant exchange which
is unnecessary for multi-access ID.

>                                                                  And, whether the LMA will

PMIPv6 assumes that the MAG is trusted by the LMA, thus the LMA can
accept the indicator provided by the MAG.

> to assign any prefix freely upon any attach.

As I said earlier many times, the 5213 model is that of a prefix set
allocated at session creation and there has been no reason to depart
from that model for purposes of flow mobility, i.e., I can provide
flow mobility under that same model thus there's no basis to change
that model under this work item.

>                                                                         With HI=Handover, it returns
> hitherto unassigned prefix, AFAICT.

As above, the 5213 model factually does not change the prefix set that
was allocated at session creation after a handover or at any other
point in the session lifetime. As above, there's no basis to change
that for the purpose of flow mobility since it is not required /
necessary.

>                                                             Similarly, even with HI = FM, the LMA
> can assign a new prefix which is not in the current set.

Disagree. This is an unwarranted modification of the 5213 model.

> This is not a new feature which we need to support.

Compared to the 5213 model it is indeed a new feature that a prefix
set for a PMIPv6 session can be modified after that session creation,
as I've kept explaining again and again. And that new feature is not
required to complete the flow mobility work item thus there's no basis
to alter the 5213 model in that context.

I am surprised we are still discussing this.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Thu, 24 Feb 2011 12:21:54 -0700

Telemaco,

I am afraid I do not find your statement below helpful in moving forward.

During the discussion many questions have been asked and left
unanswered, thus it is both the case that 1) it is premature to
summarize the discussion since it hasn't concluded by questions being
answered, and 2) the summary that was provided is inappropriate as it
does not capture the questions that were left unanswered during the
discussion.

--julien

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 24 Feb 2011 11:38:47 -0800

Julien,

The presumed MAG-AAA interaction in 5213 is for authentication purposes.
The LMA-AAA interaction is for authorization purposes. The intent in the
multi-access ID is to enable AAA to authorize the LMA for flow mobility
purposes. It's kind of interesting that you refer to 3GPP model sometimes,
but reticent about it for the LMA - AAA interaction in 3GPP (e.g., your
statement below "LMA - AAA interaction is not required per se")..

You don't believe that there is a need to add a new prefix to the session.
However, you didn't show me that 5213 prohibits adding a new prefix to an
existing session. I believe that LMA should be allowed to provide any prefix
it chooses to, including the previously assigned ones and the new ones.
So, let's agree to disagree :-)

-Rajeev

On 2/24/11 11:17 AM, "Julien Laganier" <[email-masked]> wrote:

>>                                                                  And, whether
>> the LMA will

---

From: Julien Laganier <[email-masked]>
Date: Thu, 24 Feb 2011 14:20:39 -0700

> statement below "LMA - AAA interaction is not required per se")..

As I said earlier, if AAA is required to be in place to authenticate
the MN towards the MAG, that can be used for authorization too. I do
not see what is the security requirement that authorization happens in
LMA rather than in MAG.

That being said, I don't care much about the specifics of the AAA
interactions with PMIPv6. My point was, and is, that if you assume
that the LMA can know from AAA about the ability for a MN network
stack to support flow mobility (as opposed to a legacy node), so can
the the MAG. Thus the MAG can set the HI = FM to provide flow
mobility. As a result the inability of a MAG to know about the MN
level of support for flow mobility can't be used as an argument in
favor of your model 2) where the LMA knows about MN flow mobility but
the MAG doesn't.

> it chooses to, including the previously assigned ones and the new ones.

I don't believe there's a need to add a new prefix to an existing
session to provide flow mobility. Can you point to a usecase that
_requires_ adding a new prefix to an existing session for purposes of
providing flow mobility?

My reading of 5213 is that it documents a protocol in which the prefix
set is allocated at session creation and remains unmodified throughout
that session lifetime. 5213 doesn't provide a mean to change the
prefix set after session creation. Can you point to a provision of
5213 that allows changing the prefix set of a session after its
creation?

> So, let's agree to disagree :-)

I can certainly agree to disagree on your reading of 5213 on the
ability to add prefixes to an existing session, and on the requirement
to add new prefix to provide mobility. I do not see any documented or
reasoned evidence about these.

--julien

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 25 Feb 2011 11:43:03 +1100

>>>> of a network stack on a device is questionable, but let's skip on that

=> ok I missed that part, then we're in agreement.

> earlier writings on the topic.

=> Right, I guess I stopped at the foundational assumption and it didn't sit
well with me so I consider the whole scenario invalid, but yes you're right,
it can be done that way if the AAA assumption was realistic, but it's not.

Hesham

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 24 Feb 2011 17:03:11 -0800

I do care about the PMIP6 interaction with AAA because the system design
needs it. I don't know of a system where LMA relies on MAG for
authorization.

The use-case for being able to provide a new prefix at attach is robustness.
There is nothing I could see in 5213 that disallows an LMA from providing a
prefix which is not in the session, and why should there be any restriction
on what prefixes the LMA can provide at attach?

I want flow mobility solution to work without only relying on L2 signaling,
meaning we should be able to also provide it for HI=Unknown. This can be
done with IP signaling between LMA and MAG. This is not replacing L2
signaling, but covers the case when HI=unknown.

As I have also said earlier, we have different opinions here. Let's move
on..

-Rajeev

On 2/24/11 1:20 PM, "Julien Laganier" <[email-masked]> wrote:

>>>>                                                                  And,
>>>> whether

---

From: Julien Laganier <[email-masked]>
Date: Thu, 24 Feb 2011 19:19:18 -0700

> needs it. I don't know of a system where LMA relies on MAG for

I know of one such a system: In 3GPP the MAG in the ePDG is the PMIPv6
entity that verifies that the user has a subscription that authorizes
access via a non-3GPP access by querying AAA.

> The use-case for being able to provide a new prefix at attach is robustness.

This alone doesn't mean anything. Please explain the relationship
between new prefixes and protocol robustness.

> on what prefixes the LMA can provide at attach?

I am not talking about attach. I said the prefix set is fixed at
session creation and does not change thereafter. If you disagree,
please point me to, or write one here, a conformant RFC 5213 PMIPv6
call flow that changes the prefix set _after_ session creation.

> signaling, but covers the case when HI=unknown.

Again, PMIPV6 has to rely on L2 signaling and does not work without
it. You said in an earlier email that the MN indicates to the network
its support for flow mobility. If so, that information can be made
available to the MAG and the MAG to set the HI to FM appropriately.
The case HI=unknown shouldn't happen if the MN indicates to the
network its support for flow mobility.

> As I have also said earlier, we have different opinions here. Let's move

Not sure I understand. What do you mean by "let's move on"?

--julien

---

From: Tran Minh Trung <[email-masked]>
Date: Fri, 25 Feb 2011 12:06:19 +0900

Hi Julien,

I agree with your arguments that the case HI=unknow shouldn't happen
since the MAG is aware of MN's capacity, and the prefix set is fixed
at session creation and does not need to be changed thereafter.

However, I still wonder about the case that a new session is created on the fly.

Since the PHY interfaces are already attached, how the MN can send L2
signaling to all MAGs to inform that a new session is created when the
user starts an application and activate a new PDN connection or a new
VPN connection?

Could you elaborate more detail in the ML?.
 It would be nice if you can provide an example from a real system.

Regards,
TrungTM

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Fri, 25 Feb 2011 10:21:33 -0500

Rajeev,

I agree with you. 

Even if L2 signalling can help the scenario, we should not -only- rely on that as we might end up in a catch-22 situation.

By providing an L3 MAG-LMA signalling solution we would be covered in case L2 signalling is not there (HI=unknown), and at the same time we would not preempt a solution that has that L2 signalling to use it.

This seems to me like a good way to progress this and move forward.

JC

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Rajeev Koodli
> Sent: February 24, 2011 8:03 PM
> To: Julien Laganier
> Cc: [email-masked]
> Subject: Re: [netext] Flow Mobility discussion - way forward?
> 
> 
> >>>>>> usually a user profile not a device profile unless you assume a
> 1:1
> >>>>>> mapping
> >>>>>> Furthermore, users use devices that have not be "initialised" in
> AAA all
> >>>>>> the
> >>>> The purpose of the multi-access indicator ID is twofold: to enable
> the MN
> >>>> to
> >>>> mobility. So, it's the MN which is indicating the device
> capability, and
> >>>> the
> >>> On the other hand LMA - AAA interaction isn't required per se in
> the 5213
> >>> model.
> >>>
> >>>>                                  In other words, LMA will go to
> AAA anyway.
> >>>> So, the
> >>>> the previously assigned prefix, but there is no prohibition to
> also return
> >>>> a

---

From: Julien Laganier <[email-masked]>
Date: Fri, 25 Feb 2011 09:01:48 -0700

JC,

Since no PMIPv6 based system can possibly work without the L2
signaling, the L3 MAG-LMA signaling is factually useless.

This is has to be the conclusion of this discussion unless someone can
provide us with a description of how a system would work without the
L2 signaling.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Fri, 25 Feb 2011 09:06:58 -0700

Tran,

When parallel sessions are running across a same physical interface,
there will need to be session separation at L2 because otherwise
packets from different sessions can't be distnguished from each others
by either of the MAG or the MN. This L2 separation has to be triggered
by some L2 signaling: even though the physical interface might already
be attached, there will have to be another L2 signaling to attach the
new logical interface for the new session.

If you want to see example of real system, please have a look at the
relevant 3GPP specifications, e.g., TS 23.402.

Thanks,

--julien

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 25 Feb 2011 20:51:41 +0100

Hi Julien,

> signaling, the L3 MAG-LMA signaling is factually useless.

I have a PMIPv6 system working in my lab and there is no L2 signaling at
all. Optionally, I can enable the APs attached to the MAG detect the MN
attachment and use that as trigger for the PBU (instead of relaying on
ND). I agree L2 signaling is used by most deployments as in fact PMIPv6
was designed with many things "out-of-the-scope of the spec" (it's there
where L2 signaling appears), but I disagree L2 signaling is completely
necessarily. 

I agree with Rajeev's suggestion to move forward.

Thanks,

Carlos

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

---

From: Julien Laganier <[email-masked]>
Date: Fri, 25 Feb 2011 12:59:12 -0700

> where L2 signaling appears), but I disagree L2 signaling is completely

Having a prototype that works in a lab isn't a proof that the system
works in the real world. From my perspective L2 signaling is a
requirement and I do not know how to build a real world system based
on PMIPv6 that doesn't have them. I have two questions regarding the
real world world applicability of your system that works without L2
signaling:

1) what is the trigger to the PBU if it's not the L2 signaling?

2) How does the network decides it can offer flow mobility to a host
in the absence of a layer 2 signaling from the host that indicates
this host's support for flow mobility / inter-access handoffs?

> I agree with Rajeev's suggestion to move forward.

I am happy to move forward when the valid technical questions I've
asked are answered.

--julien

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Sat, 26 Feb 2011 15:04:15 -0500

Julien,

Ok, let me rephrase it. I should have said "new" L2 signalling.

If IP Flow Mobility L2 signalling becomes available in the future, fine. However, not to rely on this assumption and also to support scenarios where the decision for the flow mobility could come from the LMA, I see value in defining also the L3 signalling.

In other words, if L2 signalling for IP Flow mobility is there, you simply don't use this L3 signalling. If new L2 is NOT there, then you can rely on this L3 mechanism. 

I see no harm and a lot of value with this approach. 

To me this is a good compromise and good way to move forward.

JC

> From: Julien Laganier [mailto:[email-masked]]
> Sent: February 25, 2011 11:02 AM
> To: Zuniga, Juan Carlos
> Cc: Rajeev Koodli; [email-masked]
> > Even if L2 signalling can help the scenario, we should not -only-
> rely on that as we might end up in a catch-22 situation.
> >
> > By providing an L3 MAG-LMA signalling solution we would be covered in
> case L2 signalling is not there (HI=unknown), and at the same time we
> would not preempt a solution that has that L2 signalling to use it.
> >
> >> meaning we should be able to also provide it for HI=Unknown. This
> can
> >> be
> >> > On Thu, Feb 24, 2011 at 12:38 PM, Rajeev Koodli
> <[email-masked]>
> >> wrote:
> >> >>
> >> >> Julien,
> >> >>
> >> >> The LMA-AAA interaction is for authorization purposes. The intent
> in
> >> the
> >> >> but reticent about it for the LMA - AAA interaction in 3GPP
> (e.g.,
> >> your
> >> > not see what is the security requirement that authorization
> happens
> >> in
> >> > LMA rather than in MAG.
> >> >
> >> >> However, you didn't show me that 5213 prohibits adding a new
> prefix
> >> to an
> >> >>> On Thu, Feb 24, 2011 at 10:42 AM, Rajeev Koodli
> <[email-masked]>
> >> wrote:
> >> >>>>
> >> >>>> Julien,
> >> >>>>
> >> >>>> Please treat this as a combined response to your other e-mail
> as
> >> well.
> >> >>>>
> >> >>>>>> => I think we need to be careful about using AAA as a
> potential
> >> silver
> >> >>>>>> of device:user, which might be the case in some systems in
> the
> >> US but is
> >> >>>>>> certainly not the case in the rest of the world. So assuming
> the
> >> device
> >> >>>>>> properties will be stored in AAA and attributed to the user
> is
> >> not a good
> >> >>>>>> way to go.
> >> >>>> indicate its capability and willingness for flow mobility
> (through
> >> the
> >> >>>> AT_MA_IND attribute). Second, to enable AAA to authorize the
> user
> >> for flow
> >> >>>>>>>> of a network stack on a device is questionable, but let's
> skip
> >> on that
> >> >>>>>>>> for now:
> >> >>>>>
> >> >>>>> but still I wanted to make the point that if to support
> scenario
> >> 2) in
> >> >>>>> same time it gets to know the MNID) and set HI = FM
> appropriately
> >> as
> >> >>>> the MN is capable and willing to have flow mobility (I think
> you
> >> brought up
> >> >>>> the issue of legacy host). Whether or not MAG is informed by
> the
> >> AAA, there
> >> >>> receives information from AAA. So in a basic 5213 deployment
> that
> >> uses
> >> >>>> AAA providing the attribute to the MAG is redundant exchange
> which
> >> we
> >> >>> This backward: As above, if AAA is used the MAG will go to AAA,
> so
> >> the
> >> >>>> Second, the issue of assigning prefixes at the LMA. The LMA
> should
> >> be able
> >> >>> As above, the 5213 model factually does not change the prefix
> set
> >> that

---

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

Hi Julien,

On Sat, Feb 26, 2011 at 1:06 AM, Julien Laganier <[email-masked]> wrote:
> by some L2 signaling:

What is the type of the L2 signaling that you mentioned here?. Is it
different with the L2 signaling used in RFC5213?.
Can this L2 signaling be sent to all MAGs even though the UE just
activates a PDN connection over a specific PHY interface (MAG)?.

It is still magic to me to assume that a L2 signaling can be used to
add ALL attached PHY interfaces to a new session.

>even though the physical interface might already

I have checked  TS 23.402, 401 as well as TR 23.861  (Multi access PDN
connectivity and IP flow mobility).
However I can not find the answer for my question.

Could you elaborate it step by step for the following scenario:

1. The UE attaches to the 3GPP as defined in TS 23.401, clause 5.3.2.
-> Session 1 is created [{IF1, 3GPP, MAG1} | Prefix 1]
2. The UE discovers a WiFi access and attaches to it as per TS 23.402,
clause 8.4.2, steps 2-6.
Since 3GPP and WiFi interfaces are in the same set (of a logical
interface), the WiFi interface is added to Session 1: [{IF1, 3GPP,
MAG1};{IF2, WiFi, MAG1} | Prefix 1]  (PMIPv6 extension for flow
mobility)
3.  User starts an application and activates a new PDN connection over
3GPP interface -> Session 2 must be created.

-> other steps are from TS 23.401, clause 5.10.2: UE requested PDN connectivity

Q1. What is the information in Session 2?. Dose it include the PDN
logical interface ID or just 3GPP Interface ID?
Q2. When the L2 signaling, that you mentioned, is sent to both MAG1
and MAG2?. Is it before  "PDN Connectivity Request" or after  "RRC
Connection Reconfiguration Complete"?.

Thank you.

Regards,
TrungTM

---

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

Hi Carlos,

2011/2/26 Carlos Jesús Bernardos Cano <[email-masked]>:
> all.

I think it is not fully implemented system.
How can you support handover without the L2 signaling message?

Regards,
TrungTM

> Optionally, I can enable the APs attached to the MAG detect the MN

---

From: <[email-masked]>
Date: Mon, 28 Feb 2011 11:52:40 +0100

Hi all,

Just to be sure to discuss on solid basis and common understanding: 

Are we, now, in agreement on the following statement: "All prefixes are assigned when the first session is created" ?

It's fundamental, since, if this statement is aggreed, MAG/LMA L3 signalling is useless (FMU).

Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] 
> De la part de Zuniga, Juan Carlos
> Envoyé : samedi 26 février 2011 21:04
> À : Julien Laganier
> Cc : [email-masked]
> Objet : Re: [netext] Flow Mobility discussion - way forward?
> 
> Julien,
> 
> If IP Flow Mobility L2 signalling becomes available in the 
> future, fine. However, not to rely on this assumption and 
> also to support scenarios where the decision for the flow 
> mobility could come from the LMA, I see value in defining 
> also the L3 signalling.
> 
> In other words, if L2 signalling for IP Flow mobility is 
> there, you simply don't use this L3 signalling. If new L2 is 
> NOT there, then you can rely on this L3 mechanism. 
> 
> > > By providing an L3 MAG-LMA signalling solution we would 
> be covered 
> > > in
> > >> I do care about the PMIP6 interaction with AAA because 
> the system 
> > >> design needs it. I don't know of a system where LMA 
> relies on MAG 
> > >> for authorization.
> > >>
> > >> There is nothing I could see in 5213 that disallows an LMA from 
> > >> providing a prefix which is not in the session, and why should 
> > >> there be any restriction on what prefixes the LMA can provide at 
> > >> attach?
> > >>
> > >> I want flow mobility solution to work without only relying on L2 
> > >> signaling, meaning we should be able to also provide it for 
> > >> HI=Unknown. This
> > can
> > >> be
> > >> done with IP signaling between LMA and MAG. This is not 
> replacing 
> > >> L2 signaling, but covers the case when HI=unknown.
> > >>
> > >> As I have also said earlier, we have different opinions 
> here. Let's 
> > >> move on..
> > >>
> > >> -Rajeev
> > >>
> > >>
> > >> >> purposes. It's kind of interesting that you refer to 
> 3GPP model
> > >> sometimes,
> > >> > the MN towards the MAG, that can be used for 
> authorization too. I
> > do
> > >> > interactions with PMIPv6. My point was, and is, that if you 
> > >> > assume that the LMA can know from AAA about the 
> ability for a MN 
> > >> > network stack to support flow mobility (as opposed to a legacy 
> > >> > node), so
> > can
> > >> > level of support for flow mobility can't be used as an 
> argument 
> > >> > in favor of your model 2) where the LMA knows about MN flow 
> > >> > mobility
> > but
> > >> > the MAG doesn't.
> > >> >
> > >> >> You don't believe that there is a need to add a new prefix to 
> > >> >> the
> > >> session.
> > >> >> existing session. I believe that LMA should be allowed to 
> > >> >> provide
> > >> any prefix
> > >> >> it chooses to, including the previously assigned ones and the 
> > >> >> new
> > >> ones.
> > >> >
> > >> > _requires_ adding a new prefix to an existing session for 
> > >> > purposes
> > of
> > >> > providing flow mobility?
> > >> >
> > >> > prefix set after session creation. Can you point to a 
> provision 
> > >> > of
> > >> > to add new prefix to provide mobility. I do not see any 
> > >> > documented
> > or
> > >> >>>> On 2/24/11 8:05 AM, "Julien Laganier" 
> <[email-masked]>
> > >> wrote:
> > >> >>>>
> > >> >>>>>>
> > >> >>>>>> usually a user profile not a device profile unless you 
> > >> >>>>>> assume
> > a
> > >> 1:1
> > >> >>>>>> mapping
> > >> >>>>>> Furthermore, users use devices that have not be 
> "initialised"
> > in
> > >> AAA all
> > >> >>>>>> the
> > >> >>>>>> time. A user doesn't ask for an operator's 
> permission before
> > >> they stick
> > >> >>>>>> their SIM in a device. So device properties are 
> not known in
> > >> advance.
> > >> >>>>>
> > >> >>>>> per case 1) thus there's no point in supporting case 2) as 
> > >> >>>>> per
> > my
> > >> >>>> There are two parts to consider here. First, the 
> issue of LMA
> > >> knowing that
> > >> >>> When authentication of the MNID is based on AAA, the MAG 
> > >> >>> already receives information from AAA. So in a basic 5213 
> > >> >>> deployment
> > that
> > >> uses
> > >> >>> On the other hand LMA - AAA interaction isn't 
> required per se 
> > >> >>> in
> > >> the 5213
> > >> >>> model.
> > >> >>>
> > >> >>>>                                  In other words, 
> LMA will go 
> > >> >>>> to
> > >> AAA anyway.
> > >> >>>> So, the
> > >> >>> AAA providing the attribute to the LMA is the redundant 
> > >> >>> exchange
> > >> which
> > >> >>> PMIPv6 assumes that the MAG is trusted by the LMA, 
> thus the LMA
> > can
> > >> >>> As I said earlier many times, the 5213 model is that of a 
> > >> >>> prefix
> > >> set
> > >> >>> that for the purpose of flow mobility since it is 
> not required 
> > >> >>> / necessary.
> > >> >>>
> > >> >>>>
> > >> Similarly, even
> > >> >>>> with HI = FM, the LMA
> > >> >>> as I've kept explaining again and again. And that 
> new feature 
> > >> >>> is
> > >> not
> > >> >>> required to complete the flow mobility work item 
> thus there's 
> > >> >>> no
> > >> basis

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 28 Feb 2011 23:00:05 +0100

Hi Julien,

> works in the real world. From my perspective L2 signaling is a

Well, my lab is in this world (and yes, Universities are real :) ),
kidding. Please see inline below...

> 1) what is the trigger to the PBU if it's not the L2 signaling?

2 possible options:

a) RS from the MN (this is documented in RFC5213, though it does not
work very well, as not all systems send an RS after moving).

b) the AP where the MN attaches to detects the attachment and triggers
the MAG. Note that this is not _new_ L2 signalling here, it's just
attachment detection based on IEEE 802.11 frames (any standard station
has to generate them).

> this host's support for flow mobility / inter-access handoffs?

For example, you can have that information in the profile of the user.

> I am happy to move forward when the valid technical questions I've

I think I've tried to answer your questions. Problem is we don't quite
agree on the answers of all of them.

Carlos

---

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

Hi Trung,

> How can you support handover without the L2 signaling message?

Please, see my reply to Julien's e-mail. It's true is not a fully
RFC5213 system, but I can tell you we are not faking any event related
to handovers.

Carlos

> >> >> providing a
> >> >> signaling,

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 01 Mar 2011 12:32:55 +1100

Carlos, 

> attachment detection based on IEEE 802.11 frames (any standard station

=> How do you identify the MN across MAGs? How does a new MAG know the MN's
addresses? Are you transferring MAC addresses around?

> For example, you can have that information in the profile of the user.

=> Do you have a user profile transfer mechanism in your lab? If you do
please share some high level info.

Hesham

---

From: Julien Laganier <[email-masked]>
Date: Mon, 28 Feb 2011 19:33:31 -0700

> work very well, as not all systems send an RS after moving).

Right. It does not work because the system can't reliably expect these
RS's to be sent and received by hosts.

> attachment detection based on IEEE 802.11 frames (any standard station

So you do rely on L2 signaling. That was my point. That L2 signalling
is required.

> For example, you can have that information in the profile of the user.

I don't think that user profile can adequately characterizes the
capabilities of a device's network stack. I might own one device that
supports flow mobility and one that doesn't, in which case, either I
get no flow mobility on any of my devices, or I get flow mobility on
one of the devices and no connectivity at all on the other. None of
this two scenarios seems to be acceptable in a real system.

The only entity that can reliably transmit that information to the
network is the (network stack on the) host itself. So we do require L2
signaling.

--julien