Subject: [MEXT] weird idea about flow bindings

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 17 May 2009 01:47:10 +0200

Hi,

Here goes a weird idea about how to do the flow bindings.
What about if we only identify flows using the flow label?
I mean, that instead of having to define a format to describe the flows, 
we simply include the flow label value of the specific flow in the flow 
bindings rules.

This would imply basically that the MN host has the policy configured 
about which flow will flow through each CoA.
the first packet of each flow will be received through the primary CoA 
(the one with highest priority).
Upon the reception of the flow, if the MN wants to divert the flow 
through an alternative CoA,  it sends a BU with the Flow binding option, 
including the Flow label value of the flow and the BID associated to the 
CoA it wants to use for this flow.

The main drawbacks of this approach afaict is that the first packets 
will flow through the primary CoA, but i guess these should not be too 
many packets and that there is a need to send a BU per each flow that 
will be sent through a CoA other than the primary one. Maybe these are 
not too many, don't know.

The nice thing is that this is fully extensible since we never have to 
encode bits refering to the upper layer headers in the BU.

Anyway, i thought it may be good to bring this up for discussion.

Regards, marcelo

---

From: George Tsirtsis <[email-masked]>
Date: Sat, 16 May 2009 21:20:39 -0400

I am not sure I fully understand what you propose.
If I understand correctly your scheme seems to assume the following:

1) what constitutes a "flow" is something fixed and is understood by both
the MN and the HA.

2) "flows" start one at a time giving enough time to the MN, to send a BU to
the HA to label (and optionally redirect) each one, before the next starts.

These are far from safe assumptions, but maybe I did not understand your
proposal in the first place.

George

On Sat, May 16, 2009 at 7:47 PM, marcelo bagnulo braun
<[email-masked]>wrote:

> I mean, that instead of having to define a format to describe the flows, we
> simply include the flow label value of the specific flow in the flow
> bindings rules.
>
> This would imply basically that the MN host has the policy configured about
> which flow will flow through each CoA.
> the first packet of each flow will be received through the primary CoA (the
> one with highest priority).

> Upon the reception of the flow, if the MN wants to divert the flow through
> an alternative CoA,  it sends a BU with the Flow binding option, including
> the Flow label value of the flow and the BID associated to the CoA it wants
> to use for this flow.
>
> The main drawbacks of this approach afaict is that the first packets will
> flow through the primary CoA, but i guess these should not be too many
> packets and that there is a need to send a BU per each flow that will be
> sent through a CoA other than the primary one. Maybe these are not too many,
> don't know.
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>

---

From: Hesham Soliman <[email-masked]>
Date: Sun, 17 May 2009 13:34:20 +1000

The flow label should be part of any filter descriptor anyway. So at anytime
A MN can send a BU specifying that packets with flow label X should be
directed to CoA1. I'm not sure how your proposal changes/adds to this.

As a general issue, the flow label is unlikely to be used for this purpose
until we resolve it's mutability issues and until it is actually _used_ in
the API. At least until recently no one was using it.

But in any case, it should be in any flow descriptor for IPv6. We did have
it in the initial draft. But having that is not mutually exclusive with
having upper layer information IMO. Nor does it replace generic rules based
on IP addresses/prefixes.

Hesham

On 17/05/09 9:47 AM, "marcelo bagnulo braun" <[email-masked]> wrote:

> The flow

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 17 May 2009 07:01:05 +0200

George Tsirtsis escribió:
> 1) what constitutes a "flow" is something fixed and is understood by 
> both the MN and the HA.

i don't think i am assuming that
I assume that the initiator of a flow will set the flow label and keep 
it unchanged for the duration of the flow
>
> 2) "flows" start one at a time giving enough time to the MN, to send a 
> BU to the HA to label (and optionally redirect) each one, before the 
> next starts.
>

