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