<?xmlversion="1.0"?> <!-- This template is for creating an Internet Draft using xml2rfc, which is available here: http://xml.resource.org. -->version='1.0' encoding='UTF-8'?> <!DOCTYPE rfcSYSTEM "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.2119.xml"> <!ENTITY RFC5497 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5497.xml"><!ENTITYRFC7927 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7927.xml">nbsp " "> <!ENTITYRFC8174 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">zwsp "​"> <!ENTITYRFC9139 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9139.xml">nbhy "‑"> <!ENTITYI-D.mastorakis-icnrg-icntraceroute SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mastorakis-icnrg-icntraceroute.xml">wj "⁠"> ]><?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 xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-irtf-icnrg-ccnx-timetlv-05" number="9510" ipr="trust200902"updates="8609">updates="8609" obsoletes="" submissionType="IRTF" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3"> <!--category values: std, bcp, info, exp, and historic ipr values: full3667, noModification3667, noDerivatives3667 you can add the attributes updates="NNNN" and obsoletes="NNNN" they will automatically be output with "(if approved)"xml2rfc v2v3 conversion 3.18.2 --> <!-- ***** FRONT MATTER ***** --> <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"> Alternative Delta Time Encoding forCCNxContent-Centric Networking (CCNx) Using Compact Floating-Point Arithmetic </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"> <organization abbrev="Huawei">Huawei Technologies Duesseldorf GmbH</organization> <address> <postal> <street>Riesstrasse 25</street> <city>Munich</city> <code>D-80992</code> <country>Germany</country> </postal> <email>cenk.gundogan@huawei.com</email> </address> </author> <author fullname="Thomas C. Schmidt" initials="TC." surname="Schmidt"> <organization abbrev="HAW Hamburg">HAW Hamburg</organization> <address> <postal> <street>Berliner Tor 7</street> <city>Hamburg</city> <code>D-20099</code> <country>Germany</country> </postal> <email>t.schmidt@haw-hamburg.de</email> <uri>http://inet.haw-hamburg.de/members/schmidt</uri> </address> </author> <author fullname="Dave Oran" initials="D." surname="Oran"> <organization>Network Systems Research and Design</organization> <address> <postal> <street>4 Shady Hill Square</street><!-- Reorder these if your country does things differently --><city>Cambridge</city> <region>MA</region> <code>02138</code><country>USA</country><country>United States of America</country> </postal><phone></phone><phone/> <email>daveoran@orandom.net</email><!-- uri and facsimile elements may also be added --></address> </author> <author fullname="Matthias Wählisch" initials="M." surname="Wählisch"> <organization abbrev="TU Dresden">TUD Dresden University of Technology</organization> <address> <postal> <street>Helmholtzstr. 10</street> <city>Dresden</city> <code>D-01069</code> <country>Germany</country> </postal> <email>m.waehlisch@tu-dresden.de</email> </address> </author> <dateyear="2023" /> <!-- If the month and year are both specified and are the current ones, xml2rfc will fill in the current day for you. If only the current year is specified, xml2rfc will fill in the current day and month for you. If the year is not the current one, it is necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the purpose of calculating the expiry date). With drafts it is normally sufficient 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. -->year="2024" month="February"/> <workgroup>Information-Centric Networking</workgroup> <keyword>CCNx</keyword> <keyword>constrained networks</keyword> <keyword>compressed delta time</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><t>CCNx<t>Content-Centric Networking (CCNx) utilizes delta time for a number of functions. When using CCNx in environments with constrained nodes or bandwidth constrained 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 Networking Research Group (ICNRG).</t> </abstract> </front> <middle> <section anchor="intro"title="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>CCNx is well suited for Internet of Things (IoT) applications <xreftarget="RFC7927"/>. LoWPANtarget="RFC7927" format="default"/>. Low-Power Wireless Personal Area Network (LoWPAN) adaptation layers (e.g., <xreftarget="RFC9139"/>)target="RFC9139" format="default"/>) confirm the advantages of a space-efficient packet encoding for low-power and lossy networks. 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 compact representation of time values. However, any compact time representation has to sacrifice accuracy or dynamic range. For some timeusesuses, this is relatively straightforward toachieve,achieve; for other uses, it is not. As a result of experiments in bandwidth-constrained IEEE 802.15.4 deployments <xreftarget="ICNLOWPAN"/>,target="ICNLOWPAN" format="default"/>, this document discusses the various cases of time values, proposes a compact encoding for delta times, and updates <xreftarget="RFC8609"/>target="RFC8609" format="default"/> to utilize this encoding format in CCNx messages.</t> <t>This document has received fruitful reviews by the members of the research 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 does not constitute an IETF standard.</t> </section> <sectiontitle="Terminology"> <t>Thenumbered="true" toc="default"> <name>Terminology</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> <t>This document uses the terminology of <xreftarget="RFC8569"/>target="RFC8569" format="default"/> and <xreftarget="RFC8609"/>target="RFC8609" format="default"/> for CCNx entities.</t> <t>The following terms are used in the document and defined as follows:<list hangIndent="14" style="hanging"> <t hangText="byte:">synonym for octet</t> <t hangText="time value:">a</t> <dl newline="false" spacing="normal" indent="14"> <dt>byte:</dt> <dd>synonym for octet</dd> <dt>time value:</dt> <dd>a time offset measured inseconds</t> <t hangText="time code:">anseconds</dd> <dt>time code:</dt> <dd>an 8-bit encoded time value as defined in <xreftarget="RFC5497"/></t> </list></t>target="RFC5497" format="default"/></dd> </dl> </section> <sectiontitle="Usagenumbered="true" toc="default"> <name>Usage of Time Values inCCNx">CCNx</name> <section anchor="relativeTime"title="Relativenumbered="true" toc="default"> <name>Relative Time inCCNx">CCNx</name> <t>CCNx, as currently specified in <xreftarget="RFC8569"/>,target="RFC8569" format="default"/>, utilizes delta time for only the lifetime of an Interest message (seesections 2.1, 2.2, 2.4.2, 10.3Sections <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" sectionFormat="bare"/> of <xreftarget="RFC8569"/>).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 integer (<xreftarget="RFC8609"/> section 3.4.1).target="RFC8609" sectionFormat="of" section="3.4.1" />). While formally an optional TLV,in all but some corner casesevery Interest message is expected to carry the Interest LifetimeTLV, and henceTLV in all but some corner cases; hence, having compact encoding is particularly valuablefor keepingto 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 specified in <xreftarget="IEEE.754.2019"/>target="IEEE.754.2019" format="default"/> and as outlined in <xreftarget="sec.timetlv"/>.target="sec.timetlv" format="default"/>. This document updates<spanx>CCNxCCNx messages in TLVFormat</spanx>format <xreftarget="RFC8609"/>target="RFC8609" format="default"/> to permit this alternative encoding for selected time values. </t> </section> <section anchor="absoluteTime"title="Absolutenumbered="true" toc="default"> <name>Absolute Time inCCNx">CCNx</name> <t>CCNx, as currently specified in <xreftarget="RFC8569"/>,target="RFC8569" format="default"/>, utilizes absolute time for various important functions. Each of these absolute time usages poses a different challenge for a compact representation. These are discussed in the following subsections.</t> <section toc="exclude"title="Signaturenumbered="true"> <name>Signature Time and ExpiryTime"> <t><spanx>Signature Time</spanx>Time</name> <t>Signature Time is the time the signature of acontent objectContent Object was generated(<xref target="RFC8569">sections 8.2-8.4</xref>). <spanx>Expiry Time</spanx>(see Sections <xref target="RFC8569" sectionFormat="bare" section="8.2"/>-<xref target="RFC8569" sectionFormat="bare" section="8.4"/> of <xref target="RFC8569"/>). Expiry Time indicates theexpirytimeofafter which acontent objectContent Object is considered expired (<xreftarget="RFC8569">section 4</xref>).target="RFC8569" sectionFormat="of" section="4"/>). Both values are content message TLVs and represent absolute timestamps in milliseconds since the POSIX epoch. They are currently encoded via the T_SIGTIME and T_EXPIRY TLVs as 64-bit unsigned integers (see Sections <xreftarget="RFC8609"> section 3.6.4.1.4.5target="RFC8609" sectionFormat="bare" section="3.6.4.1.4.5"/> and3.6.2.2.2</xref>).</t><xref target="RFC8609" sectionFormat="bare" section="3.6.2.2.2"/> of <xref target="RFC8609"/>, respectively).</t> <t>Both time values could be in thepast,past or in the future, potentially by a large delta. They are also included in the security envelope of the message. 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 consider it further as a candidate.</t>therefore, this approach is not considered further.</t> </section> <section toc="exclude"title="Recommendednumbered="true"> <name>Recommended CacheTime"> <t><spanx>RecommendedTime</name> <t>Recommended CacheTime</spanx>Time (RCT) for acontent objectContent Object (<xreftarget="RFC8569">see section 4</xref>)target="RFC8569" sectionFormat="of" section="4" />) is a hop-by-hop header stating the expiration time for a cachedcontent objectContent Object in milliseconds since the POSIX epoch. It is currently encoded via the T_CACHETIME TLV as a 64-bit unsigned integer (see <xreftarget="RFC8609"> section 3.4.2</xref>).</t>target="RFC8609" sectionFormat="of" section="3.4.2"/>).</t> <t>Arecommended cache timeRecommended 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 time. Therefore, this document allows therecommended cache timeRecommended Cache Time to be interpreted as a relative time value rather than an absolute time,sincebecause the semantics associated with an absolute time value do not seem to be critical to the utility of this value. This document therefore updates therecommended cache timeRecommended Cache Time with the following rule set:<list style="symbols"></t> <ul spacing="normal"> <li> <t>Use absolute time as per <xreftarget="RFC8609"/></t>target="RFC8609" format="default"/></t> </li> <li> <t>Use relative time, if the compact time representation is used (see Sections <xreftarget="sec.timetlv"/>target="sec.timetlv" format="counter"/> and <xreftarget="sec.integration"/>)</t> </list> </t>target="sec.integration" format="counter"/>)</t> </li> </ul> <t>If relative time is used, the time offset recorded in a message will typically not account for residence times on lower layers (e.g., for processing, queuing) and link delays for every hop.The recommended cache time can thus notThus, the Recommended Cache Time cannot beexpressedas accurate aswithwhen absolutetime.time is used. This document targets low-power networks, where delay bounds are ratherloose,loose or do not exist. An accumulated error due to transmission delays in the range of milliseconds and seconds for therecommended cache timeRecommended Cache Time is still tolerable in thesenetworks,networks and does not impact the protocol performance. </t> <t>Networks with tight latency bounds use dedicated hardware, optimized software routines, and traffic engineering to reduce latency variations. Time offsets can then be corrected on every hop to yield exact cache times. </t> </section> </section> </section> <sectiontitle="Aanchor="sec.timetlv" numbered="true" toc="default"> <name>A Compact Time Representation with LogarithmicRange" anchor="sec.timetlv">Range</name> <t> This document uses the compact time representationof ICNLoWPAN (<xref target="RFC9139">see section 7 of </xref>)described in "Information-Centric Networking (ICN) Adaptation to Low-Power Wireless Personal Area Networks (LoWPANs)" (see <xref target="RFC9139" sectionFormat="of" section="7" />) thatiswas inspired by <xreftarget="RFC5497"/>target="RFC5497" format="default"/> and <xreftarget="IEEE.754.2019"/>.target="IEEE.754.2019" format="default"/>. Its logarithmic encoding supports a representation ranging from milliseconds to years. <xreftarget="fig.time-value"/>target="fig.time-value" format="default"/> depicts the logarithmic nature of this time representation. </t> <figureanchor="fig.time-value" title="Aanchor="fig.time-value"> <name>A logarithmic range representation allows for higher precision in the smaller time ranges and still supports large timedeltas.">deltas.</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ || | | | | | | | | | | +-----------------------------------------------------------------+ milliseconds years ]]></artwork> </figure> <t> Time codes encode exponent and mantissa values in a singlebyte, but inbyte. In contrast to the representation in <xreftarget="IEEE.754.2019"/>,target="IEEE.754.2019" format="default"/>, time codes only encode non-negative numbers and hence do not include a separatesign bit.bit to indicate integer signedness. <xreftarget="fig.time-code"/>target="fig.time-code" format="default"/> shows the configuration of a time code: an exponent width of 5 bits, and a mantissa width of 3 bits. </t> <figureanchor="fig.time-code" title="Aanchor="fig.time-code"> <name>A time code with exponent and mantissa to encode a logarithmic range timerepresentation.">representation.</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ <--- one byte wide ---> +----+----+----+----+----+----+----+----+ | exponent (b) | mantissa (a) | +----+----+----+----+----+----+----+----+ 0 1 2 3 4 5 6 7 ]]></artwork> </figure> <t> The base unit for time valuesareis seconds. A time value is calculated using the following formula (adopted from <xreftarget="RFC5497"/>target="RFC5497" format="default"/> and <xreftarget="RFC9139"/>),target="RFC9139" format="default"/>), where (a) represents the mantissa, (b) the exponent, and (C) a constant factor set to<spanx style="verb">C<tt>C :=1/32</spanx>. <list style="hanging"> <t hangText="Subnormal1/32</tt>. </t> <dl newline="false" spacing="normal"> <dt>Subnormal (b ==0):">0):</dt> <dd> (0 + a/8) * 2 * C</t> <t hangText="Normalized</dd> <dt>Normalized (b >0):">0):</dt> <dd> (1 + a/8) * 2^b * C</t> </list></dd> </dl> <t> The subnormal form provides a gradual underflow between zero and the smallest normalized number. 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, ...]. <xreftarget="sec.testvectors"/> furthertarget="sec.testvectors" format="default"/> includes test vectors to illustrate the logarithmic range. </t> <t> An example algorithm to encode a time value into the corresponding exponent and mantissa is given aspseudo codepseudocode in <xreftarget="fig.algo"/>.target="fig.algo" format="default"/>. Not all time values can be represented by a time code. For these instances,the closesta time code ischosenproduced thatisrepresents a time value closest to and smaller than the initial time valueto encode.input. </t> <figureanchor="fig.algo" title="Algorithmanchor="fig.algo"> <name>Algorithm inpseudo code."> <artwork align="center"><![CDATA[pseudocode.</name> <sourcecode type="pseudocode"><![CDATA[ input: float v // time value output: int a, b // mantissa, exponent of time code (a, b) encode (v): if (v == 0) return (0, 0) if (v < 2 * C) // subnormal a = floor (v * 4 / C) // round down return (a, 0) else // normalized if (v > (1 + 7/8) * 2^31 * C) // check bounds return (7, 31) // return maximum else b = floor (log2(v / C)) // round down a = floor ((v / (2^b * C) - 1) * 8) // round down return (a, b)]]></artwork>]]></sourcecode> </figure> <t>As an example: NoFor example, no specific time code for<spanx style="verb">0.063</spanx> exists, but<tt>0.063</tt> exists. However, this algorithm maps to the closest valid time code that issmaller,smaller than <tt>0.063</tt>, i.e., exponent<spanx style="verb">1</spanx><tt>1</tt> and mantissa<spanx style="verb">0</spanx><tt>0</tt> (the same as for time value<spanx style="verb">0.0625</spanx>).<tt>0.0625</tt>). </t> </section> <sectiontitle="Protocolanchor="sec.integration" numbered="true" toc="default"> <name>Protocol Integration of the Compact TimeRepresentation" anchor="sec.integration">Representation</name> <t>A straightforward way to accommodate the compact time approach is to use a 1-byte length field to indicate this alternative encoding while retaining the existing TLV registry entries. This approach has backward compatibility problems, but it is still considered for the following reasons:<list style="symbols"></t> <ul spacing="normal"> <li> <t>Both CCNx RFCs (<xref target="RFC8569" format="default"/> and <xref target="RFC8609" format="default"/>) areexperimentalExperimental and not StandardsTrack, henceTrack; hence, expectations for forward and backward compatibility are not as stringent. "Flag day" upgrades of deployed CCNx networks, while inconvenient, are still feasible.</t> </li> <li> <t>The major use case for these compressed encodings are smaller-scale IoT and/or sensor networks where the population of consumers, producers, and forwarders is reasonably small.</t> </li> <li> <t>Since the current TLVs have hop-by-hop semantics, they are not covered by any signed hash and hence may be freely re-encoded by any forwarder. That means a forwarder supporting the new encoding can translate freely between the two encodings.</t> </li> <li> <t>The alternative of assigning new TLV registry values does not substantially mitigate the interoperability problems anyway.</t></list> </t></li> </ul> <sectiontitle="Interest Lifetime" anchor="sec.integration.intlife">anchor="sec.integration.intlife" numbered="true" toc="default"> <name>Interest Lifetime</name> <t>The Interest Lifetime definition in <xreftarget="RFC8609"/>target="RFC8609" format="default"/> allows for a variable-length lifetime representation, where a length of<spanx style="verb">1</spanx><tt>1</tt> encodes the linear range [0,255] in milliseconds. This document changes the definition to always encode 1-byte InterestlifetimeLifetime values in the compact time value representation(<xref target="def-intlifetime"/>).(see <xref target="def-intlifetime" format="default"/>). For any other length, Interest Lifetimes are encoded as described in <xref target="RFC8609" section="3.4.1"/>. </t> <!-- [rfced] Figures 4 and 5 are not easily understood without additional context. Please consider whether one of the following suggestions is acceptable, or please 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". --> <figureanchor="def-intlifetime" title="Changesanchor="def-intlifetime"> <name>Changes to the definition of the Interest LifetimeTLV.">TLV.</name> <artworkalign="left"><![CDATA[align="left" name="" type="" alt=""><![CDATA[ 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 | +---------------+---------------+---------------+---------------+ | 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> </figure> </section> <sectiontitle="Recommendedanchor="sec.integration.recctime" numbered="true" toc="default"> <name>Recommended CacheTime" anchor="sec.integration.recctime">Time</name> <t>The Recommended Cache Time definition in <xreftarget="RFC8609"/>target="RFC8609" format="default"/> specifies an absolute time representation that is of a length fixed to 8 bytes. This document changes the definition to always encode 1-byte Recommended Cache Time values in the compact relative time value representation(<xref target="def-recctime"/>).(see <xref target="def-recctime" format="default"/>). For any other length, Recommended Cache Times are encoded as described in <xref target="RFC8609" section="3.4.2"/>. </t> <figureanchor="def-recctime" title="Changesanchor="def-recctime"> <name>Changes to the definition of the Recommended Cache TimeTLV.">TLV.</name> <artworkalign="left"><![CDATA[align="left" name="" type="" alt=""><![CDATA[ 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 = 1 | +---------------+---------------+---------------+---------------+ | 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> </figure> <t>The packet processing is adapted to calculate an absolute time from the relative time code based on the absolute reception time. On transmission, a new relative time code is calculated based on the current system time.</t> </section> </section> <section anchor="IANA"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>This document has no IANA actions.</t> </section> <section anchor="Security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>This document makes no semantic changes to <xreftarget="RFC8569"/>,target="RFC8569" format="default"/>, nor to any of the security properties of the message encodingsofdescribed in <xreftarget="RFC8609"/>, and hencetarget="RFC8609" format="default"/>; hence, it has the same security considerations as those twoexistingdocuments.Additional considerations need to be made inCareful consideration is needed for networks that deploy forwarders with support (updated forwarder) and without support (legacy forwarder) for this compact time representation: </t><list style="hanging"> <t hangText="Interest Lifetime:"><dl newline="false" spacing="normal"> <dt>Interest Lifetime:</dt> <dd> A legacy forwarder interprets a time code as an InterestlifetimeLifetime between 0 and 255 milliseconds. This may lead to a degradation of network performance, since Pending Interest Table (PIT) entries timeout quicker than expected. An updated forwarder interprets short lifetimes set by a legacy forwarder as time codes, thus configuring timeouts of up to 4 years. This leads to an inefficient occupation of state space.</t> <t hangText="Recommended</dd> <dt>Recommended CacheTime:">Time:</dt> <dd> A legacy forwarder considers a Recommended Cache Time with length 1 as a structural or syntactical error and itSHOULD<bcp14>SHOULD</bcp14> discard the packet (<xreftarget="RFC8569">section 10.3.9</xref>).target="RFC8569" sectionFormat="of" section="10.3.9"/>). Otherwise, a legacy forwarder interprets time codes as absolute time values far in the past, which impacts cache utilization.</t> </list></dd> </dl> </section> </middle><!-- *****BACK MATTER ***** --><back><!-- References split into informative and normative --> <!-- There are 2 ways to insert reference entries from the citation libraries: 1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown) 2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml") Both are cited textually in the same manner: by using xref elements. If you use the PI option, xml2rfc will, by default, try to find included files in the same directory as the including file. You can also define the XML_LIBRARY environment variable with a value containing a set of directories to search. These can be either in the local filing system or remote ones accessed by http (http://domain/dir/... ).--> <references title="Normative References"> &RFC2119; &RFC8174; &RFC8569; &RFC8609;<references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8569.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8609.xml"/> </references><references title="Informative References"> &RFC5497; &RFC7927; &RFC9139;<references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5497.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7927.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9139.xml"/> <reference anchor="IEEE.754.2019" target="https://standards.ieee.org/content/ieee-standards/en/standard/754-2019.html"> <front> <title>Standard for Floating-Point Arithmetic</title><author initials="" fullname="" surname="Institute of Electrical and Electronics Engineers, C/MSC - Microprocessor Standards Committee"/><author> <organization>IEEE </organization> </author> <date month="June" year="2019"/> </front> <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.2020.10.002" quoteTitle="true" derivedAnchor="ICNLOWPAN">target="https://doi.org/10.1016/j.comcom.2020.10.002"> <front> <title>Designing a LoWPAN convergence layer for the Information Centric Internet of Things</title> <author initials="C." surname="Gündoğan"><organization showOnFrontPage="true">HAW<organization>HAW Hamburg</organization> </author> <author initials="P." surname="Kietzmann"><organization showOnFrontPage="true">HAW<organization>HAW Hamburg</organization> </author> <author initials="T." surname="Schmidt"><organization showOnFrontPage="true">HAW<organization>HAW Hamburg</organization> </author> <author initials="M." surname="Wählisch"><organization showOnFrontPage="true">FU<organization>FU Berlin</organization> </author> <date month="December" year="2020"/> </front> <refcontent>Computer Communications, Vol. 164, No. 1, p.114–123,114-123, Elsevier</refcontent> </reference> </references> </references> <section anchor="sec.testvectors"title="Test Vectors">numbered="true" toc="default"> <name>Test Vectors</name> <t> The test vectors in <xreftarget="tab.testvectors"/>target="tab.testvectors" format="default"/> show sample time codes and their corresponding time values according to the algorithm outlined in <xreftarget="sec.timetlv"/>.target="sec.timetlv" format="default"/>. </t><texttable<table anchor="tab.testvectors"title="Test Vectors"> <ttcolalign="center"> <name>Test Vectors</name> <thead> <tr> <th align="center">TimeCode</ttcol> <ttcolCode</th> <th align="right">Time Value(seconds)</ttcol> <c>0x00</c> <c>0.0000000</c> <c>0x01</c> <c>0.0078125</c> <c>0x04</c> <c>0.0312500</c> <c>0x08</c> <c>0.0625000</c> <c>0x15</c> <c>0.2031250</c> <c>0x28</c> <c>1.0000000</c> <c>0x30</c> <c>2.0000000</c> <c>0xF8</c> <c>67108864.0000000</c> <c>0xFF</c> <c>125829120.0000000</c> </texttable>(seconds)</th> </tr> </thead> <tbody> <tr> <td align="center">0x00</td> <td align="right">0.0000000</td> </tr> <tr> <td align="center">0x01</td> <td align="right">0.0078125</td> </tr> <tr> <td align="center">0x04</td> <td align="right">0.0312500</td> </tr> <tr> <td align="center">0x08</td> <td align="right">0.0625000</td> </tr> <tr> <td align="center">0x15</td> <td align="right">0.2031250</td> </tr> <tr> <td align="center">0x28</td> <td align="right">1.0000000</td> </tr> <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 anchor="sec.tvapprox"title="Efficientnumbered="true" toc="default"> <name>Efficient Time ValueApproximation">Approximation</name> <t> A forwarder frequently converts compact time into milliseconds to compare InterestlifetimesLifetimes and the duration of cache entries. On many architectures, multiplication and division perform slower than addition, subtraction, and bit shifts. The following equations approximate the formulas in <xreftarget="sec.timetlv"/>,target="sec.timetlv" 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%.<list style="hanging" hangIndent="10"> <t hangText="b</t> <dl newline="false" spacing="normal" indent="10"> <dt>b ==0:">2^100:</dt> <dd>2^10 * a * 2^-3 * 2^1 * 2^-5<br/>= a << 3</t> <t hangText="b</dd> <dt>b >0:">(2^100:</dt> <dd>(2^10 + a * 2^-3 * 2^10) * 2^b * 2^-5<br/>= (1 << 5 + a << 2) << b</t> </list> </t></dd> </dl> </section> <sectionnumbered="no" title="Acknowledgments">numbered="false" toc="default" anchor="ack"> <name>Acknowledgments</name> <t>We would like to thank the active members of the ICNRG research group for their constructive thoughts. In particular, we thankMarc Mosko and Ken Calvert<contact fullname="Marc Mosko"/> and <contact fullname="Ken Calvert"/> for their valuable feedback on the encoding scheme andtheprotocol integration. Special thanks also go toCarsten Bormann<contact fullname="Carsten Bormann"/> for his constructive in-depth comments during the IRSG review.</t> </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> </rfc>