[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