3. Usage of Time Values in CCNx (Utilizzo dei valori temporali in CCNx)

3.1. Relative Time in CCNx (Tempo relativo in CCNx)

CCNx, come attualmente specificato in [RFC8569], utilizza il tempo delta solo per la durata di vita di un messaggio Interest (vedere sezioni 2.1, 2.2, 2.4.2 e 10.3 di [RFC8569]). È un valore di intestazione hop-by-hop ed è attualmente codificato tramite il TLV T_INTLIFE come intero a 64 bit (sezione 3.4.1 di [RFC8609]). Sebbene formalmente sia un TLV opzionale, ogni messaggio Interest dovrebbe portare il TLV Interest Lifetime in tutti i casi tranne alcuni casi limite; quindi, avere una codifica compatta è particolarmente prezioso per mantenere brevi i messaggi Interest.

Poiché gli usi attuali del tempo delta non richiedono sia precisione che intervallo dinamico contemporaneamente, si può considerare una codifica logaritmica come quella specificata in [IEEE.754.2019] e delineata nella sezione 4. Questo documento aggiorna i messaggi CCNx in formato TLV [RFC8609] per consentire questa codifica alternativa per valori temporali selezionati.

3.2. Absolute Time in CCNx (Tempo assoluto in CCNx)

CCNx, come attualmente specificato in [RFC8569], utilizza il tempo assoluto per varie funzioni importanti. Ciascuno di questi usi del tempo assoluto pone una sfida diversa per una rappresentazione compatta. Questi sono discussi nelle seguenti sottosezioni.

3.2.1. Signature Time and Expiry Time (Tempo di firma e tempo di scadenza)

Il Signature Time (tempo di firma) è il momento in cui è stata generata la firma di un Content Object (oggetto contenuto) (vedere sezioni 8.2-8.4 di [RFC8569]). L'Expiry Time (tempo di scadenza) indica il tempo dopo il quale un oggetto contenuto è considerato scaduto (sezione 4 di [RFC8569]). Entrambi i valori sono TLV di messaggi di contenuto e rappresentano timestamp assoluti in millisecondi dall'epoca POSIX. Sono attualmente codificati tramite i TLV T_SIGTIME e T_EXPIRY come interi senza segno a 64 bit (vedere rispettivamente sezioni 3.6.4.1.4.5 e 3.6.2.2.2 di [RFC8609]).

Entrambi i valori temporali potrebbero essere nel passato o nel futuro, potenzialmente con un grande delta. Sono anche inclusi nell'involucro di sicurezza del messaggio. Pertanto, sembra che non ci sia un modo pratico per definire una codifica compatta alternativa che preservi la sua semantica e le proprietà di sicurezza; pertanto, questo approccio non viene ulteriormente considerato.

3.2.2. Recommended Cache Time (Tempo di cache raccomandato)

Il Recommended Cache Time (tempo di cache raccomandato, RCT) per un Content Object (sezione 4 di [RFC8569]) è un'intestazione hop-by-hop che indica il tempo di scadenza per un oggetto contenuto memorizzato nella cache in millisecondi dall'epoca POSIX. È attualmente codificato tramite il TLV T_CACHETIME come intero senza segno a 64 bit (vedere sezione 3.4.2 di [RFC8609]).

Un tempo di cache raccomandato potrebbe essere lontano nel futuro, ma non può essere nel passato ed è probabilmente un offset ragionevolmente breve dal tempo corrente. Pertanto, questo documento consente al tempo di cache raccomandato di essere interpretato come un valore di tempo relativo piuttosto che un tempo assoluto, poiché la semantica associata a un valore di tempo assoluto non sembra essere critica per l'utilità di questo valore. Questo documento quindi aggiorna il tempo di cache raccomandato con il seguente set di regole:

Utilizzare il tempo assoluto secondo [RFC8609]
Utilizzare il tempo relativo se viene utilizzata la rappresentazione temporale compatta (vedere sezioni 4 e 5)

Se viene utilizzato il tempo relativo, l'offset temporale registrato in un messaggio tipicamente non terrà conto dei tempi di permanenza sui livelli inferiori (ad esempio, per elaborazione, accodamento) e dei ritardi di collegamento per ogni hop. Pertanto, il tempo di cache raccomandato non può essere accurato come quando viene utilizzato il tempo assoluto. Questo documento è destinato a reti a bassa potenza, dove i limiti di ritardo sono piuttosto allentati o non esistono. Un errore accumulato dovuto ai ritardi di trasmissione nell'intervallo di millisecondi e secondi per il tempo di cache raccomandato è ancora tollerabile in queste reti e non influisce sulle prestazioni del protocollo.

Le reti con limiti di latenza rigorosi utilizzano hardware dedicato, routine software ottimizzate e ingegneria del traffico per ridurre le variazioni di latenza. Gli offset temporali possono quindi essere corretti ad ogni hop per ottenere tempi di cache esatti.