Subject: [MEXT] Flow rules directionality

From: Michael Eriksson <[email-masked]>
Date: Tue, 9 Jun 2009 10:24:05 +0200

I think that the discussion regarding flow rules directionality is
somewhat awry, and not as open as it could be...

Here are some comments regarding three arguments that are used in the
discussion.

1. "Only the MN knows enough to construct the flow rules"

The truth is that the knowledge is spread between the HA and the MN.
Some cases where the HA knows more than the MN:

- It has access network information. A typical case is an HA that is
  also a 3GPP GGSN/PDN-GW.

- Some applications are implemented in an operator's service network.
  All the application logic is in the network, and the MN only
  contains a "thin" client. The HA will have "out-of-band"
  communication with the server in the service network.

In practice, some information must be transmitted between the MN and
HA to make good flow rules. But why would that information have to be
transmitted as "high-level policies" from the HA to the MN? In some
cases, it could be better for the MN to transmit its information to
the HA, which would then do all the decision making (i.e., rule
generation). This would simplify the MN, which is a good thing in some
scenarios (say cost reduced mobile phones).

Some terminals (operator branded mobile phones?) may only contain
clients for applications in the operator services network, and then
the HA will know about all flows and the MN will not have to send any
information before rule generation. The HA can look in the binding
cache to see what interfaces work on the MN.

2. "The HA can't know what access is used for a particular CoA"

The MN and HA must have a prior agreement on what BIDs the MN should
use, but that is trivial. For example, the MN always uses BID 10 for
its HSPA interface and BID 11 for its WiFi interface.

3. "There is no reasonable use case for HA -> MN rule transfer"

This argument is plain silly, IMHO. Obviously, people see a need to
send rules from HA to MN. Choosing a solution with artificial
limitations just because some vocal people don't want some reasonable
functionality is not very impressive...

But this is really a non-issue: Just read the working group charter.
The rule transfer shall be bidirectional. If anyone wants to recharter
(at this late moment), that is a separate discussion.

Regards,
Michael