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

From: Fausto Vieira <[email-masked]>
Date: Sat, 01 Dec 2007 13:52:00 +0100

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 knowledge, Ethertype should always be 16-bit.

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?

Many thanks

Fausto Vieira

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 01 Dec 2007 21:17:08 -0800

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:
> 
> 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.

> 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.

> Is this the  1 microsecond resolution value or is this some type of byte
See above.

---

From: Bernhard Collini-Nocker <[email-masked]>
Date: Sun, 02 Dec 2007 13:45:37 +0100

Hello Fausto,

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.

> 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

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).

> Fausto Vieira

Hope that helped further,
Bernhard

---

From: Fausto Vieira <[email-masked]>
Date: Sun, 02 Dec 2007 14:12:14 +0100

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:
>> where the HLEN (0x03) is at the start of the extension header, when 
>> in the RFC4326 the extension headers are defined as:
>>
> 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.
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 02 Dec 2007 08:34:13 -0800

No - each H-Type is only specified for the HLEN values described in the 
IANA registry, e.g. in this case 0x0101 would simply be invalid and 
ignored by the receiver (it would skip these bytes without interpreting 
them).

GVorry