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

Re: A proposal for a link timestamp option for ULE/GSE - Comments?



Are there timing constraints on the PCR that you would expect to need for GSE, that would imply a certain required timestamp resolution?

Gorry

Georgios Gardikis wrote:

It seems quite a good idea.
We often come to the point where we need to measure delay and jitter over DVB networks, and we have no choice but proprietary, IP-based methods. Including a timestamp at the encapsulation stage could be quite handy. Also, in the GSE case (no MPEG-2 TS), this extension could act as a new PCR, providing encapsulator (rather than multiplexer) clock reference.

George

----------

Dr. Georgios Gardikis
Associate Researcher
NCSR "Demokritos", Institute of Informatics and Telecommunications
Athens 153 10, Greece
Tel: +30 210 650 3108
Fax: +30 210 653 2175



Gorry Fairhurst wrote:


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.