This doc is mostly OK, but if it is going to specify that the flow label be unique (within the source/dest addr space), it also needs to specify for how long that needs to remain true.
Comparisons with TCP ISN's have been made, and that's fine - but with TCP, the period within which an ISN should not be reused is known - one technique a TCP implementation can use, other than stable storage (or other ways) is simply to abstain from using any ISNs (that is, from sending packets) for a set period after a restart. While that's hard for TCP, and so few implementations these days actually force the node to remain silent for minutes after a restart, with flow labels, the existence of the 0 value, mitigates this, and would allow a node to simply not use flow labels for a period after a restart. But only if we have some idea what that period is to be. There has to be a period, or after 2^20 - 1 flows between a source and a destination, there could never be another. The period needs to be explicit (either a constant, or algorithmically derivable). Stacks need to know what it is, and routers need to have some guidance on how long idle state might usefully be retained (without constraining them, beyond what the flow setup protocol does, to actually do anything at all with flows). 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. kre -------------------------------------------------------------------- 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] --------------------------------------------------------------------
