Subject: Re: [netext] About draft-bernardos-netext-pmipv6-flowmob

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 4 Oct 2010 09:39:19 -0700

Hi Carlos,

Thank you for sharing with the WG the requirements you've been considering in developing your flow mobility solution. All requirements are non-controversial but this one with which I actually disagree:

> - Analyze the different scenarios to be supported. We currently include
> the "shared prefix" and "unique prefix" per physical interface models.

I disagree that supporting a per-physical interface prefix is a requirement to support flow mobility, and there also seems to be evidence that supporting a per-physical interface prefix is actually NOT a requirement for flow mobility:

- Up to version -06 of the PMIPv6 draft it is said that a given mobile node is allocated a unique set of prefix, that is either stored in the mobile node's policy profile, or dynamically assigned by the local mobility anchor. 

- This is changed starting with version -07 with the additional requirement that "the local mobility anchor MUST allocate a unique home network prefix for each of the connected interfaces." The departure from the earlier addressing model is justified because it is only way to avoid breaking unmodified hosts which would not support having the same prefix assigned simultaneously on the same interface. 

- The "unique prefix per interface" requirement is no longer justified for flow mobility work because all the work we're doing, while stile assuming an unmodified IP layer on the mobile nodes, also assumes that a logical interfaces hides the multiple physical interfaces. Thus assigning a single prefix set to the mobile node, independently of number of physical interfaces does not risk breaking the IP layer. Additionally, because when flow mobility is in use, packets are required to be routed on a per-flow basis and no longer based on a longest prefix match between routing table entries and packet destination IP address, flow mobility cannot be used to justify the need for per-interface prefix.  

--julien

Carlos Jesús Bernardos Cano wrote:
> 
> Hi all,
> 
> Julien and Raj suggested that people working on flow mobility solutions
> posted a summary of the requirements of goals of their ongoing work.
> 
> Authors of draft-bernardos-netext-pmipv6-flowmob are working on the
> next revision for the consideration of the WG. The draft has the
> following goals and requirements:
> 
> - The goal is to define PMIPv6 extensions that allow to move flows
> among different simultaneously attaches interfaces of an MN.
> 
> - Analyze the different scenarios to be supported. We currently include
> the "shared prefix" and "unique prefix" per physical interface models.
> 
> - The solution defines the LMA as the controlling entity. The solution
> defines the signaling between MAG and LMA. The specifics on how the
> network nodes obtain the policies is out of scope.
> 
> - The MN is equipped with one logical interface (we don't support flow
> mobility across different logical interfaces).
> 
> We are currently working out the details and reaching an agreement
> among the authors of the draft. As soon as we come up with a
> consolidated document (hopefully within the next couple of weeks) we'll
> submit it and ask for feedback to the WG.
> 
> Thanks,
> 
> Carlos
> 
> --
> Carlos Jesús Bernardos Cano     http://www.netcoms.net
> GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 12 Oct 2010 18:46:25 +0200

Hi Julien,

On Mon, 2010-10-04 at 09:39 -0700, Laganier, Julien wrote:
> Hi Carlos,
> 
> Thank you for sharing with the WG the requirements you've been
> considering in developing your flow mobility solution. All
> requirements are non-controversial but this one with which I actually
> disagree:
> 
> I disagree that supporting a per-physical interface prefix is a
> requirement to support flow mobility, and there also seems to be
> evidence that supporting a per-physical interface prefix is actually
> NOT a requirement for flow mobility:

At this stage we are just "analyzing the different scenarios to be
supported". This does not necessarily mean that at the end we aim at
supporting all. Anyway, I think it is in general better not to limit to
a single scenario (which is different from current PMIPv6 model), unless
there is no (or few) people that want it to be supported (so far some
people stated that the "unique prefix" per physical interface is useful
and needs to be covered) and considering it adds too much complexity to
the solution.

Besides, as a side note (as individual, not as editor of
draft-bernardos-netext-pmipv6-flowmob), I think that even though we are
now assuming the MN implements the logical interface, if we do not limit
too much the scenario, the extensions that we develop on the network
side could also work for MNs that do not support the logical interface
but "flow mobility" in general.

