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

[Marie-Jose Montpetit <marie@mjmontpetit.com>]

I agree and yes we need to get a time stamp higher in the stack for (as
mentioned below) delay and jitter but could also for some time
sensitive applications.

/mjm

> -------- Original Message --------
> Subject: Re: A proposal for a link timestamp option for ULE/GSE -
> Comments?
> From: Georgios Gardikis <gardikis@iit.demokritos.gr>
> Date: Tue, February 27, 2007 5:40 am
> To: ipdvb@erg.abdn.ac.uk
> 
> 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.
> >
> >
> >
> >