no, i am assuming that the flow starts and upon the reception of the 
first packet of the flow, the MN redirects it to the correct CoA using a 
BU message.
Basically, i am assuming that most of the flows that i care about are 
longer than one RTT between the MN and the HA. Is this safe?

Regards, marcelo

> These are far from safe assumptions, but maybe I did not understand 
> your proposal in the first place.
>
> George
>
>
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     I mean, that instead of having to define a format to describe the
>     flows, we simply include the flow label value of the specific flow
>     in the flow bindings rules.
>
>     This would imply basically that the MN host has the policy
>     configured about which flow will flow through each CoA.
>     the first packet of each flow will be received through the primary
>     CoA (the one with highest priority). 
>
>
>     through an alternative CoA,  it sends a BU with the Flow binding
>     option, including the Flow label value of the flow and the BID
>     associated to the CoA it wants to use for this flow.
>
>     The main drawbacks of this approach afaict is that the first
>     packets will flow through the primary CoA, but i guess these
>     should not be too many packets and that there is a need to send a
>     BU per each flow that will be sent through a CoA other than the
>     primary one. Maybe these are not too many, don't know.
>
>     The nice thing is that this is fully extensible since we never
>     have to encode bits refering to the upper layer headers in the BU.
>
>     [email-masked] <mailto:[email-masked]>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 17 May 2009 07:04:27 +0200

> directed to CoA1. I'm not sure how your proposal changes/adds to this.

what i am saying is that you don't need anything else other than this
> until we resolve it's mutability issues

what mutability issues are you referring to?
AFAIU, the flow label is set randomly b the source and remains unchanged 
e2e and for the duration of the flow.
>  and until it is actually _used_ in

why do we need to have it in the API? It is only imporntat the the 
source sets it to a random value and keep it unchenged e2e and for the 
duration of the flow. I understand that these conditions are met today, 
right?
> on IP addresses/prefixes.
that is exactly my point, if you use the flow label (and the source 
address) you don't need to use anything else and in partiuclar you don't 
need to embed upper layer information in the MIP BU signalling.

Regards, marcelo

---

From: Hesham Soliman <[email-masked]>
Date: Sun, 17 May 2009 19:27:51 +1000

> what i am saying is that you don't need anything else other than this

=> see below

> e2e and for the duration of the flow.

=> I thought RFC 3697 talked about it being changed en route then changed
back before it hits the destination. But I just scanned it and I can't find
this text. Maybe it was never included.

> duration of the flow. I understand that these conditions are met today,

=> But are you saying the src MIP6 module overwrites the potential flow
label set in the API? Because it is possible that an app sets the flow
label. RFC 3697 assumes the presence of an e2e mechanism to negotiate the
flow label. If not then how do you make sure it's always unique? And how do
you make sure that the CN echoes back the same value in the flow label?
And what if the CN initiated the connection?

Hesham

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 17 May 2009 14:58:00 +0200

ok, let me try again because it seems i am failing miserably to 
communicate what i want to say (or it simply so broken that people 
cannot believe what they are reading :-)

Let's try with an example.

We have the MN who has two CoAs, CoA1 and CoA2.

The MN has a policy that says that it wants flows from app1 to be 
exchanged through CoA1 (well, the policy would say that they should be 
received by the interfece in which CoA1 is configured) and that flows 
from app2 to be exchanged through CoA2 (same comment about the interface 
applies here)

In addition, MN has defined CoA1 to be the primary CoA i.e. the CoA with 
highest priority.

So, we have two different situations. Either the MN starts the 
communication or the CN starts the communication. Actually, this is 
pretty irrelevant, cause the two directions of a connections are handled 
independently. the MN will send packets from app1 through CoA1 and 
packets from app2 through CoA2 and it doesn't need any additional 
actions from the HA for outgoing packets.

Now, the difficulty is with incoming packets. the MN needs to inform the 
HA about which CoA it wants to use to receive any flow.

Suppose that the HA has no flow bindings for the MN so far.

