| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Kevin, That is a good point. Actually dropping the C-flag and in general being able to redefine packet payload based on the pkt_type kind of makes the whole extended_header_space
concept questionable. We already took this step by defining subtypes for control packets. - Jouni From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of Bross, Kevin All, Earlier on, we had a bit in the header to indicate whether or not we had an extended header (32 bits of data immediately preceding the payload). Since that time, we agreed
to absorb the bit into the pkt_type field, so we had more flexibility in packet types (we wouldn’t necessarily need to have a standard and extended header version of each packet type). This makes sense. Since there’s no longer a single bit to say whether or not there’s an extended header, are we now limited to extended headers only being 32 bits? Since the packet type defines
the format of the header after the first 48 bits, why couldn’t the definition for that packet type define whether the extended header portion is 16, 32, 48, 64, 80, or 96 bits? (I’m assuming we’d at least want to be on 16-bit boundaries, if not 32.) I don’t
see a solid reason to limit any extended headers to only 32 bits. That said, I haven’t though through the implications of what this does to our representation of packet formats in the spec. I would expect that the definition of each specific
packet type would indicate the length of any extended header portion, and the examples would show this specific header format. For a given packet type, you can look up exactly how long the header is—there is no variation in header length for a given packet
type. Thoughts? --kb |