rfc9510xml2.original.xml   rfc9510.xml 
<?xml version="1.0"?> <?xml version='1.0' encoding='UTF-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!DOCTYPE rfc [
.2119.xml"> <!ENTITY nbsp "&#160;">
<!ENTITY RFC5497 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!ENTITY zwsp "&#8203;">
.5497.xml"> <!ENTITY nbhy "&#8209;">
<!ENTITY RFC7927 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!ENTITY wj "&#8288;">
.7927.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC8569 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8569.xml">
<!ENTITY RFC8609 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8609.xml">
<!ENTITY RFC9139 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.9139.xml">
<!ENTITY I-D.mastorakis-icnrg-icntraceroute SYSTEM "http://xml.resource.org/publ
ic/rfc/bibxml3/reference.I-D.mastorakis-icnrg-icntraceroute.xml">
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="exp" docName="draft-irtf-icnrg-ccnx-timetlv-05" ipr="trust200902" <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
updates="8609"> category="exp"
<!-- category values: std, bcp, info, exp, and historic docName="draft-irtf-icnrg-ccnx-timetlv-05"
ipr values: full3667, noModification3667, noDerivatives3667 number="9510"
you can add the attributes updates="NNNN" and obsoletes="NNNN" ipr="trust200902"
they will automatically be output with "(if approved)" --> updates="8609"
obsoletes=""
submissionType="IRTF"
consensus="true"
xml:lang="en"
tocInclude="true"
tocDepth="4"
symRefs="true"
sortRefs="true"
version="3">
<!-- xml2rfc v2v3 conversion 3.18.2 -->
<!-- ***** FRONT MATTER ***** --> <!-- ***** FRONT MATTER ***** -->
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary
if the
full title is longer than 39 characters -->
<title abbrev="TimeTLV for CCNx"> <title abbrev="TimeTLV for CCNx">
Alternative Delta Time Encoding for CCNx Using Compact Floating-Point Arithm etic Alternative Delta Time Encoding for Content-Centric Networking (CCNx) Using Compact Floating-Point Arithmetic
</title> </title>
<!-- add 'role="editor"' below for the editors if appropriate --> <seriesInfo name="RFC" value="9510"/>
<author fullname="Cenk Gündoğan" initials="C." surname="Gündoğan"> <author fullname="Cenk Gündoğan" initials="C." surname="Gündoğan">
<organization abbrev="Huawei">Huawei Technologies Duesseldorf GmbH</orga <organization abbrev="Huawei">Huawei Technologies Duesseldorf GmbH</organi
nization> zation>
<address> <address>
<postal> <postal>
<street>Riesstrasse 25</street> <street>Riesstrasse 25</street>
<city>Munich</city> <city>Munich</city>
<code>D-80992</code> <code>D-80992</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>cenk.gundogan@huawei.com</email> <email>cenk.gundogan@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Thomas C. Schmidt" initials="TC." surname="Schmidt"> <author fullname="Thomas C. Schmidt" initials="TC." surname="Schmidt">
<organization abbrev="HAW Hamburg">HAW Hamburg</organization> <organization abbrev="HAW Hamburg">HAW Hamburg</organization>
<address> <address>
<postal> <postal>
<street>Berliner Tor 7</street> <street>Berliner Tor 7</street>
<city>Hamburg</city> <city>Hamburg</city>
<code>D-20099</code> <code>D-20099</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
skipping to change at line 84 skipping to change at line 60
<postal> <postal>
<street>Berliner Tor 7</street> <street>Berliner Tor 7</street>
<city>Hamburg</city> <city>Hamburg</city>
<code>D-20099</code> <code>D-20099</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>t.schmidt@haw-hamburg.de</email> <email>t.schmidt@haw-hamburg.de</email>
<uri>http://inet.haw-hamburg.de/members/schmidt</uri> <uri>http://inet.haw-hamburg.de/members/schmidt</uri>
</address> </address>
</author> </author>
<author fullname="Dave Oran" initials="D." surname="Oran"> <author fullname="Dave Oran" initials="D." surname="Oran">
<organization>Network Systems Research and Design</organization> <organization>Network Systems Research and Design</organization>
<address> <address>
<postal> <postal>
<street>4 Shady Hill Square</street> <street>4 Shady Hill Square</street>
<!-- Reorder these if your country does things differently --> <city>Cambridge</city>
<city>Cambridge</city> <region>MA</region>
<region>MA</region> <code>02138</code>
<code>02138</code> <country>United States of America</country>
<country>USA</country> </postal>
</postal> <phone/>
<phone></phone> <email>daveoran@orandom.net</email>
<email>daveoran@orandom.net</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Matthias Wählisch" initials="M." surname="Wählisch"> <author fullname="Matthias Wählisch" initials="M." surname="Wählisch">
<organization abbrev="TU Dresden">TUD Dresden University of Technology</or ganization> <organization abbrev="TU Dresden">TUD Dresden University of Technology</or ganization>
<address> <address>
<postal> <postal>
<street>Helmholtzstr. 10</street> <street>Helmholtzstr. 10</street>
<city>Dresden</city> <city>Dresden</city>
<code>D-01069</code> <code>D-01069</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>m.waehlisch@tu-dresden.de</email> <email>m.waehlisch@tu-dresden.de</email>
</address> </address>
</author> </author>
<date year="2024" month="February"/>
<date year="2023" /> <workgroup>Information-Centric Networking</workgroup>
<!-- If the month and year are both specified and are the current ones, xml2
rfc will fill
in the current day for you. If only the current year is specified, xml2
rfc will fill
in the current day and month for you. If the year is not the current on
e, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not s
pecified for the
purpose of calculating the expiry date). With drafts it is normally su
fficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>IRTF</area>
<workgroup>ICNRG</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. --
>
<keyword>CCNx</keyword> <keyword>CCNx</keyword>
<keyword>constrained networks</keyword> <keyword>constrained networks</keyword>
<keyword>compressed delta time</keyword> <keyword>compressed delta time</keyword>
<keyword>IoT</keyword> <keyword>IoT</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract> <abstract>
<t>CCNx utilizes delta time for a number of functions. When using CCNx in environments with constrained nodes or bandwidth constrained networks, it is va luable to have a compressed representation of delta time. In order to do so, eit her accuracy or dynamic range has to be sacrificed. Since the current uses of de lta time do not require both simultaneously, one can consider a logarithmic enco ding. This document updates RFC 8609 ("CCNx messages in TLV Format") to specify this alternative encoding.</t> <t>Content-Centric Networking (CCNx) utilizes delta time for a number of f unctions. When using CCNx in environments with constrained nodes or bandwidth co nstrained networks, it is valuable to have a compressed representation of delta time. In order to do so, either accuracy or dynamic range has to be sacrificed. Since the current uses of delta time do not require both simultaneously, one can consider a logarithmic encoding. This document updates RFC 8609 ("CCNx messages in TLV Format") to specify this alternative encoding.</t>
<t>This document is a product of the IRTF Information-Centric <t>This document is a product of the IRTF Information-Centric
Networking Research Group (ICNRG).</t> Networking Research Group (ICNRG).</t>
</abstract> </abstract>
</front> </front>
<middle>
<middle> <section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
<section anchor="intro" title="Introduction"> <t>CCNx is well suited for Internet of Things (IoT) applications <xref tar
get="RFC7927" format="default"/>.
<t>CCNx is well suited for Internet of Things (IoT) applications <xref target="R Low-Power Wireless Personal Area Network (LoWPAN) adaptation layers (e.g., <xref
FC7927"/>. target="RFC9139" format="default"/>) confirm the advantages of a space-efficien
LoWPAN adaptation layers (e.g., <xref target="RFC9139"/>) confirm the advantages t packet encoding for low-power and lossy networks.
of a space-efficient packet encoding for low-power and lossy networks.
CCNx utilizes absolute and delta time values for a number of functions. CCNx utilizes absolute and delta time values for a number of functions.
When using CCNx in resource-constrained environments, it is valuable to have a c When using CCNx in resource-constrained environments, it is valuable to have a c
ompact representation of time values. However, any compact time representation ompact representation of time values. However, any compact time representation
has to sacrifice accuracy or dynamic range. For some time uses this is relativel has to sacrifice accuracy or dynamic range. For some time uses, this is relative
y straightforward to achieve, for other uses, it is not. ly straightforward to achieve; for other uses, it is not.
As a result of experiments in bandwidth-constrained IEEE 802.15.4 deployments <x As a result of experiments in bandwidth-constrained IEEE 802.15.4 deployments <x
ref target="ICNLOWPAN"/>, this document discusses the various cases of time valu ref target="ICNLOWPAN" format="default"/>, this document discusses the various c
es, proposes a compact encoding for delta times, and updates <xref target="RFC86 ases of time values, proposes a compact encoding for delta times, and updates <x
09"/> to utilize this encoding format in CCNx messages.</t> ref target="RFC8609" format="default"/> to utilize this encoding format in CCNx
<t>This document has received fruitful reviews by the members of the research messages.</t>
<t>This document has received fruitful reviews by the members of the resea
rch
group (see the Acknowledgments section). It is the consensus of ICNRG that this group (see the Acknowledgments section). It is the consensus of ICNRG that this
document should be published in the IRTF Stream of the RFC series. This document document should be published in the IRTF Stream of the RFC series. This document
does not constitute an IETF standard.</t> does not constitute an IETF standard.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Terminology"> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"MAY", and "OPTIONAL" in this document are to be interpreted as "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> wh ",
en, and only when, they "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
appear in all capitals, as shown here.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<t>This document uses the terminology of <xref target="RFC8569"/> and <x be
ref interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8609"/> for CCNx entities.</t> target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
<t>The following terms are used in the document and defined as follows: </t>
<list hangIndent="14" style="hanging"> <t>This document uses the terminology of <xref target="RFC8569" format="de
<t hangText="byte:">synonym for octet</t> fault"/> and <xref target="RFC8609" format="default"/> for CCNx entities.</t>
<t hangText="time value:">a time offset measured in seconds</t> <t>The following terms are used in the document and defined as follows:
<t hangText="time code:">an 8-bit encoded time value as defined in <xr </t>
ef target="RFC5497"/></t> <dl newline="false" spacing="normal" indent="14">
</list></t> <dt>byte:</dt>
</section> <dd>synonym for octet</dd>
<dt>time value:</dt>
<section title="Usage of Time Values in CCNx"> <dd>a time offset measured in seconds</dd>
<section anchor="relativeTime" title="Relative Time in CCNx"> <dt>time code:</dt>
<dd>an 8-bit encoded time value as defined in <xref target="RFC5497" for
<t>CCNx, as currently specified in <xref target="RFC8569"/>, utilizes delta time mat="default"/></dd>
for only the lifetime of an Interest message (see sections 2.1, 2.2, 2.4.2, 10. </dl>
3 of <xref target="RFC8569"/>). It is a hop-by-hop header value, and is currentl </section>
y encoded via the T_INTLIFE TLV as a 64-bit integer (<xref target="RFC8609"/> se <section numbered="true" toc="default">
ction 3.4.1). While formally an optional TLV, in all but some corner cases every <name>Usage of Time Values in CCNx</name>
Interest message is expected to carry the Interest Lifetime TLV, and hence havi <section anchor="relativeTime" numbered="true" toc="default">
ng compact encoding is particularly valuable for keeping Interest messages short <name>Relative Time in CCNx</name>
.</t> <t>CCNx, as currently specified in <xref target="RFC8569" format="defaul
t"/>, utilizes delta time for only the lifetime of an Interest message (see Sect
ions <xref target="RFC8569" section="2.1" sectionFormat="bare"/>, <xref target="
RFC8569" section="2.2" sectionFormat="bare"/>, <xref target="RFC8569" section="2
.4.2" sectionFormat="bare"/>, and <xref target="RFC8569" section="10.3" sectionF
ormat="bare"/> of <xref target="RFC8569" format="default"/>). It is a hop-by-hop
header value, and is currently encoded via the T_INTLIFE TLV as a 64-bit intege
r (<xref target="RFC8609" sectionFormat="of" section="3.4.1" />). While formally
an optional TLV, every Interest message is expected to carry the Interest Lifet
ime TLV in all but some corner cases; hence, having compact encoding is particul
arly valuable to keep Interest messages short.</t>
<t>Since the current uses of delta time do not require both accuracy and dynamic range simultaneously, one can consider a logarithmic encoding such as that spec ified in <xref target="IEEE.754.2019"/> and outlined in <xref target="sec.timetl v"/>. This document updates <spanx>CCNx messages in TLV Format</spanx> <xref tar get="RFC8609"/> to permit this alternative encoding for selected time values. <t>Since the current uses of delta time do not require both accuracy and dynamic range simultaneously, one can consider a logarithmic encoding such as t hat specified in <xref target="IEEE.754.2019" format="default"/> and as outlined in <xref target="sec.timetlv" format="default"/>. This document updates CCNx me ssages in TLV format <xref target="RFC8609" format="default"/> to permit this al ternative encoding for selected time values.
</t> </t>
</section> </section>
<section anchor="absoluteTime" numbered="true" toc="default">
<section anchor="absoluteTime" title="Absolute Time in CCNx"> <name>Absolute Time in CCNx</name>
<t>CCNx, as currently specified in <xref target="RFC8569"/>, utilizes absolute t <t>CCNx, as currently specified in <xref target="RFC8569" format="defaul
ime for various important functions. Each of these absolute time usages poses a t"/>, utilizes absolute time for various important functions. Each of these abso
different challenge for a compact representation. These are discussed in the fol lute time usages poses a different challenge for a compact representation. These
lowing subsections.</t> are discussed in the following subsections.</t>
<section toc="exclude" numbered="true">
<section toc="exclude" title="Signature Time and Expiry Time"> <name>Signature Time and Expiry Time</name>
<t><spanx>Signature Time</spanx> is the time the signature of a content object <t>Signature Time is the time the signature of a Content Object was ge
was generated (<xref target="RFC8569">sections 8.2-8.4</xref>). nerated (see Sections <xref target="RFC8569" sectionFormat="bare" section="8.2"/
<spanx>Expiry Time</spanx> indicates the expiry time of a content object (<xre >-<xref target="RFC8569" sectionFormat="bare" section="8.4"/> of <xref target="R
f target="RFC8569">section 4</xref>). FC8569"/>).
Expiry Time indicates the time after which a Content Object is considered expi
red (<xref target="RFC8569" sectionFormat="of" section="4"/>).
Both values are content message TLVs and represent absolute timestamps in mill iseconds since the POSIX epoch. Both values are content message TLVs and represent absolute timestamps in mill iseconds since the POSIX epoch.
They are currently encoded via the T_SIGTIME and T_EXPIRY TLVs as 64-bit unsig They are currently encoded via the T_SIGTIME and T_EXPIRY TLVs as 64-bit unsig
ned integers (see <xref target="RFC8609"> section 3.6.4.1.4.5 and 3.6.2.2.2</xre ned integers (see Sections <xref target="RFC8609" sectionFormat="bare" section="
f>).</t> 3.6.4.1.4.5"/> and <xref target="RFC8609" sectionFormat="bare" section="3.6.2.2.
2"/> of <xref target="RFC8609"/>, respectively).</t>
<t>Both time values could be in the past, or in the future, potentially by a l <t>Both time values could be in the past or in the future, potentially
arge delta. by a large delta.
They are also included in the security envelope of the message. They are also included in the security envelope of the message.
Therefore, it seems there is no practical way to define an alternative compact Therefore, it seems there is no practical way to define an alternative compact
encoding that preserves its semantics and security properties; hence we don't c encoding that preserves its semantics and security properties; therefore, this
onsider it further as a candidate.</t> approach is not considered further.</t>
</section> </section>
<section toc="exclude" numbered="true">
<section toc="exclude" title="Recommended Cache Time"> <name>Recommended Cache Time</name>
<t><spanx>Recommended Cache Time</spanx> (RCT) for a content object (<xref tar <t>Recommended Cache Time (RCT) for a Content Object (<xref target="RF
get="RFC8569">see section 4</xref>) is a hop-by-hop header stating the expiratio C8569" sectionFormat="of" section="4" />) is a hop-by-hop header stating the exp
n time for a cached content object in milliseconds since the POSIX epoch. It is iration time for a cached Content Object in milliseconds since the POSIX epoch.
currently encoded via the T_CACHETIME TLV as a 64-bit unsigned integer (see <xre It is currently encoded via the T_CACHETIME TLV as a 64-bit unsigned integer (se
f target="RFC8609"> section 3.4.2</xref>).</t> e <xref target="RFC8609" sectionFormat="of" section="3.4.2"/>).</t>
<t>A Recommended Cache Time could be far in the future, but it cannot
be in the past and is likely to be a reasonably short offset from the current ti
me.
Therefore, this document allows the Recommended Cache Time to be interpreted a
s a relative time value rather than an absolute time, because the semantics asso
ciated with an absolute time value do not seem to be critical to the utility of
this value.
This document therefore updates the Recommended Cache Time with the following
rule set:
</t>
<ul spacing="normal">
<li>
<t>Use absolute time as per <xref target="RFC8609" format="default
"/></t>
</li>
<li>
<t>Use relative time, if the compact time representation is used (
see Sections <xref target="sec.timetlv" format="counter"/> and <xref target="sec
.integration" format="counter"/>)</t>
</li>
</ul>
<t>A recommended cache time could be far in the future, but cannot be in the pas <t>If relative time is used, the time offset recorded in a message wil
t and is likely to be a reasonably short offset from the current time. l typically not account for residence times on lower layers (e.g., for processin
Therefore, this document allows the recommended cache time to be interpreted a g, queuing) and link delays for every hop. Thus,
s a relative time value rather than an absolute time, since the semantics associ the Recommended Cache Time cannot be as accurate as when absolute time is used.
ated with an absolute time value do not seem to be critical to the utility of th This document targets low-power networks, where delay bounds are rather loose
is value. or do not exist.
This document therefore updates the recommended cache time with the following An accumulated error due to transmission delays in the range of milliseconds a
rule set: nd seconds for the Recommended Cache Time is still tolerable in these networks a
<list style="symbols"> nd does not impact the protocol performance.
<t>Use absolute time as per <xref target="RFC8609"/></t>
<t>Use relative time, if the compact time representation is used (see <xref
target="sec.timetlv"/> and <xref target="sec.integration"/>)</t>
</list>
</t>
<t>If relative time is used, the time offset recorded in a message will typica
lly not account for residence times on lower layers (e.g., for processing, queui
ng) and link delays for every hop.
The recommended cache time can thus not be expressed as accurate as with absol
ute time.
This document targets low-power networks, where delay bounds are rather loose,
or do not exist.
An accumulated error due to transmission delays in the range of milliseconds a
nd seconds for the recommended cache time is still tolerable in these networks,
and does not impact the protocol performance.
</t> </t>
<t>Networks with tight latency bounds use dedicated hardware, optimized softwa re routines, and traffic engineering to reduce latency variations. <t>Networks with tight latency bounds use dedicated hardware, optimize d software routines, and traffic engineering to reduce latency variations.
Time offsets can then be corrected on every hop to yield exact cache times. Time offsets can then be corrected on every hop to yield exact cache times.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section title="A Compact Time Representation with Logarithmic Range" anchor="se <section anchor="sec.timetlv" numbered="true" toc="default">
c.timetlv"> <name>A Compact Time Representation with Logarithmic Range</name>
<t> <t>
This document uses the compact time representation of ICNLoWPAN (<xref targe This document uses the compact time representation described in "Information
t="RFC9139">see section 7 of </xref>) that is inspired by <xref target="RFC5497" -Centric Networking (ICN) Adaptation to Low-Power Wireless Personal Area Network
/> and <xref target="IEEE.754.2019"/>. s (LoWPANs)" (see <xref target="RFC9139" sectionFormat="of" section="7" />) that
was inspired by <xref target="RFC5497" format="default"/> and <xref target="IEE
E.754.2019" format="default"/>.
Its logarithmic encoding supports a representation ranging from milliseconds to years. Its logarithmic encoding supports a representation ranging from milliseconds to years.
<xref target="fig.time-value"/> depicts the logarithmic nature of this time <xref target="fig.time-value" format="default"/> depicts the logarithmic nat
representation. ure of this time representation.
</t> </t>
<figure anchor="fig.time-value" title="A logarithmic range representation allo <figure anchor="fig.time-value">
ws for higher precision in the smaller time ranges and still supports large time <name>A logarithmic range representation allows for higher precision in
deltas."> the smaller time ranges and still supports large time deltas.</name>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
|| | | | | | | | | | | || | | | | | | | | | |
+-----------------------------------------------------------------+ +-----------------------------------------------------------------+
milliseconds years milliseconds years
]]></artwork> ]]></artwork>
</figure> </figure>
<t>
Time codes encode exponent and mantissa values in a single byte, but in cont <t>
rast to the representation in <xref target="IEEE.754.2019"/>, time codes only en Time codes encode exponent and mantissa values in a single byte. In contrast
code non-negative numbers and hence do not include a separate sign bit. to the representation in <xref target="IEEE.754.2019" format="default"/>, time
<xref target="fig.time-code"/> shows the configuration of a time code: an ex codes only encode non-negative numbers and hence do not include a separate bit t
ponent width of 5 bits, and a mantissa width of 3 bits. o indicate integer signedness.
</t> <xref target="fig.time-code" format="default"/> shows the configuration of a
<figure anchor="fig.time-code" title="A time code with exponent and mantissa t time code: an exponent width of 5 bits, and a mantissa width of 3 bits.
o encode a logarithmic range time representation."> </t>
<artwork align="center"><![CDATA[ <figure anchor="fig.time-code">
<name>A time code with exponent and mantissa to encode a logarithmic ran
ge time representation.</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
<--- one byte wide ---> <--- one byte wide --->
+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+
| exponent (b) | mantissa (a) | | exponent (b) | mantissa (a) |
+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
The base unit for time values are seconds. A time value is calculated using The base unit for time values is seconds. A time value is calculated using t
the following formula (adopted from <xref target="RFC5497"/> and <xref target="R he following formula (adopted from <xref target="RFC5497" format="default"/> and
FC9139"/>), <xref target="RFC9139" format="default"/>),
where (a) represents the mantissa, (b) the exponent, and (C) a constant fact where (a) represents the mantissa, (b) the exponent, and (C) a constant fact
or set to <spanx style="verb">C := 1/32</spanx>. or set to <tt>C := 1/32</tt>.
<list style="hanging">
<t hangText="Subnormal (b == 0):"> (0 + a/8) * 2 * C
</t>
<t hangText="Normalized (b &gt; 0):"> (1 + a/8) * 2^b * C
</t> </t>
</list> <dl newline="false" spacing="normal">
<dt>Subnormal (b == 0):</dt>
<dd> (0 + a/8) * 2 * C
</dd>
<dt>Normalized (b &gt; 0):</dt>
<dd> (1 + a/8) * 2^b * C
</dd>
</dl>
<t>
The subnormal form provides a gradual underflow between zero and the smalles t normalized number. The subnormal form provides a gradual underflow between zero and the smalles t normalized number.
Eight time values exist in the subnormal range [0s,~0.0546875s] with a step size of ~0.0078125s between each time value. Eight time values exist in the subnormal range [0s,~0.0546875s] with a step size of ~0.0078125s between each time value.
This configuration also encodes the following convenient numbers in seconds: [1, 2, 4, 8, 16, 32, 64, ...]. This configuration also encodes the following convenient numbers in seconds: [1, 2, 4, 8, 16, 32, 64, ...].
<xref target="sec.testvectors"/> further includes test vectors to illustrate <xref target="sec.testvectors" format="default"/> includes test vectors to i
the logarithmic range. llustrate the logarithmic range.
</t> </t>
<t>
An example algorithm to encode a time value into the corresponding exponent <t>
and mantissa is given as pseudo code in <xref target="fig.algo"/>. An example algorithm to encode a time value into the corresponding exponent
and mantissa is given as pseudocode in <xref target="fig.algo" format="default"/
>.
Not all time values can be represented by a time code. Not all time values can be represented by a time code.
For these instances, the closest time code is chosen that is smaller than th For these instances, a time code is produced that represents a time value cl
e value to encode. osest to and smaller than the initial time value input.
</t> </t>
<figure anchor="fig.algo" title="Algorithm in pseudo code."> <figure anchor="fig.algo">
<artwork align="center"><![CDATA[
<name>Algorithm in pseudocode.</name>
<sourcecode type="pseudocode"><![CDATA[
input: float v // time value input: float v // time value
output: int a, b // mantissa, exponent of time code output: int a, b // mantissa, exponent of time code
(a, b) encode (v): (a, b) encode (v):
if (v == 0) if (v == 0)
return (0, 0) return (0, 0)
if (v < 2 * C) // subnormal if (v < 2 * C) // subnormal
a = floor (v * 4 / C) // round down a = floor (v * 4 / C) // round down
return (a, 0) return (a, 0)
else // normalized else // normalized
if (v > (1 + 7/8) * 2^31 * C) // check bounds if (v > (1 + 7/8) * 2^31 * C) // check bounds
return (7, 31) // return maximum return (7, 31) // return maximum
else else
b = floor (log2(v / C)) // round down b = floor (log2(v / C)) // round down
a = floor ((v / (2^b * C) - 1) * 8) // round down a = floor ((v / (2^b * C) - 1) * 8) // round down
return (a, b) return (a, b)
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t> <t>
As an example: No specific time code for <spanx style="verb">0.063</spanx> e For example, no specific time code for <tt>0.063</tt> exists. However, this
xists, but this algorithm maps to the closest valid time code that is smaller, i algorithm maps to the closest valid time code that is smaller than <tt>0.063</tt
.e., exponent <spanx style="verb">1</spanx> and mantissa <spanx style="verb">0</ >, i.e., exponent <tt>1</tt> and mantissa <tt>0</tt> (the same as for time value
spanx> (the same as for time value <spanx style="verb">0.0625</spanx>). <tt>0.0625</tt>).
</t> </t>
</section> </section>
<section title="Protocol Integration of the Compact Time Representation" anchor= <section anchor="sec.integration" numbered="true" toc="default">
"sec.integration"> <name>Protocol Integration of the Compact Time Representation</name>
<t>A straightforward way to accommodate the compact time approach is to use a <t>A straightforward way to accommodate the compact time approach is to us
1-byte length field to indicate this alternative encoding while retaining the ex e a 1-byte length field to indicate this alternative encoding while retaining th
isting TLV registry entries. e existing TLV registry entries.
This approach has backward compatibility problems, but is still considered f This approach has backward compatibility problems, but it is still considere
or the following reasons: d for the following reasons:
<list style="symbols"> </t>
<t>Both CCNx RFCs are experimental and not Standards Track, hence expectat <ul spacing="normal">
ions for forward and backward compatibility are not as stringent. "Flag day" upg <li>
rades of deployed CCNx networks, while inconvenient, are still feasible.</t> <t>Both CCNx RFCs (<xref target="RFC8569" format="default"/> and <xref
<t>The major use case for these compressed encodings are smaller-scale IoT target="RFC8609" format="default"/>) are Experimental and not Standards Track;
and/or sensor networks where the population of consumers, producers, and forwar hence, expectations for forward and backward compatibility are not as stringent.
ders is reasonably small.</t> "Flag day" upgrades of deployed CCNx networks, while inconvenient, are still fe
<t>Since the current TLVs have hop-by-hop semantics, they are not covered asible.</t>
by any signed hash and hence may be freely re-encoded by any forwarder. That mea </li>
ns a forwarder supporting the new encoding can translate freely between the two <li>
encodings.</t> <t>The major use case for these compressed encodings are smaller-scale
<t>The alternative of assigning new TLV registry values does not substanti IoT and/or sensor networks where the population of consumers, producers, and fo
ally mitigate the interoperability problems anyway.</t> rwarders is reasonably small.</t>
</list> </li>
</t> <li>
<section title="Interest Lifetime" anchor="sec.integration.intlife"> <t>Since the current TLVs have hop-by-hop semantics, they are not cove
<t>The Interest Lifetime definition in <xref target="RFC8609"/> allows for a red by any signed hash and hence may be freely re-encoded by any forwarder. That
variable-length lifetime representation, where a length of <spanx style="verb"> means a forwarder supporting the new encoding can translate freely between the
1</spanx> encodes the linear range [0,255] in milliseconds. two encodings.</t>
This document changes the definition to always encode 1-byte Interest lifeti </li>
me values in the compact time value representation (<xref target="def-intlifetim <li>
e"/>). <t>The alternative of assigning new TLV registry values does not subst
</t> antially mitigate the interoperability problems anyway.</t>
<figure anchor="def-intlifetime" title="Changes to the definition of the Inter </li>
est Lifetime TLV."> </ul>
<artwork align="left"><![CDATA[ <section anchor="sec.integration.intlife" numbered="true" toc="default">
<name>Interest Lifetime</name>
<t>The Interest Lifetime definition in <xref target="RFC8609" format="de
fault"/> allows for a variable-length lifetime representation, where a length of
<tt>1</tt> encodes the linear range [0,255] in milliseconds.
This document changes the definition to always encode 1-byte Interest Lifeti
me values in the compact time value representation (see <xref target="def-intlif
etime" format="default"/>).
For any other length, Interest Lifetimes are encoded as described in <xref t
arget="RFC8609" section="3.4.1"/>.
</t>
<!-- [rfced] Figures 4 and 5 are not easily understood without additional contex
t. Please consider whether one of the following suggestions is acceptable, or p
lease suggest an alternative.
Note: figures have been ommitted to ensure we don't break the output files.
Section 5.1 original:
This document changes the
definition to always encode 1-byte Interest lifetime values in the
compact time value representation (Figure 4).
New figure
Old figure
Perhaps A:
This document changes the
definition to always encode 1-byte Interest Lifetime values in the
compact time value representation (see Figure 4).
Figure 4: new figure only
Perhaps B:
This document changes the
definition to always encode 1-byte Interest Lifetime values in the
compact time value representation (see Figure 4).
Figure 4
As defined in Section 3.4.2 of [RFC8609]:
Old figure
Figure 5:
New figure
Note that we would make a similar update to Figure 5.
Authors: Both figures Fig. 4 and Fig. 5 display the new definition only, not the
new
and old version. We changed the captions from "Changes to the definition ..."
to "New definition ..." to make this apparent. This aligns with above "Perhaps
A" solution.
Authors: We simplified the figure and adjusted the text to reference Sec. 3.4.1
of RFC8609 for Interest Lifetimes with a Length not equal 1. We did the same
for the Recommended Cache Time. We also reverted the caption to say "Changes to
the definition" instead of "New definition".
-->
<figure anchor="def-intlifetime">
<name>Changes to the definition of the Interest Lifetime TLV.</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
1 2 3 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 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
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_INTLIFE | Length = 1 | | T_INTLIFE | Length = 1 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| COMPACT_TIME | | COMPACT_TIME |
+---------------+ +---------------+
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
+---------------+---------------+---------------+---------------+
| T_INTLIFE | Length > 1 |
+---------------+---------------+---------------+---------------+
/ /
/ Lifetime (Length octets) /
/ /
+---------------+---------------+---------------+---------------+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section title="Recommended Cache Time" anchor="sec.integration.recctime"> <section anchor="sec.integration.recctime" numbered="true" toc="default">
<t>The Recommended Cache Time definition in <xref target="RFC8609"/> specifi <name>Recommended Cache Time</name>
es an absolute time representation that is of a length fixed to 8 bytes. <t>The Recommended Cache Time definition in <xref target="RFC8609" forma
This document changes the definition to always encode 1-byte Recommended Cac t="default"/> specifies an absolute time representation that is of a length fixe
he Time values in the compact relative time value representation (<xref target=" d to 8 bytes.
def-recctime"/>). This document changes the definition to always encode 1-byte Recommended Cac
</t> he Time values in the compact relative time value representation (see <xref targ
<figure anchor="def-recctime" title="Changes to the definition of the Recommen et="def-recctime" format="default"/>).
ded Cache Time TLV."> For any other length, Recommended Cache Times are encoded as described in <x
<artwork align="left"><![CDATA[ ref target="RFC8609" section="3.4.2"/>.
</t>
<figure anchor="def-recctime">
<name>Changes to the definition of the Recommended Cache Time TLV.</na
me>
<artwork align="left" name="" type="" alt=""><![CDATA[
1 2 3 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 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
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_CACHETIME | Length = 1 | | T_CACHETIME | Length = 1 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| COMPACT_TIME | | COMPACT_TIME |
+---------------+ +---------------+
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
+---------------+---------------+---------------+---------------+
| T_CACHETIME | Length = 8 |
+---------------+---------------+---------------+---------------+
/ /
/ Recommended Cache Time /
/ /
+---------------+---------------+---------------+---------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The packet processing is adapted to calculate an absolute time from the rel <t>The packet processing is adapted to calculate an absolute time from t
ative time code based on the absolute reception time. he relative time code based on the absolute reception time.
On transmission, a new relative time code is calculated based on the current s ystem time.</t> On transmission, a new relative time code is calculated based on the current s ystem time.</t>
</section> </section>
</section> </section>
<section anchor="IANA" title="IANA Considerations"> <section anchor="IANA" numbered="true" toc="default">
<t>This document has no IANA actions.</t> <name>IANA Considerations</name>
</section> <t>This document has no IANA actions.</t>
</section>
<section anchor="Security" title="Security Considerations"> <section anchor="Security" numbered="true" toc="default">
<t>This document makes no semantic changes to <xref target="RFC8569"/>, <name>Security Considerations</name>
nor to any of the security properties of the message encodings of <xref target=" <t>This document makes no semantic changes to <xref target="RFC8569" forma
RFC8609"/>, and hence has the same security considerations as those two existing t="default"/>, nor to any of the security properties of the message encodings de
documents. scribed in <xref target="RFC8609" format="default"/>; hence, it has the same sec
Additional considerations need to be made in networks that deploy forwar urity considerations as those two documents.
ders with support (updated forwarder) and without support (legacy forwarder) for Careful consideration is needed for networks that deploy forwarders with
this compact time representation: support (updated forwarder) and without support (legacy forwarder) for this com
</t> pact time representation:
<list style="hanging"> </t>
<t hangText="Interest Lifetime:"> <dl newline="false" spacing="normal">
<dt>Interest Lifetime:</dt>
<dd>
A legacy forwarder A legacy forwarder
interprets a time code as an Interest lifetime between 0 and interprets a time code as an Interest Lifetime between 0 and
255 milliseconds. This may lead to a degradation of network 255 milliseconds. This may lead to a degradation of network
performance, since Pending Interest Table (PIT) entries timeout performance, since Pending Interest Table (PIT) entries timeout
quicker than expected. quicker than expected.
An updated forwarder interprets short lifetimes set by a legacy forwar der as time codes, thus configuring timeouts of up to 4 years. An updated forwarder interprets short lifetimes set by a legacy forwar der as time codes, thus configuring timeouts of up to 4 years.
This leads to an inefficient occupation of state space. This leads to an inefficient occupation of state space.
</t> </dd>
<t hangText="Recommended Cache Time:"> <dt>Recommended Cache Time:</dt>
<dd>
A legacy forwarder A legacy forwarder
considers a Recommended Cache Time with length 1 as a considers a Recommended Cache Time with length 1 as a
structural or syntactical error and it SHOULD discard the packet (<x ref target="RFC8569">section 10.3.9</xref>). structural or syntactical error and it <bcp14>SHOULD</bcp14> discard the packet (<xref target="RFC8569" sectionFormat="of" section="10.3.9"/>).
Otherwise, a legacy forwarder interprets time codes as absolute Otherwise, a legacy forwarder interprets time codes as absolute
time values far in the past, which impacts cache utilization. time values far in the past, which impacts cache utilization.
</t> </dd>
</list> </dl>
</section> </section>
</middle>
</middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation librarie <references>
s: <name>References</name>
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here <references>
(as shown) <name>Normative References</name>
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xm <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
l"?> here 119.xml"/>
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
xml") 174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
Both are cited textually in the same manner: by using xref elements. 569.xml"/>
If you use the PI option, xml2rfc will, by default, try to find included fi <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
les in the same 609.xml"/>
directory as the including file. You can also define the XML_LIBRARY enviro </references>
nment variable <references>
with a value containing a set of directories to search. These can be eithe <name>Informative References</name>
r in the local <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
filing system or remote ones accessed by http (http://domain/dir/... ).--> 497.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<references title="Normative References"> 927.xml"/>
&RFC2119; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
&RFC8174; 139.xml"/>
&RFC8569;
&RFC8609;
</references>
<references title="Informative References">
&RFC5497;
&RFC7927;
&RFC9139;
<reference anchor="IEEE.754.2019" <reference anchor="IEEE.754.2019" target="https://standards.ieee.org/con
target="https://standards.ieee.org/content/ieee-standards/en/st tent/ieee-standards/en/standard/754-2019.html">
andard/754-2019.html"> <front>
<front> <title>Standard for Floating-Point Arithmetic</title>
<title>Standard for Floating-Point Arithmetic</title> <author>
<author initials="" fullname="" <organization>IEEE
surname="Institute of Electrical and Electronics Engineers, C/ </organization>
MSC - Microprocessor Standards Committee"/> </author>
<date month="June" year="2019"/> <date month="June" year="2019"/>
</front> </front>
</reference> <seriesInfo name="IEEE Std" value="754-2019"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2019.8766229"/>
</reference>
<reference anchor="ICNLOWPAN" target="https://doi.org/10.1016/j.comcom.202 <reference anchor="ICNLOWPAN" target="https://doi.org/10.1016/j.comcom.2
0.10.002" quoteTitle="true" derivedAnchor="ICNLOWPAN"> 020.10.002">
<front> <front>
<title>Designing a LoWPAN convergence layer for the Information Centri <title>Designing a LoWPAN convergence layer for the Information Cent
c Internet of Things</title> ric Internet of Things</title>
<author initials="C." surname="Gündoğan"> <author initials="C." surname="Gündoğan">
<organization showOnFrontPage="true">HAW Hamburg</organization> <organization>HAW Hamburg</organization>
</author> </author>
<author initials="P." surname="Kietzmann"> <author initials="P." surname="Kietzmann">
<organization showOnFrontPage="true">HAW Hamburg</organization> <organization>HAW Hamburg</organization>
</author> </author>
<author initials="T." surname="Schmidt"> <author initials="T." surname="Schmidt">
<organization showOnFrontPage="true">HAW Hamburg</organization> <organization>HAW Hamburg</organization>
</author> </author>
<author initials="M." surname="Wählisch"> <author initials="M." surname="Wählisch">
<organization showOnFrontPage="true">FU Berlin</organization> <organization>FU Berlin</organization>
</author> </author>
<date month="December" year="2020"/> <date month="December" year="2020"/>
</front> </front>
<refcontent>Computer Communications, Vol. 164, No. 1, p. 114–123, Elsevi <refcontent>Computer Communications, Vol. 164, No. 1, p. 114-123, Else
er</refcontent> vier</refcontent>
</reference> </reference>
</references>
</references> </references>
<section anchor="sec.testvectors" title="Test Vectors"> <section anchor="sec.testvectors" numbered="true" toc="default">
<name>Test Vectors</name>
<t> <t>
The test vectors in <xref target="tab.testvectors"/> show sample time co des and their corresponding time values according to the algorithm outlined in < xref target="sec.timetlv"/>. The test vectors in <xref target="tab.testvectors" format="default"/> sh ow sample time codes and their corresponding time values according to the algori thm outlined in <xref target="sec.timetlv" format="default"/>.
</t> </t>
<table anchor="tab.testvectors" align="center">
<texttable anchor="tab.testvectors" <name>Test Vectors</name>
title="Test Vectors"> <thead>
<ttcol align="center">Time Code</ttcol> <tr>
<th align="center">Time Code</th>
<ttcol align="right">Time Value (seconds)</ttcol> <th align="right">Time Value (seconds)</th>
</tr>
<c>0x00</c> </thead>
<c>0.0000000</c> <tbody>
<tr>
<c>0x01</c> <td align="center">0x00</td>
<c>0.0078125</c> <td align="right">0.0000000</td>
</tr>
<c>0x04</c> <tr>
<c>0.0312500</c> <td align="center">0x01</td>
<td align="right">0.0078125</td>
<c>0x08</c> </tr>
<c>0.0625000</c> <tr>
<td align="center">0x04</td>
<c>0x15</c> <td align="right">0.0312500</td>
<c>0.2031250</c> </tr>
<tr>
<c>0x28</c> <td align="center">0x08</td>
<c>1.0000000</c> <td align="right">0.0625000</td>
</tr>
<c>0x30</c> <tr>
<c>2.0000000</c> <td align="center">0x15</td>
<td align="right">0.2031250</td>
<c>0xF8</c> </tr>
<c>67108864.0000000</c> <tr>
<td align="center">0x28</td>
<c>0xFF</c> <td align="right">1.0000000</td>
<c>125829120.0000000</c> </tr>
</texttable> <tr>
<td align="center">0x30</td>
<td align="right">2.0000000</td>
</tr>
<tr>
<td align="center">0xF8</td>
<td align="right">67108864.0000000</td>
</tr>
<tr>
<td align="center">0xFF</td>
<td align="right">125829120.0000000</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="sec.tvapprox" title="Efficient Time Value Approximation"> <section anchor="sec.tvapprox" numbered="true" toc="default">
<name>Efficient Time Value Approximation</name>
<t> <t>
A forwarder frequently converts compact time into milliseconds to compar e Interest lifetimes and the duration of cache entries. A forwarder frequently converts compact time into milliseconds to compar e Interest Lifetimes and the duration of cache entries.
On many architectures, multiplication and division perform slower than a ddition, subtraction, and bit shifts. On many architectures, multiplication and division perform slower than a ddition, subtraction, and bit shifts.
The following equations approximate the formulas in <xref target="sec.ti metlv"/>, and scale from seconds into the milliseconds range by applying a facto r of 2^10 instead of 10^3. The following equations approximate the formulas in <xref target="sec.ti metlv" format="default"/>, and scale from seconds into the milliseconds range by applying a factor of 2^10 instead of 10^3.
This results in an error of 2.4%. This results in an error of 2.4%.
<list style="hanging" hangIndent="10">
<t hangText="b == 0:">2^10 * a * 2^-3 * 2^1 * 2^-5<br/>= a &lt;&lt; 3
</t>
<t hangText="b &gt; 0:">(2^10 + a * 2^-3 * 2^10) * 2^b * 2^-5<br/>= (1
&lt;&lt; 5 + a &lt;&lt; 2) &lt;&lt; b
</t>
</list>
</t> </t>
<dl newline="false" spacing="normal" indent="10">
<dt>b == 0:</dt>
<dd>2^10 * a * 2^-3 * 2^1 * 2^-5<br/>= a &lt;&lt; 3
</dd>
<dt>b &gt; 0:</dt>
<dd>(2^10 + a * 2^-3 * 2^10) * 2^b * 2^-5<br/>= (1 &lt;&lt; 5 + a &lt;&l
t; 2) &lt;&lt; b
</dd>
</dl>
</section> </section>
<section numbered="no" title="Acknowledgments"> <section numbered="false" toc="default" anchor="ack">
<t>We would like to thank the active members of the ICNRG research group f <name>Acknowledgments</name>
or constructive thoughts. <t>We would like to thank the active members of the ICNRG research group f
In particular, we thank Marc Mosko and Ken Calvert for their valuable feed or their constructive thoughts.
back on the encoding scheme and the protocol integration. In particular, we thank <contact fullname="Marc Mosko"/> and <contact full
Special thanks also to Carsten Bormann for his constructive in-depth comme name="Ken Calvert"/> for their valuable feedback on the encoding scheme and prot
nts during the IRSG review.</t> ocol integration.
Special thanks also go to <contact fullname="Carsten Bormann"/> for his co
nstructive in-depth comments during the IRSG review.</t>
</section> </section>
<!-- Change Log
v00 2019-10-03 DRO Initial version
v03 2021-01-18 DRO Refreash - no changes
v05 2022-01-20 CG major update-->
</back> </back>
</rfc> </rfc>
 End of changes. 56 change blocks. 
499 lines changed or deleted 524 lines changed or added

This html diff was produced by rfcdiff 1.48.