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

Hi Toni, Rod, Imed and Vincent,

good proposal. I also support Mark's proposal to maintain backward
compatibility. 

However, what does the value "0x00 = Unspecified" mean?

Example: A receiver find an HET= 0x65 extension header with a "Use"
bitfile == 0x00 (Unspecified). What does that give to the receiver or
the sender? 

BR,
/Thorsten 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Vincent Roca
> Sent: Monday, December 12, 2005 9:56 AM
> To: Rmt@ietf. org; Mark Watson
> Cc: Toni.paila; [email protected]; [email protected]; 
> Vincent Roca
> Subject: [Rmt] 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)
> 
> _______________________________________________
> Rmt mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rmt
>