So, suppose that the app1 in CN starts a flow to the MN. The HA will 
receive the packet and will send it though the CoA1 cause it is the one 
with higher priority. the MN is happy and there is no need to do 
anything else.

Suppose now that the app2 in the CN starts a flow to the MN. According 
to RFC3697, the CN SHOULD assign a different flow label to the packets 
belonging to this flow e.g. to this TCP connection. Let's assume it is 
actually a TCP connection to make the example more concrete.
So, app2 opens a TCP connection to MN. CN then sends the TCP SYN to the MN.
The HA receives the TCP SYN and since there is no flow binding state for 
this flow it forwards it through the CoA1 (the one with highest priority)
The MN receives the TCP SYN through CoA1 and it realizes that this is 
not compliant with its flow policy. So, it extracts the flow label 
value, the src address and the dest address and it sends a BU to the HA 
stating that the flow identified by the flow label, src add and dest add 
needs to be bound to the CoA2.
Simultaneously, it also sends the TCP SYN+ACK back to the CN.
The CN receives the TCP SYN+ACK and sends the Ack back. the HA receives 
the ACk and will forward it based on the flow binding, i.e. through the CoA.

the result is a method that never looks into higher layer information 
for setting the flows.

makes sense?

Regards, marcelo

---

From: George Tsirtsis <[email-masked]>
Date: Sun, 17 May 2009 09:16:34 -0400

Hi Marcelo, I now understand what you propose better. and it makes more
sense than I initially thought.
Two issues, though:

1) this requires the CN to cooperate i.e., make proper use of flow labels.
It is not clear to me that even if all nodes populated the flow label (which
I think is not even true), its use would be universally consistent in a way
that would ensure that the setting of the flow label by the CN would be
inline with what the MN would like to identify as a flow.

2) This does not work for IPv4 traffic.

Thoughts?
George

On Sun, May 17, 2009 at 8:58 AM, marcelo bagnulo braun
<[email-masked]>wrote:

> ok, let me try again because it seems i am failing miserably to communicate
> what i want to say (or it simply so broken that people cannot believe what
> they are reading :-)
>
> The MN has a policy that says that it wants flows from app1 to be exchanged
> through CoA1 (well, the policy would say that they should be received by the
> interfece in which CoA1 is configured) and that flows from app2 to be
> exchanged through CoA2 (same comment about the interface applies here)
>
> communication or the CN starts the communication. Actually, this is pretty
> irrelevant, cause the two directions of a connections are handled
> independently. the MN will send packets from app1 through CoA1 and packets
> from app2 through CoA2 and it doesn't need any additional actions from the
> HA for outgoing packets.
>
> Now, the difficulty is with incoming packets. the MN needs to inform the HA
> about which CoA it wants to use to receive any flow.
>
> receive the packet and will send it though the CoA1 cause it is the one with
> higher priority. the MN is happy and there is no need to do anything else.
>
> Suppose now that the app2 in the CN starts a flow to the MN. According to
> RFC3697, the CN SHOULD assign a different flow label to the packets
> The MN receives the TCP SYN through CoA1 and it realizes that this is not
> compliant with its flow policy. So, it extracts the flow label value, the
> src address and the dest address and it sends a BU to the HA stating that
> the flow identified by the flow label, src add and dest add needs to be
> bound to the CoA2.
> The CN receives the TCP SYN+ACK and sends the Ack back. the HA receives the
> ACk and will forward it based on the flow binding, i.e. through the CoA.
>
> the result is a method that never looks into higher layer information for
> setting the flows.
>
> makes sense?
>
> Regards, marcelo
>
>
> Hesham Soliman escribió:
>
>

---

From: Hesham Soliman <[email-masked]>
Date: Sun, 17 May 2009 23:23:48 +1000

