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
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.
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?
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.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.
Regards, marcelo
Hesham
On 17/05/09 9:47 AM, "marcelo bagnulo braun" <marcelo at it.uc3m.es> wrote: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.The flow Regards, marcelo_______________________________________________ MEXT mailing list MEXT at ietf.org https://www.ietf.org/mailman/listinfo/mext