[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hello Gorry,

Many thanks for the explanation.
I just have one follow up question:
Is the 257 (0x0101) the Next-header Type that appears in the Type field before the Timestamp extension (probably in the ULE header)?
Couldn't there be a problem if the Next-header Type field (257) and the H-type (1+256) don't match? 

Best regards

Fausto


Gorry Fairhurst wrote:

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