Thanks fpr the long version! Yes it works of course. That's why I agree that
it should be in every filter descriptor. However, since it's not currently
used at all, I don't think we can remove upper layer information. We need to
allow both to exist until the flow label is actually used. So, to summarise:
yes by all means we have to make sure it's in every spec defining filters
(which this draft is not btw), but not the only way of defining filters.
We should also make sure the SPI is one of those parameters for instance.

Hesham

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 17 May 2009 16:03:31 +0200

George Tsirtsis escribió:
> Hi Marcelo, I now understand what you propose better. and it makes 
> more sense than I initially thought.
>
> Two issues, though:
>
according to RFC3697:

   To enable Flow Label based classification, source nodes SHOULD assign
   each unrelated transport connection and application data stream to a
   new flow. 

...

   To enable applications and transport protocols to define what packets
   constitute a flow, the source node MUST provide means for the
   applications and transport protocols to specify the Flow Label values
   to be used with their flows.  The use of the means to specify Flow
   Label values is subject to appropriate privileges (see section 5.1).
   The source node SHOULD be able to select unused Flow Label values for
   flows not requesting a specific value to be used.

So, yes but node should do this if they expect things to work properly

> It is not clear to me that even if all nodes populated the flow label 
> (which I think is not even true)
does anybody has information about the support of RFC3697 in current OSes?

> , its use would be universally consistent in a way that would ensure 
> that the setting of the flow label by the CN would be inline with what 
> the MN would like to identify as a flow. 
>
that would determine the granularity of the method
I am not sure the spectrum of choices is so big that this can be a problem
could you think of some very different criteria to define what a flow is 
that this would be an issue?
> 2) This does not work for IPv4 traffic.
i don't buy this argument. If we apply this argument, then we could 
never use the flow label for anything, since it doesn't work for IPv4.

Reagrds, marcelo

>     exchanged through CoA1 (well, the policy would say that they
>     should be received by the interfece in which CoA1 is configured)
>     and that flows from app2 to be exchanged through CoA2 (same
>     comment about the interface applies here)
>
>     In addition, MN has defined CoA1 to be the primary CoA i.e. the
>     CoA with highest priority.
>
>     communication or the CN starts the communication. Actually, this
>     is pretty irrelevant, cause the two directions of a connections
>     are handled independently. the MN will send packets from app1
>     through CoA1 and packets from app2 through CoA2 and it doesn't
>     need any additional actions from the HA for outgoing packets.
>
>     Now, the difficulty is with incoming packets. the MN needs to
>     inform the HA about which CoA it wants to use to receive any flow.
>
>     So, suppose that the app1 in CN starts a flow to the MN. The HA
>     will receive the packet and will send it though the CoA1 cause it
>     is the one with higher priority. the MN is happy and there is no
>     need to do anything else.
>
>     Suppose now that the app2 in the CN starts a flow to the MN.
>     According to RFC3697, the CN SHOULD assign a different flow label
>     to the packets belonging to this flow e.g. to this TCP connection.
>     Let's assume it is actually a TCP connection to make the example
>     more concrete.
>     The HA receives the TCP SYN and since there is no flow binding
>     state for this flow it forwards it through the CoA1 (the one with
>     highest priority)
>     The MN receives the TCP SYN through CoA1 and it realizes that this
>     is not compliant with its flow policy. So, it extracts the flow
>     label value, the src address and the dest address and it sends a
>     BU to the HA stating that the flow identified by the flow label,
>     src add and dest add needs to be bound to the CoA2.
>     The CN receives the TCP SYN+ACK and sends the Ack back. the HA
>     receives the ACk and will forward it based on the flow binding,
>     i.e. through the CoA.
>
>     the result is a method that never looks into higher layer
>     information for setting the flows.
>
>     makes sense?
>
>     Regards, marcelo
>
>
>     Hesham Soliman escribió:
>
>
>         On 17/05/09 3:04 PM, "marcelo bagnulo braun"

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 17 May 2009 16:15:27 +0200