Thanks,

Carlos

> 
> - Up to version -06 of the PMIPv6 draft it is said that a given mobile
> node is allocated a unique set of prefix, that is either stored in the
> mobile node's policy profile, or dynamically assigned by the local
> mobility anchor. 
> 
> - This is changed starting with version -07 with the additional
> requirement that "the local mobility anchor MUST allocate a unique
> home network prefix for each of the connected interfaces." The
> departure from the earlier addressing model is justified because it is
> only way to avoid breaking unmodified hosts which would not support
> having the same prefix assigned simultaneously on the same interface. 
> 
> - The "unique prefix per interface" requirement is no longer justified
> for flow mobility work because all the work we're doing, while stile
> assuming an unmodified IP layer on the mobile nodes, also assumes that
> a logical interfaces hides the multiple physical interfaces. Thus
> assigning a single prefix set to the mobile node, independently of
> number of physical interfaces does not risk breaking the IP layer.
> Additionally, because when flow mobility is in use, packets are
> required to be routed on a per-flow basis and no longer based on a
> longest prefix match between routing table entries and packet
> destination IP address, flow mobility cannot be used to justify the
> need for per-interface prefix.  
> 
> --julien
>

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 12 Oct 2010 12:34:17 -0700

Adding to what Carlos said.

> and needs to be covered) and considering it adds too much complexity to

I'm not sure, if supporting prefixes per-interfaces is complex, or
supporting a single prefix across access networks is complex. One way to
look at it is, this is the default behavior of the base specification, the
ability to allocate a unique prefix per-interface, the natural multi-homing
behavior as per RFC-5213. Now, when we support flow-mobility, that is not
taking away this basic capability from the specification, we will continue
to support that. Additionally, if we look at this from the perspective of a
logical interface, we are truly hosting a set of prefixes for a given
interface which is the virtual/logical interface, for the same reason as
when we have added multiple prefix support to the base spec for resolving
the IESG Discuss, "retain support for the basic IPv6 link property, ability
to host multiple prefixes on a given link".

The ability to allocate prefixes per-interface, will also give the ability
to move that entire prefix as a flow aggregate between interfaces. A prefix
which was advertised on interface-1, can simply be hosted on interface-2,
with the resulting affect of flow group movement between interfaces. This
approach offers the natural ability for the network node to hint the
presence of a new prefix simply by sending a RA, with the new PIO option.
There is a natural MN-AR trigger, in the form of RA's. The MN has a clear
visibility on the hosted prefixes at a physical interface level and hence
the forwarding capability. A prefix on interface-1, or on interface-2 is
implicit by the RA hints.

This approach allows a simply flow mobility approach for deployments to
categorize flows based on APN's and move all the flows associated to an APN
from interface-1 to interface-2. A policy which states, all these flows
bound this APN, when in the presence of WLAN interface, use that interface.

Additionally, we can provide more granular approach, at a flow level, but at
the risk of lack of MN-AR hints and some assumptions. Ignoring the split
link issues, we can have a layer-2 based policy which states, any time the
MN see's a WLAN interface, flow-1, flow-2, flow-3 move it on to that WLAN
interface, irrespective of the source prefix, we can move the flow across.
The MN can assume, the network has the same forwarding state as the MN, the
MN has the understanding to differentiate between the various states of that
WLAN interface, if there is a MAG on the WLAN link, or if access security
matters, DHCP state matters, when to start forwarding packets, after the L2
attach, after the address configuration and after access authentication, in
the absence of any MN-AR hints, sure this can work with some hard
assumptions. All of this in comparison to the natural multi-homing behavior
per 5213.

So, we will document both and we can discuss what is complex and see the way
forward.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 12 Oct 2010 12:56:36 -0700

