[pcap-ng-format] Proposed new Alternative Packet Block

[Guy Harris]

On Aug 13, 2016, at 8:57 PM, Serge Aleynikov <serge at aleynikov.org> wrote:

> ​So, with this revision, let's ​modify the layout of this option type, and also for the purpose of preserving alignment, let's keep the code/value 2 octets each:
> 
> ​ 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
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |0 0 1|      Option Code        |         Option Value          |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Hence, revised option codes become (with added apb_iface_id option):
> 
> Options:
>    Name          Code    Length  Multiple?  Description
>    apb_opt_size  0x2001  -       no         Total byte size of options
>    apb_orig_len  0x2002  -       no         Packet's Original Length

That means that the APB can't be used if the original length was > 65535.

Preserving alignment for short options might not be *that* important if supporting packets > 65535 bytes in length *is* important.

>>>    4-11     Compression type
>>>                 0  = uncompressed
>>>                 1  = lzw
>>>                 2  = gzip
>>>                 3  = bzip2
>>>                 4  = zip
>>>                 5  = 7z
>>>                 6  = lzo
>>>                 7  = ucl
>>>                 8  = snappy
>>>                 ...
>> 
>> So that indicates the form of compression used on the packet data?
> 
> ​Right, to conserve space, pcap-ng writing app​lication could choose to compress packets. One thought here is that perhaps that should be a file-level setting in the Interface Description Block rather than on the per-packet basis as proposed here?

If there's no need to compress different packets with different compression mechanisms (or to compress some but not all packets), putting it in the IDB would make sense.

However, that wouldn't apply to other block types - a file has to be readable by programs that don't understand that option, so the other block types can't support compression. 

>> There's no ​​FCS length field; do these packets have an FCS iff the "FCS length" field for interface 0's IDB is non-zero (so that all packets for that interface, whether they were transmitted by this host or received by this host, either have an FCS or don't have an FCS)?
> 
> ​Wouldn't that frame check sequence be part of the packet data?

Yes, but there needs to be a way to indicate whether it's present, as it's not *always* part of the packet data.  For the EPB, there's both the IDB indication and a per-frame indication, in case either

	1) the FCS length changes over time (e.g., if the presence or size are changed by negotiation in the middle of a PPP connection)

or

	2) not all frames have an FCS (e.g., if received frames have one but transmitted frames don't).

For the SPB, the FCS must be present, or absent, in all frames, and, if it's present, it must have the same length in all frames, as there's no per-frame indication.

For the APB, if there's no per-frame FCS indication, it must be present, or absent, in all frames, and, if it's present, it must have the same length in all frames.