Subject: [Rmt] New HE for timing information, including SCT/ERT

From: Vincent Roca <[email-masked]>
Date: Mon, 12 Dec 2005 09:55:41 +0100

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-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: [email-masked]
Date: Tue, 13 Dec 2005 16:27:14 +0200

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-masked]] 
>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,
>
>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).
>the following time value(s) 0x00 = Unspecified
>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:
>while "Use field" 0x0100 to 0x8000 are reserved for 64 bit time values.
>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.
>
>
>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...)
>
>
>---------------
>
>+ it logically groups all timing stuff in the same framework it eases 
>+ the addition of new functionalities to ALC/FLUTE/NORM/
>But:
>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.