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

[Bernhard Collini-Nocker <bnocker@cosy.sbg.ac.at>]

Hello Fausto,

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:


>           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

in RFC4326 as above.

> knowledge, Ethertype should always be 16-bit.

The introduction of "5.  Extension Headers" in RFC4326 reads:
   A ULE Extension Header is identified by a 16-bit value in the Type
   field.  This field is organised as a 5-bit zero prefix, a 3-bit H-LEN
   field, and an 8-bit H-Type field, as follows:
           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     |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


So, the H-Type field is NOT the Ethertype. Instead the 5+3+8 corresponds
to Ethertype, whose values less then 1536 are "(ab)used" for ULE
extension headers.

Actually RFC4326 "5.  Extension Headers" starts with this explanation:

   This section describes an extension format for the ULE encapsulation.
   In ULE, a Type field value less than 1536 decimal indicates an
   Extension Header.  These values are assigned from a separate IANA
   registry defined for ULE.

> However, my question is:
> What is the meaning of the 0x01 byte in the Timestamp Header?

First, in binary, the 0x03 reads 00000011 or in above syntax 00000 + 011
standing for (again according to RFC4326) an optional extension of
length 6 Bytes consisting of Type + 4 bytes.

   The H-LEN Assignment is described below:
   0    Indicates a Mandatory Extension Header
   1    Indicates an Optional Extension Header of length 2B (Type only)
   2    Indicates an Optional Extension Header of length 4B (Type + 2B)
   3    Indicates an Optional Extension Header of length 6B (Type + 4B)
   4    Indicates an Optional Extension Header of length 8B (Type + 6B)
   5    Indicates an Optional Extension Header of length 10B (Type + 8B)
   >=6  The combined H-LEN and H-TYPE values indicate the EtherType
        of a PDU that directly follows this Type field.
   The H-LEN value indicates the total number of bytes in an Optional
   Extension Header (including the 2B Type field).

Secondly, the 0x01 is to be interpreted according to RFC4326 as:
   The H-Type is a one-byte field that is either one of 256 Mandatory
   Header Extensions or one of 256 Optional Header Extensions.  The set
   of currently permitted values for both types of Extension Headers are
   defined by an IANA Registry (section 15).  Registry values for
   Optional Extensions are specified in the form H=1 (i.e., a decimal
   number in the range 256-511), but may be used with an H-Length value
   in the range 1-5 (see example in section 5.3).
"4. IANA Considerations" of draft-ietf-ipdvb-ule-ext-04.txt reads:
      Type      Name                    H-LEN   Reference
      257:      Timestamp                3      Section 3.3

I guess the confusion results from the fact that the binary
representation of the Timestamp optional header is 00000 011 00000001
whose decimal representation is 769. Instead, it is just interpreted
differently, because the range of optional headers is 256-511 where the
0x01 (H-Type) is indicating type 257. Before that, H-LEN=3 is indicating
6 bytes length of which 4B are for the timestamp value and 2B for the Type.

> Is this the 1 microsecond resolution value or is this some type of byte
> alignment?

No, not at all, although the resolution is 1 microsecond.

The 0x01 is the optional header of type 0x01 or 257.

draft-ietf-ipdvb-ule-ext-04.txt further defines it as:
   The extension carries a 32-bit value (time stamp HI plus time stamp
     LO). The specified resolution is 1 microsecond. The value therefore
indicates the number of 1 microsecond ticks past the hour in Universal
Time when the PDU was encapsulated. This value may be earlier than the
time of transmission due for example to Packing, queuing and other
Encapsulator processing. The value is right-justified to the 32-bit
field. Systems unable to insert timestamps at the specified resolution
may use an arbitrary (and varying) value to pad the unused
least-significant bits.
The last two bytes carry a 16-bit Type field that indicates the type of
payload carried in the SNDU, or the presence of a further Next-Header
([RFC4326], Section 4.4).


> 
> Many thanks
> Fausto Vieira

Hope that helped further,
Bernhard