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

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 01 Mar 2011 10:38:52 +0100

Hi Julien,

On Mon, 2011-02-28 at 19:33 -0700, Julien Laganier wrote:
> 2011/2/28 Carlos Jesús Bernardos Cano <[email-masked]>:
> > Hi Julien,
> >
> > On Fri, 2011-02-25 at 12:59 -0700, Julien Laganier wrote:
> >> 2011/2/25 Carlos Jesús Bernardos Cano <[email-masked]>:
> >> > Hi Julien,
> >> >
> >> > On Fri, 2011-02-25 at 09:01 -0700, Julien Laganier wrote:
> >> >> JC,
> >> >>
> >> >> Since no PMIPv6 based system can possibly work without the L2
> >> >> 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.
> >>
> >> 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
> >
> > Well, my lab is in this world (and yes, Universities are real :) ),
> > kidding. Please see inline below...
> >
> >> 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 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).
> 
> Right. It does not work because the system can't reliably expect these
> RS's to be sent and received by hosts.
> 
> > 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).
> 
> So you do rely on L2 signaling. That was my point. That L2 signalling
> is required.

Well, there is a big difference between using the signalling that is
always there (no matter if is PMIPv6 in place or just a single station
attaching to an AP) and requiring L2 signalling to have additional
semantics to enable PMIPv6 operation. We just use triggers from the AP.

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

You can have information about the capabilities of the device in your
database as well.

Carlos

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

-- 
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: Thu, 3 Mar 2011 11:34:39 -0800

Hi Carlos,

> semantics to enable PMIPv6 operation. We just use triggers from the AP.

If you target a 3GPP system for flow mobility between a PMIPv6-based
3GPP access (S5) and non-3GPP access (S2b), 3GPP " owns"  the L2
signaling and can certainly extends it to support flow mobility.

On the other hand if you rely upon the *unmodified* L2 signaling of an
IEEE 802 media to provide flow mobility across an IEEE 802 media and a
non-IEEE 802 media such as 3GPP, I don't understand how  the thing
would work, including:

1. how does network retrieve knowledge of the MN stack capabilities
w.r.t. flow mobility / inter access handoff (e.g. logical interface
support) ?
2. how does the network obtains knowledge of the MN-ID based on IEEE
802 L2 signaling?
3. how does the network provides a point-to-point link over a shared
IEEE 802 media?

...and there are probably more but these three come to mind first...

> You can have information about the capabilities of the device in your

If you rely on unmodified IEEE 802 signaling, should I take it as your
solution be only applicable to monolithic devices integrating an IEEE
802.11 chipset?

--julien

---

From: Tran Minh Trung <[email-masked]>
Date: Fri, 4 Mar 2011 09:15:48 +0900

Hi Julien,

Since I did not receive answer for my questions in previous email,
could I understand that LMA-MAG signaling is necessary for the case of
adding attached interfaces to a new session.

Please check again my questions in quoted text:

On Mon, Feb 28, 2011 at 6:08 PM, Tran Minh Trung <[email-masked]> wrote:
> Hi Julien,
>
> On Sat, Feb 26, 2011 at 1:06 AM, Julien Laganier <[email-masked]> wrote:
>> 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:
>
<TrungTM>
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
>> 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.
>>
>
<TrungTM>
 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
>
>> Thanks,
>>
>> --julien
>>
>> On Thu, Feb 24, 2011 at 8:06 PM, Tran Minh Trung <[email-masked]> wrote:
>>> 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
>>>
>>>
>>>
>>>
>>> On Fri, Feb 25, 2011 at 11:19 AM, Julien Laganier <[email-masked]> wrote:
>>>> On Thu, Feb 24, 2011 at 6:03 PM, Rajeev Koodli <[email-masked]> wrote:
>>>>>
>>>>> 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.
>>>>
>>>> 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.
>>>>
>>>>> 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 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.
>>>>
>>>>> 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.
>>>>
>>>> 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
>>>>> on..
>>>>
>>>> Not sure I understand. What do you mean by "let's move on"?
>>>>
>>>> --julien
>>>> _______________________________________________
>>>> 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
>>>
>>
>
>
>
> --
> 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
>

-- 
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: Julien Laganier <[email-masked]>
Date: Fri, 4 Mar 2011 17:35:31 -0800

Hi Tran,

Sorry for not replying earlier...

> different with the L2 signaling used in RFC5213?.

RFC 5213 assumes but does not define L2 signaling. The assumptions are
that the L2 signaling carries attach, detach, and optionally
intra-access handoff and inter-access handoff. The latter is required
to support any type of inter-access handover because without it a
legacy MN could end up with no connectivity at all if configured with
same prefix/address over two different interfaces.

> activates a PDN connection over a specific PHY interface (MAG)?.

If the specific connection is to have flow mobility enabled through a
given physical interface, the L2 signaling can certainly be sent to
the MAG that serves that physical interface if the specification says
so. It doesn't need to happen all at once. It only need to happen when
the specific physical interface is to be brought up, or when the
session (e.g., PDN connection) is created, whichever happens first.

> add ALL attached PHY interfaces to a new session.

Why would this be magic. PDN connection creation entails L2 signaling.
So you just piggyback on that L2 signaling to attach the physical
interfaces to the session / PDN connection.

> 2. The UE discovers a WiFi access and attaches to it as per TS 23.402,

I think this is the wrong section of 23.402. The initial attach would
be in section 7.2.1., and the inter-access handoff in 8.2.3.

> logical interface ID or just 3GPP Interface ID?

3GPP wise, activation of a PDN connection would be indicated via
indicating a distinct APN for the PDN to which to connect the PDN
connection.

> Connection Reconfiguration Complete"?.

For inter-access hand-off:

The L2 signaling on the 3GPP access side is in step 3 of section
8.2.1.1. where the UE uses a Request Type indicating "Handover" Attach
that corresponds to a handoff indicator of " inter-access handoff".

The L2 signaling on the non-3GPP access side is the signaling of the
underlying layer to IP, i.e., IKEv2. The handoff indicator can be set
to handoff across interfaces if in the step 4. of section 8.2.3 the UE
indicates support for IP address preservation (i.e., the 3GPP term for
support of inter-access handoff.)

You won't find the steps for flow mobility since it's not supported
yet for non-3GPP accesses other than DSMIPv6 based S2c...

--julien