Hesham Soliman escribió:
> used at all,
i woudl actually like to get data about this assertion. Are you certain 
that current OSes don't implement RFC3697?

>  I don't think we can remove upper layer information. We need to
Ok, this is where i come from.
I don't have any problem whatsoever with using any IP layer information 
as a flow descriptor. So, SPIs are perfectly ok to me.
I have a little problem with using transport layer information. 
Especially cause if the traffic is encrypted, we need to fall back to 
something else. In any case, there are a few transports, that are pretty 
stable and we can rely on hardcoding where to look inside the packet to 
determine what is a flow (modulo the encrypted packets)
I do have a big problem with using application layer information as a 
flow descriptor. I mean, there are millions of different apps and new 
apps are defined everyday and a not so limited number become widely 
used. I think using app bits in MIP signalling is simply a very bad 
idea. For example, let's take for instance an app protocol that it is 
propietary and it is widely used (skype for instance). You have no 
certainty which bits to look.

So, my preference here would be to:
- use IP header info in any way you want (recommended approach, 
especially since the flow label approach can discriminate every flow)
- maybe use transport info
- don not use application layer information in any case.

Makes sense?

Regards, marcelo

---

From: George Tsirtsis <[email-masked]>
Date: Sun, 17 May 2009 11:13:42 -0400

Marcelo,

Flow Movement is supposed to work in combination with DSMIPv6. Are you
suggesting the flow bindings should only work for IPv6 traffic then?
why would we place such a restriction?

BTW, as far as I know flow label is the least well defined aspect of
IPv6. How does the MN know whether a given CN marks each relevant flow
with a different flow label? Also note that flow labels are source
address specific so the flow label by itself is not sufficient.

Also the binary format
(http://tools.ietf.org/html/draft-tsirtsis-mext-binary-filters-00) in
fact allows for a very simple MN implementation if the only thing you
want to classify is flow labels. An implementation could only allow
the flow label to be set resulting in the following flow descriptor:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0|0|0|0|0|0|0|0|0|0|0|0|M| 0000 |       (M)   Flow Label
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         FB (cont)     |
     +-+-+-+-+-+-+-+

Or actually something like the above but including the source address
too (flag C), do me more correct..

If an MN implementation does not want to deal with any of the other
fields, it does not need to implement them.
In that sense multiple compatible implementations are allowed as long
as the HA implements the flow descriptors in their full complexity.

Finally note that what constitutes a "flow" could be something like
"ALL TCP Traffic", no matter which source address and what flow label
is used. How would the MN be able to say push all TCP to one CoA and
all UDP to another based on your scheme?

George

On Sun, May 17, 2009 at 10:03 AM, marcelo bagnulo braun
<[email-masked]> wrote:
>> Hi Marcelo, I now understand what you propose better. and it makes more sense than I initially thought.
>>
>> Two issues, though:
>>
>> It is not clear to me that even if all nodes populated the flow label (which I think is not even true)
>
>> , its use would be universally consistent in a way that would ensure that the setting of the flow label by the CN would be inline with what the MN would like to identify as a flow.
>
> could you think of some very different criteria to define what a flow is that this would be an issue?
>>
> i don't buy this argument. If we apply this argument, then we could never use the flow label for anything, since it doesn't work for IPv4.
>
> Reagrds, marcelo
>
>> Thoughts?
>> George
>> On Sun, May 17, 2009 at 8:58 AM, marcelo bagnulo braun <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 18 May 2009 01:32:30 +1000

> that current OSes don't implement RFC3697?

=> RFC3697 mainly states requirements. Last time I checked there was no one
using the flow label in the API and there were no flow label negotiations
except, say SIP. But it would be interesting to see if anyone is actually
using it. The point is, even if 80% of implementations are using it, we
can't make it the only was of defining flows.

> something else. 

=> Sure. Like SPI for example :)

 In any case, there are a few transports, that are pretty
> certainty which bits to look.

