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

Re: Flow label versus Extension header - protocol itself

Greg Daley wrote:

Yes, I was thinking that some APIs may allow explicit access to flow
labels (perhaps as RFC3542bis), or a separate extension of to the
advanced sockets API (new socket options?)

The constant flow label would be required in this case, as it could
have particular semantics with the ULP or application.


Yep.


And when switching to a different locator pair, and some flow signaling is used, one would need to do the flow signaling for that locator pair in any case. So using a different flow label for the different locator pair shouldn't be much of an issue. 


I guess you'd only want to do the signalling when you had to:

You wouldn't want to require signalling (or a new label)
for every locator pair change, if the label was receiver unique.

By "signaling" I was referring to things like RSVP and NSIS. Those would need to be triggered for every new <source IP, dest IP, flow label> combination that needs whatever QoS is used. Thus if such protocols are used before there is a change to a different locator pair, they would need to be triggered for every new locator pair that is used for that communication. And there doesn't seem to be a need to use the same flow label across those reservations.

   Erik