I've written the propsoal below as a candidate (if useful) for
inclusion in the ULE extension header draft.
I realise there may be some debate about how to fix a sensible
timestamp value - so here is a first attempt via the list to see if
others have any comments or ideas...
Clearly there are many options for representation, including ...
"A resolution of 20 microseconds. The 32-bit value therefore
indicates the number of 20 microsecond ticks past midnight Universal
Time when the timestamp option was inserted, right-justified to the
32-bit field."
All thoughts are welcome!
Best wishes,
Gorry
---
Timestamp Extension Header
The timestamp extension is designed to support monitoring and
measurement of ULE performance over a link to provide indications of
the quality of an operational ULE link. It may be particularly
useful for GSE links (where significant complexity exists in the
scheduling provided by the lower layers). The extension permits an
Encapsulator to insert an extension header while forming an SNDU.
This extension may be (optionally) checked at the Reciever.
Possible uses of this extension include:
* Validation of in-sequence ordering per Logical Channel,
* Measurement of the one-way delay (when synchronised with the sender)
* Measurement of PDU Jitter introduced by the link,
* PDU loss (with additional information from the sender).
>>> IANA please insert a value for the H-Type from the Next-Header
Registry in the sentence below, and the figure following <<<
The Timestamp Extension Header is specified by the IANA-assigned
H-Type of 0xTBD. The format of the Timestamp extension is shown in
figure XX below.
0 7 15 23 31
+---------------+---------------+---------------+---------------+
| 0x03 |H-Type = 0xTBD | time stamp HI |
+---------------+---------------+---------------+---------------+
| time stamp LO | Type |
+---------------+---------------+---------------+---------------+
This extension is an Optional Extension Header ([RFC4326], Section 5).
Figure 2 shows the format of this extension with a HLEN value of 3
indicating a timestamp of length 4B plus a Type field.
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 timestamp option was inserted,
right-justified to the 32-bit field. Systems unable to insert
timestamps at the specified resolution may use an arbitary (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 an SNDU, or the presence of a further
Next-Header, as defined in [RFC4326], Section 4.4.
This is an Optional Extension Header, Receivers that do not
implement, or do not wish to process the Timestamp Extension MAY
skip this extension and continue to process the remainder of the SNDU.