=> I don't advocate the use of app information either.

> - don not use application layer information in any case.

=> Makes sense to recommend that, but of course the spec needs to offer both
options for the reasons above.

Hesham

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 17 May 2009 17:34:24 +0200

> suggesting the flow bindings should only work for IPv6 traffic then?

no, i ma suggesting that for IPv6 traffic, we should use the flow label
for ipv4, we certainly need to use something else
What i am not buying is that we cannot build a method that relies in the 
flow label cause IPv4 doesn't support it. 
In other words, i think it is perfeclty ok to build our reccomended 
method relying on the usage of the flow label, and define some other 
hacks to support ipv4.
> IPv6.

but that is not the porblem of IPv6, but it is an inherent problem of 
defining a flow. The IP layer has a problem cause it is agonstic to 
flows. So, only the application knows what really a flow is. And IPv6 
does provide the means for the application to signal the packets that 
belong to flow to the IP layer i.e. the flow label.
In other words, this is a fundamental problem: IP does not knows about 
flows and we are trying that MIP which is in the IP layer to 
discriminate flows. We can either try the IP layer to guess what are the 
common bits of a flow or we can leverage on the explicit definition of a 
flow, which is what the flow label is for.
>  How does the MN know whether a given CN marks each relevant flow
> with a different flow label? 
becuase it needs to be compliant with RFC3697?
> Also note that flow labels are source
sure, the flow description is src add, dst add and flow label

> the flow label to be set resulting in the following flow descriptor:
this is my problem. I don't want to impose the HAs to be able to parse 
arbitrary bits in the application data. I think this is not the right 
way to do it. I don't think the IP layer should be snooping into 
application data bits

> all UDP to another based on your scheme?
well, you can do this based on the protocol field of the IP header
As i stated in my earlier reply to Hesham, i don't have a problem with 
using any IP header fields as flow descriptors and i may be ok with sing 
the transport header bits (not what i would preffer, but hey, you can't 
always get what you want)
My problem is with supporting application data bits as part of the flow 
description, which i really think is broken

Makes sense?

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 17 May 2009 17:48:39 +0200

Hesham Soliman escribió:
> except, say SIP.
but we don't need negotiation for this right?
the only thing that we need is that the CN sets different flow label 
values for different flows. for isntnace if each socket uses a different 
flow label, then we are ok i think

>  But it would be interesting to see if anyone is actually
> using it.
right, i would like to find out how current OSes set the flow label. For 
instance, if for each socket a different flow label value is used, then 
we should be ok, i think

>  The point is, even if 80% of implementations are using it, we
right, which is perfect cause it IP layer info. I mean, i rather use the 
SPI than the transport information

> options for the reasons above.
mmm, i am not sure i understand what you suggest we need to support in 
the spec.

I think that we could simply support flow descriptors  as follows:
MUST support flow descriptors based on IP header
MAY support flow descriptors based on transport header

I would be silent about other flow descriptors. In particular, i would 
not define in the spec means to use app data bits as flow descriptors.

would that make sense to you?

Regards, marcelo

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 18 May 2009 10:11:50 +1000

> flow label, then we are ok i think

=> Yes I understand, I was responding to the comment about RFC 3697. The
other point is, the CNs didn't set that field at all (last time I checked).
Until that happens, no one can use it for anything. It would be good to know
if that behaviour has changed.

> would that make sense to you?

=> Yes that works for me but I suspect that people will treat the MAY above
in the same way as a MUST when it comes to implementation.

Hesham

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 18 May 2009 09:21:08 -0700 (PDT)

Hi Marcelo,

  I support your proposal, I think it is inline with my previous call for a new look into this problem.
  My only comment is on the BID. Why should MN send a BID? Since HA trusts MN, MN sending CoA for the first time should register this CoA. This would make things even simpler.

Regards,

Behcet

