RE: New HE for timing information, including SCT/ERT

Hi All

The proposal assumes no one has the requirement to signal more than a
single timestamp in a single packet.

If you have this requirement, speak up or be left in need.

Cheers, Rod.


>-----Original Message-----
>From: ext Vincent Roca [mailto:[email protected]] 
>Sent: 12 December, 2005 10:56
>To: Rmt@ietf. org; Mark Watson
>Cc: Paila Toni (Nokia-M/Espoo); Walsh Rod (Nokia-NRC/Tampere); 
>Bouazizi Imed (Nokia-NRC/Tampere); Vincent Roca
>Subject: New HE for timing information, including SCT/ERT
>
>Dear All, dear Mark,
>
>After an internal discussion on the SCT/ERT topic and on the 
>draft-jansky-alc-timestamp-extension-00.txt proposal, we came 
>to the following conclusions. As usual, comments are welcome.
>Best Regards,
>
>   Toni, Rod, Imed, Vincent
>
>---------
>
>1- we are proposing to remove the SCT and ERT fields from the 
>LCT header and to create a new Header Extension dedicated to 
>timing aspects.
>
>2- since the SCT/ERT field are removed, the associated T and R 
>one bit flags are also removed from the LCT header. These two 
>bits can now either be "reserved for future use" or be added 
>to the "PSI" bits (for a total of 4 PSI bits then).
>((Toni is in favor of 4 PSI bits))
>
>3- the new HE is used to carry timing information of various 
>types/semantics, defined below.
>
>4- we are proposing a general HE, not something specific to 
>FLUTE, even if some use-cases are more related to the FLUTE 
>CDP. In particular, this extension can also be used with NORM, 
>when the associated use-case makes sense.
>((TO DO: ask the opinion of the NORM authors))
>
>5- the LCT HE uses the following format:
>
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |   HET = 65    |    HEL >= 2   |         Use (bit field)       |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                       first time value                        |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   ...            (other time values (optional)                  ...
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>5.1- the "Use-field" of the LCT HE indicates the semantic of 
>the following time value(s) 0x00 = Unspecified
>0x01 = SCT-flag (32 bit time value)
>0x02 = ERT-flag (32 bit time value)
>0x04 = SDF-flag (32 bit time value)
>	(corresponds to the "Session Last Change" proposal
>	of draft-jansky-alc-timestamp-extension-00.txt)
>0x08 = reserved flag, set to 0
>0x10 = reserved flag, set to 0
>0x20 = reserved flag, set to 0
>0x40 = reserved flag, set to 0
>0x80 = reserved flag, set to 0
>0x0100 = reserved flag, set to 0
>....
>0x8000 = reserved flag, set to 0
>
>5.2- in case of SCT and SDF, the time value transported in the 
>HE are the 32 most significant bits of a 64 bit NTP timestamp 
>(number of seconds since January 1900).
>
>5.3- in case of ERT, the time value transported in the HE is 
>the number of (TBD: seconds or milliseconds, see NOTE_3 below) 
>till the end of session.
>
>5.4- several time "time value" fields can be present in a 
>given HE, depending on the "Use-field". When several "time 
>value" fields are present, they must appear in the order 
>specified by the associated bit value:
>SCT (if present) - ERT (if present) - SDF (if present) - etc.
>
>5.5- current time values are 32 bit long, but future values 
>might be 64 bit long, e.g. to carry a full 64 bit NTP timestamp.
>"Use field" 0x01 to 0x80 are reserved for 32 bit time values, 
>while "Use field" 0x0100 to 0x8000 are reserved for 64 bit time values.
>The motivation for this split is to enable clients to skip 
>"time values" corresponding to Use cases they don't support 
>while being able to process supported time values (if any).
>
>5.6- the total HE length is carried in the HEL, since the 
>current HE is of variable length. It also enables clients to 
>skip this HE altogether if not supported.
>
>
>6- in case of FLUTE, the FDT Expiry time and the SCT/"Session 
>last change" MUST refer to the same clock at the sender.
>
>7- using NTP time means that the sender and clients are 
>synchronized, at least loosely (loosely can be sufficient 
>since time is often in unit of seconds).
>(NB: Note that this is also an assumption we have with the 
>TESLA authentication scheme...)
>
>
>---------------
>
>NOTE_1: on the use of the current SCT field in the LCT header
>(Toni) I've been asking around and my feeling is that nobody 
>really needs SCT.
>(Toni) At least OMA BCAST, DVB IPDC, 3GPP MBMS and 3GPP2 BCMCS.
>(Toni) Regarding these groups, my opinion is that we can 
>safely remove SCT.
>
>
>NOTE_2: motivations for having a separate HE dedicated to timing
>+ it simplifies the LCT header, removing unused fields from the
>"fast header processing path"
>+ it adds two more "PSI or reserved" bits (need to choose which
>one is the best solution).
>+ it logically groups all timing stuff in the same framework it eases 
>+ the addition of new functionalities to ALC/FLUTE/NORM/
>But:
>- it's not backward compatible at all! Is it really a problem 
>(see NOTE_1)?
>
>
>NOTE_3: unit in case of ERT (Rod/Imed):
>Current spec says it's in milliseconds, but is that really 
>appropriate? With a 32 bit field, in milliseconds, we wrap at 
>49.71 days.
>Changing ms to second mean we wrap at 49710 days = 136.1 years.
>The proposal is to go for NTP style - 32 bits is in seconds; 
>if you want better resolution use 64 bits where the most 
>significant 32 bits are seconds and the least are a multiple 
>of 1/2^^32 of a second.
>This can be done by specifying a new Use value (e.g. 0x0100=ERT_64BITS)
>