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.