________________________________
From: marcelo bagnulo braun <[email-masked]>
To: Hesham Soliman <[email-masked]>
Cc: mext <[email-masked]>
Sent: Sunday, May 17, 2009 7:58:00 AM
Subject: Re: [MEXT] weird idea about flow bindings

ok, let me try again because it seems i am failing miserably to communicate what i want to say (or it simply so broken that people cannot believe what they are reading :-)

The MN has a policy that says that it wants flows from app1 to be exchanged through CoA1 (well, the policy would say that they should be received by the interfece in which CoA1 is configured) and that flows from app2 to be exchanged through CoA2 (same comment about the interface applies here)

In addition, MN has defined CoA1 to be the primary CoA i.e. the CoA with highest priority.

So, we have two different situations. Either the MN starts the communication or the CN starts the communication. Actually, this is pretty irrelevant, cause the two directions of a connections are handled independently. the MN will send packets from app1 through CoA1 and packets from app2 through CoA2 and it doesn't need any additional actions from the HA for outgoing packets.

Now, the difficulty is with incoming packets. the MN needs to inform the HA about which CoA it wants to use to receive any flow.

So, suppose that the app1 in CN starts a flow to the MN. The HA will receive the packet and will send it though the CoA1 cause it is the one with higher priority. the MN is happy and there is no need to do anything else.

Suppose now that the app2 in the CN starts a flow to the MN. According to RFC3697, the CN SHOULD assign a different flow label to the packets belonging to this flow e.g. to this TCP connection. Let's assume it is actually a TCP connection to make the example more concrete.
So, app2 opens a TCP connection to MN. CN then sends the TCP SYN to the MN.
The HA receives the TCP SYN and since there is no flow binding state for this flow it forwards it through the CoA1 (the one with highest priority)
The MN receives the TCP SYN through CoA1 and it realizes that this is not compliant with its flow policy. So, it extracts the flow label value, the src address and the dest address and it sends a BU to the HA stating that the flow identified by the flow label, src add and dest add needs to be bound to the CoA2.
Simultaneously, it also sends the TCP SYN+ACK back to the CN.
The CN receives the TCP SYN+ACK and sends the Ack back. the HA receives the ACk and will forward it based on the flow binding, i.e. through the CoA.

the result is a method that never looks into higher layer information for setting the flows.

makes sense?

Regards, marcelo

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 19 May 2009 18:37:33 -0400

Hi Marcelo,

> cannot believe what they are reading :-)

I think it is a cool idea but it is very hard to realize in practice 
since it needs CNs to be changed.

> belonging to this flow e.g. to this TCP connection. 

This is the crux of the issue. Almost every implementation I have seen 
sets the flow label to zero. This falls under the category "A source 
node which does not assign traffic to flows MUST set the Flow Label to 
zero.". Add to this the fact that compliance to RFC3697 is completely 
optional (it is not even mentioned in RFC4294), and this task quickly 
becomes pretty improbable.

Thanks
Suresh

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 19 May 2009 15:50:33 -0700

Hello folks,

I've been following some of this discussion from afar, please excuse
if I am not up to speed...

> since it needs CNs to be changed.

Right.  This seems very much the point.  If we are going to enable the use
of flow labels, CNs need to be changed.  The application that wants to
have flows will have to run on the mobile and on the CN.

But this seems perfectly fine, even desirable, to me.  Am I missing
something?

For an application that wants to make a flow happen that doesn't
use the flow label, is it somehow imagined that the application will
not have to run on the CN?

>> According to RFC3697, the CN SHOULD assign a different flow label to 
>> the packets belonging to this flow e.g. to this TCP connection. 
>

Implementation of what?  Implementation of Mobile IP?  Implementation of 
IPv6?
I guess the application would have to use something to indicate that the 
flow
label should NOT be zero.  I still am not really seeing what's wrong 
with that.

In brief, since applications today do not use the flow label, I don't 
see what's
wrong with the flow label being zero.  When applications are built that 
need to
use the flow label, they'll have to have operating systems support to do it.

