>When we get to APIs (the other issue discussed here recently), I
>suspect that we're going to need a mechanism to set a specific value
>as the flow label (and the application would be resonsible for
>ensuring it was valid to use), a mechanism to simply set a new flow
>label, without caring about its value (in which case the stack would
>apply the uniqueness constraint - which might then mean dividing the
>flow label space (for that stack) into some available for apps to
>set, and some for the kernel, or the bookkeeping would get real hard),
>and a mechanism to set no flow label. This can't be directly died to
>sockets, as multiple of those might want to be using the same label
>(though one way to do that would be to have a label picked, then a method
>to obtain the value selected, then force that into the other sockets).
>Nor can it be tied to bind/connect sys calls - the lifetime of a label
>and the lifetime of a TCP connection (or the thing which UDP gets when
>connect is used) aren't necessarily related. Using those to supply
>default labels, when there is no other app request, would mean mods to
>less applications though.
i don't think we need to un-tie flowlabels and sockets, at least
within the default behavior. it complicate things too much (and if we
add a new system call, we'll need to go through POSIX/XNET/whatever,
which will be a lot of pain).
for normal usage 1:1 relationship between socket and flowlabel should
be ok. i'll try to think more about how i should provide user
override for flowlabel values.
itojun
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
