Re: GloballyUniqueID duplicates
At 18:43 16/06/98 -0700, you wrote:
From: Douglas Clowes[SMTP:dclowes@OZEMAIL.COM.AU] On reading the text in H.225.0 describing the construction of a globally unique identifier, it seems to me that duplicates are possible if the clock has not advanced since the last identifier was generated.
That's what the clock sequence value is for.
Paul Long Smith Micro
Perhaps, but on my reading, it's not what the document says!
Douglas Clowes OzEmail Interline
According to H.225.0 section 7.6:
"The clock sequence is required to detect potential losses of monotonicity of the clock."
...and...
"While a node is operational, the GloballyUniqueID generator always saves the last UTC used to create a GloballyUniqueID. Each time a new GloballyUniqueID is created, the current UTC is compared to the saved value and if either the current value is less (the non-monotonic clock case) or the saved value was lost, then the clock sequence is incremented modulo 16,384, thus avoiding production of duplicate GloballyUniqueIDs."
The obvious interpretation :-) is that the clock sequence is incremented when the clock value of the previous GloballyUniqueID and current clock do not allow unique identification. I'd be glad to modify the text to make this clear.
Perhaps we could also add clarifying text to the implementors guide.
Glen
Douglas Clowes wrote:
At 18:43 16/06/98 -0700, you wrote:
From: Douglas Clowes[SMTP:dclowes@OZEMAIL.COM.AU] On reading the text in H.225.0 describing the construction of a globally unique identifier, it seems to me that duplicates are possible if the clock has not advanced since the last identifier was generated.
That's what the clock sequence value is for.
Paul Long Smith Micro
Perhaps, but on my reading, it's not what the document says!
Douglas Clowes OzEmail Interline
-- Glen Freundlich ggf@lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA
participants (2)
-
Douglas Clowes
-
Glen Freundlich