Also, I'd like to remind, the use-cases for flow mobility is not like in
Hollywood action movies. Flow-1 comes on interface-1, network triggers it
dynamically to move the flow to interface-2, the third second, while the MN
is still connected to the same set of interfaces, the network tells the MN
to move the flow back to Interface-1, because it saw another traffic
intensive flow from another MN. So, it pushes the policy to the MN, it also
triggers the MAG, which it cant do a thing about it in the absence of MN-AR
triggers, but it gets the policy for the heck of it.  I don't believe any
operator deployments are looking at this level of complexity. Lets be
realistic in the the scenarios and solutions.

IMO, Most operators are looking at simple policies, such as:

- When in the presence of WLAN, move certain type of traffic flows to WLAN,
keep my essential flows related to operator value added services to the
macro network.
- Offload most non essential traffic over WLAN, don't bring it back to EPC.

To solve this, I need the simple ability to move a set of flows, as a group,
I can manage them at the granularity of a prefix level/APN level. I don't
have to exchange complex flow templates. As part of the address assignment
procedures, the LMA can give the set of prefixes, which the MAG can host on
the link, that's all I need. I do not require complex policies on the MN, it
knows when a prefix is on a given link and when it is not, by virtue of
RA's, I don't require complex logic on the UE.

Any thing more beyond this is a bonus feature addition and that is fine with
me, we can keep ourselves busy. If any one wants to challenge me, I want to
hear first on some practical and realistic operator input on the most common
scenarios that they are interested in. So, lets take an incremental
approach, lets not overload this document with every possible scenario, on
day-1.

Sri

On 10/12/10 12:34 PM, "Sri Gundavelli" <[email-masked]> wrote:

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 12 Oct 2010 14:09:30 -0700 (PDT)

Hi Sri,
  How does a prefix become a flow description? 

Regards,

Behcet

----- Original Message ----
> From: Sri Gundavelli <[email-masked]>
> To: Sri Gundavelli <[email-masked]>; [email-masked]; "Laganier, Julien" 
><[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: Tue, October 12, 2010 2:56:36 PM
> Subject: Re: [netext] About draft-bernardos-netext-pmipv6-flowmob
>

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 12 Oct 2010 14:50:05 -0700

YOUTUBE: Flow-1: src: cafe::1, dest: babe::1, sport=x, dport=z APN:INTERNET
PANDORA: Flow-2: src: cafe::1, dest: dead::1, sport=y, dport=w APN:INTERNET
SIP:     Flow-3: src: face::1, dest: cead::1, sport=a, dport=b APN:IMS
VPN:     Flow-4: src: face::1, dest: deaf::1, sport=d, dport=c APN:ENT

Flow Groups: 1. (Flow-1, Flow-2)---> CAFE::/64
             2. (Flow-3, Flow-4)---> FACE::/64

Move Flow Group#1, by moving prefix CAFE::/64, as an aggregate. That's your
flow group description. RA with the PIO Option (CAFE::1/64) on the new link,
avoid split link.

Sri

---

From: Frank Xia <[email-masked]>
Date: Tue, 12 Oct 2010 15:31:13 -0700

Hi Sri

Do you mean different prefixes for different
flows ( or applications )?

I recalled I had some discussion with Mohana
in the mailing list regarding this assumption.

BR
Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sri Gundavelli
Sent: Tuesday, October 12, 2010 2:50 PM
To: Behcet Sarikaya
Cc: [email-masked]
Subject: Re: [netext] About draft-bernardos-netext-pmipv6-flowmob

Sri

On 10/12/10 2:09 PM, "Behcet Sarikaya" <[email-masked]> wrote:

>>> Additionally, we can provide more granular approach,  at a flow level,
but
> at
>>>  matters, DHCP state matters, when to start forwarding packets, after
the
> L2
>>> So, we will document  both and we can discuss what is complex and see
the
> way

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 15 Oct 2010 10:41:15 -0700

Sri, Carlos,

Please see some thoughts below:

Sri Gundavelli wrote:
> > and needs to be covered) and considering it adds too much complexity
> > to the solution.
> 
> supporting a single prefix across access networks is complex. One way
> to look at it is, this is the default behavior of the base specification,
> the ability to allocate a unique prefix per-interface, the natural multi-
> homing behavior as per RFC-5213.

