[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Flow label versus Extension header



Pekka Savola wrote:
On Mon, 25 Apr 2005, Erik Nordmark wrote:

This isn't the only option. With receiver-based tag allocation, then the receiver can choose which locators it advertises for which contexts. For instance, a receiver can have multiple locators in each prefix and keep them separate. So {P1:X, P2:Y} can use tag=1 and be associated with one context, and {P1:Z, P2:W} can use tag=1 and be associated with a different context. Of course, if the host doesn't do this, then it can assign the tags to that it never needs to look at the locators in order to lookup the context.


I'm a bit confused -- we're still talking about flow label and extension header/destination option both, right?

I was (apparently not clearly) restricting my comments about receiver-based allocation to the case when we don't overload the flow label as a context tag, but instead carry a tag explicitly somewhere else in the packet (e.g., in a new extension header or destination option)


How would one perform receiver-based tag allocation with flow labels, because the flow label is allocated when the sender sends out a first packet and cannot be changed since?

One wouldn't.
Unless we are told that it is ok to have the transmitting shim start using a different flow label once the shim state has been set up with the peer. But my assumption is that this would cause too much pain for other usage of the flow label.


   Erik