Thanks for any light you can shed on this.

Regards,
Charlie P.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 20 May 2009 02:36:30 +0200

> becomes pretty improbable.
right
i am slowly understanding this is the case
I think we should update rfc3697 to obtain a better use of the flow 
label, but i agree that its usage for flow bindings can not be immediate 
(i.e. with current implementations)

Regards, marcelo

---

From: "Wassim Haddad" <[email-masked]>
Date: Tue, 19 May 2009 22:42:36 -0500

Hi,

But this seems perfectly fine, even desirable, to me.  

=> Me too.

Regards,

Wassim H.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 20 May 2009 15:02:38 +0200

Charles E. Perkins escribió:
>
> Implementation of what?  Implementation of Mobile IP?  Implementation 
> of IPv6?
> I guess the application would have to use something to indicate that 
> the flow
> wrong with the flow label being zero.  When applications are built 
> that need to

I agree that if the application wants to define a flow i.e. set the flow 
label, that should be honored. So no argument here.

The question is whether a lower part of the stack could also have an 
idea of what a flow is.

My suggestion is that packets belonging to a connected socket (either 
TCP or UDP) by default form a flow.

So, i would like to change rfc3697 in the follwoing way:
If the application sets the flow label, then it must be honored.
If the application does not set the flow label, then the stack assign a 
rando flow label value for each connected socket and packets from that 
socket must carry the selected flow label.

Regards, marcelo

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 20 May 2009 09:29:11 -0400

Hi Charlie,
   Always good to hear from you :-)

> But this seems perfectly fine, even desirable, to me.  Am I missing

Yep. While I agree this is desirable and possible in the MNs, we are 
talking about the CNs.

> not have to run on the CN?

This is not the point. If the application sets the flow label, the OS 
will honor it (at least in all the cases I have seen), but the point 
here is that the IPv6 stack needs to AUTOMATICALLY set the flow label 
for each new flow. i.e. every new connect() results in a new NON-ZERO 
flow label.

> Implementation of what?  Implementation of Mobile IP?  Implementation of 

IPv6. Again, we are talking about CNs here. I do not see issues with the 
  MN being updated to support this concept.

> label should NOT be zero.  I still am not really seeing what's wrong 

Nothing. Except that we are not talking about flow aware applications. 
We are talking about flow aware OSs automatically assigning flow labels.

> Thanks for any light you can shed on this.

Hope that clarifies my position.

Thanks
Suresh

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 20 May 2009 08:26:36 -0700 (PDT)

Hi Marcelo,
  The problem with 3697 seems to be not its contents but its deployment status.
I would agree with your proposed modification but how do we address the problem of getting it used? In mobile environments?

Regards,

Behcet

----- Original Message ----
From: marcelo bagnulo braun <[email-masked]>
To: Charles E. Perkins <[email-masked]>
Cc: mext <[email-masked]>
Sent: Wednesday, May 20, 2009 8:02:38 AM
Subject: Re: [MEXT] weird idea about flow bindings

Charles E. Perkins escribió:
> 
> Implementation of what?  Implementation of Mobile IP?  Implementation of IPv6?
> I guess the application would have to use something to indicate that the flow
> label should NOT be zero.  I still am not really seeing what's wrong with that.
> 
> In brief, since applications today do not use the flow label, I don't see what's
> wrong with the flow label being zero.  When applications are built that need to

I agree that if the application wants to define a flow i.e. set the flow label, that should be honored. So no argument here.

The question is whether a lower part of the stack could also have an idea of what a flow is.

My suggestion is that packets belonging to a connected socket (either TCP or UDP) by default form a flow.

So, i would like to change rfc3697 in the follwoing way:
If the application sets the flow label, then it must be honored.
If the application does not set the flow label, then the stack assign a rando flow label value for each connected socket and packets from that socket must carry the selected flow label.

Regards, marcelo