Re: Header extension format differences between RFC4326 and draft-ietf-ipdvb-ule-ext-04.txt

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

Hello Fausto,

See the answer in-line. Hope this clarifies things for you,

best wishes,

gorry


Fausto Vieira wrote:
> Hello all,
>
> I missed the discussion on the draft-ietf-ipdvb-ule-ext-04.txt so my 
> question has probably been raised before:
>
> Why is it that for the timestamp extension header, the format is:
>
>    0               7               15              23              31
>    +---------------+---------------+---------------+---------------+
>    |     0x03      |      0x01     |       time stamp HI           |
>    +---------------+---------------+---------------+---------------+
>    |         time stamp LO         |            Type               |
>    +---------------+---------------+---------------+---------------+
>
>         Figure 7 The format of the 32-bit Timestamp Extension Header
>
> where the HLEN (0x03) is at the start of the extension header, when in 
> the RFC4326 the extension headers are defined as:
The first byte, 0x03, contains the HLEN
- i.e in this case, 3 16-bit words, from RFC4326:
"3    Indicates an Optional Extension Header of length 6B (Type + 4B)"

The IANA has assigned the H-Type of 1 decimal to the timestamp option:
http://www.iana.org/assignments/ule-next-headers

The entry is:
 Type    Name                        H-LEN   Reference
------   --------------------------  -----   ---------
  257    Time-Stamp                   3  [RFC-ietf-ipdvb-ule-ext-01.txt]

This is a bit cryptic, but entries for Optional Extensions are recorded 
as 256+H-Type, or in hex 0x1hh where hh is the H-Type.

So, the next field is 0x01. This and the previous byte together forms 
the 16-bit value that identifies this Extension Header.

>           0                   1
>           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>          |0 0 0 0 0|H-LEN|    H-Type     |
>          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>   Figure 7: Structure of ULE Next-Header Field
>
>
> Where it is stated that the H-Type is 8-bit and not 16-bit. To my 
> knowledge, Ethertype should always be 16-bit.
RFC4326 states:
"The H-Type is a one-byte field that is either one of 256 Mandatory
   Header Extensions or one of 256 Optional Header Extensions."
- so this forms the second byte of an extension header.

> However, my question is:
> What is the meaning of the 0x01 byte in the Timestamp Header?
> Is this the  1 microsecond resolution value or is this some type of byte
> alignment?
See above.
> Many thanks
>
> Fausto Vieira