Detailing what RFC 5213 provides us with:

- ability to create and tore down a PMIPv6 session that comprises a common set of prefixes
- a PMIPv6 session can be brought up when a new interface is brought up (HI set to 1)
- a PMIPv6 session can be moved across interface (HI set to 2)
- a PMIPv6 session can be moved between MAG for same interface (HI set to 3)

>                             Now, when we support flow-mobility, that is
> not taking away this basic capability from the specification, we will
> continue to support that. 

I think we're in agreement: The per-interface prefixes set scenario is already supported in RFC 5213, thus we do not need to provide a new mechanism for this within the flow mobility extensions. The only requirement is that we do not break working features of RFC 5213 while extending it (which is kind of obvious.)

Thus, flow-mobility extension wise, the only thing we need to be concerned with are:

- ability to tie a PMIPv6 session (with a common set of prefixes) to a logical interface hiding one or more physical interfaces
- ability to move flows anchored to a PMIPv6 session (and thus to its set of prefixes) across the physical interface below the logical interface. 

As a result, what we have a model with one or more PMIPv6 sessions, each of them being valid over a subset of the MN physical interfaces (which are hiden by a logical interface on the MN side.) The fact that some prefixes are only valid on a per-interface prefix is just a special case within that model.
 
>                         Additionally, if we look at this from the perspective
> of a logical interface, we are truly hosting a set of prefixes for a given
> interface which is the virtual/logical interface, for the same reason
> as when we have added multiple prefix support to the base spec for
> resolving the IESG Discuss, "retain support for the basic IPv6 link property,
> ability to host multiple prefixes on a given link".

This is aligned with what I wrote above: We are hosting PMIPv6 sessions that correspond to set of prefixes, over logical interfaces, which in turn corresponds to one or more physical interfaces.
 
> The ability to allocate prefixes per-interface, will also give the
> ability to move that entire prefix as a flow aggregate between interfaces. 

I'd rather say "the ability to allocate PMIPv6 sessions on a per-interface basis". This is a special case that is supported with the model we're discussing.

> A prefix which was advertised on interface-1, can simply be hosted on interface-
> 2, with the resulting affect of flow group movement between interfaces.
> This approach offers the natural ability for the network node to hint the
> presence of a new prefix simply by sending a RA, with the new PIO
> option. There is a natural MN-AR trigger, in the form of RA's. The MN has a
> clear visibility on the hosted prefixes at a physical interface level and
> hence the forwarding capability. A prefix on interface-1, or on interface-2
> is implicit by the RA hints.

I am not sure I am following you with the notion of RA trigger. 

In my opinion the RA are something that we shouldn't be concerned with in the context of the PMIPv6 protocol extensions. The only thing we have to do is to document how the logical interface makes sure that the unmodified IP stack on top of it functions properly and does not enter new failure modes due to the extensions we're building.
 
> categorize flows based on APN's and move all the flows associated to an
> APN from interface-1 to interface-2. A policy which states, all these flows

Yup. But this APN-based routing is something that is out-of-scope of this WG and has to be dealt with in 3GPP.
 
> but at the risk of lack of MN-AR hints and some assumptions. Ignoring the
> split link issues, we can have a layer-2 based policy which states, any time
> the MN see's a WLAN interface, flow-1, flow-2, flow-3 move it on to that
> WLAN interface, irrespective of the source prefix, we can move the flow
> across. The MN can assume, the network has the same forwarding state as the MN,
> the MN has the understanding to differentiate between the various states of
> that WLAN interface, if there is a MAG on the WLAN link, or if access
> security matters, DHCP state matters, when to start forwarding packets, after
> the L2 attach, after the address configuration and after access authentication,
> in the absence of any MN-AR hints, sure this can work with some hard
> assumptions. All of this in comparison to the natural multi-homing
> behavior per 5213.
> 
> the way forward.

This discussion on the flow mobility model seems productive...

--julien