[ntar-workers] PCAP-NG / Interface ID size / Drops Counter size ?
Hannes Gredler
hannes at juniper.net
Wed Feb 22 13:56:26 GMT 2006
Guy Harris wrote:
> (I'm not sure if Hannes is on ntar-workers; if not, he might want to
> join....)
just did that - tx for the note;
> On Feb 21, 2006, at 2:05 PM, Gianluca Varenni wrote:
>
>> My opinion is that we should add a new packet block to the spec,
>> similar to the current packet block:
>>
>> 0 1 2 3
>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Interface ID |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Timestamp (High) |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Timestamp (Low) |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> ...
>
> If we're adding a new packet block to the spec, should the Timestamp
> (High) field be extended to 64 bits, or do we expect that this file
> format won't still be used in 2038?
makes sense - or at least reserve 32-bits ahead of the Timestamp high.
/hannes
More information about the ntar-workers
mailing list