George Tsirtsis escribió:
Marcelo,
Flow Movement is supposed to work in combination with DSMIPv6. Are you
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.
why would we place such a restriction?
BTW, as far as I know flow label is the least well defined aspect of
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
address specific so the flow label by itself is not sufficient.
sure, the flow description is src add, dst add and flow label
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.
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
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?
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
George
On Sun, May 17, 2009 at 10:03 AM, marcelo bagnulo braun
<marcelo at it.uc3m.es> wrote:
George Tsirtsis escribió:
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.
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
Thoughts?
George
On Sun, May 17, 2009 at 8:58 AM, marcelo bagnulo braun
<marcelo at it.uc3m.es <mailto:marcelo at it.uc3m.es>> 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 :-)
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
Hesham Soliman escribió:
On 17/05/09 3:04 PM, "marcelo bagnulo braun"
<marcelo at it.uc3m.es <mailto:marcelo at it.uc3m.es>> wrote:
Hesham Soliman escribió:
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.
what i am saying is that you don't need anything else
other than this
=> see below
As a general issue, the flow label is unlikely to be
used for this purpose
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.
=> 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.
and until it is actually _used_ in
the API. At least until recently no one was using it.
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?
=> 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
_______________________________________________
MEXT mailing list
MEXT at ietf.org <mailto:MEXT at ietf.org>
https://www.ietf.org/mailman/listinfo/mext