rfc9510.original   rfc9510.txt 
ICNRG C. Gündoğan Internet Research Task Force (IRTF) C. Gündoğan
Internet-Draft Huawei Request for Comments: 9510 Huawei
Updates: 8609 (if approved) TC. Schmidt Updates: 8609 TC. Schmidt
Intended status: Experimental HAW Hamburg Category: Experimental HAW Hamburg
Expires: 6 April 2024 D. Oran ISSN: 2070-1721 D. Oran
Network Systems Research and Design Network Systems Research and Design
M. Wählisch M. Wählisch
TU Dresden TU Dresden
4 October 2023 February 2024
Alternative Delta Time Encoding for CCNx Using Compact Floating-Point Alternative Delta Time Encoding for Content-Centric Networking (CCNx)
Arithmetic Using Compact Floating-Point Arithmetic
draft-irtf-icnrg-ccnx-timetlv-05
Abstract Abstract
CCNx utilizes delta time for a number of functions. When using CCNx Content-Centric Networking (CCNx) utilizes delta time for a number of
in environments with constrained nodes or bandwidth constrained functions. When using CCNx in environments with constrained nodes or
networks, it is valuable to have a compressed representation of delta bandwidth constrained networks, it is valuable to have a compressed
time. In order to do so, either accuracy or dynamic range has to be representation of delta time. In order to do so, either accuracy or
sacrificed. Since the current uses of delta time do not require both dynamic range has to be sacrificed. Since the current uses of delta
simultaneously, one can consider a logarithmic encoding. This time do not require both simultaneously, one can consider a
document updates RFC 8609 ("CCNx messages in TLV Format") to specify logarithmic encoding. This document updates RFC 8609 ("CCNx messages
this alternative encoding. in TLV Format") to specify this alternative encoding.
This document is a product of the IRTF Information-Centric Networking This document is a product of the IRTF Information-Centric Networking
Research Group (ICNRG). Research Group (ICNRG).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Research Task
time. It is inappropriate to use Internet-Drafts as reference Force (IRTF). The IRTF publishes the results of Internet-related
material or to cite them other than as "work in progress." research and development activities. These results might not be
suitable for deployment. This RFC represents the consensus of the
Information-Centric Networking Research Group of the Internet
Research Task Force (IRTF). Documents approved for publication by
the IRSG are not candidates for any level of Internet Standard; see
Section 2 of RFC 7841.
This Internet-Draft will expire on 6 April 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9510.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document.
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. Usage of Time Values in CCNx . . . . . . . . . . . . . . . . 3 3. Usage of Time Values in CCNx
3.1. Relative Time in CCNx . . . . . . . . . . . . . . . . . . 3 3.1. Relative Time in CCNx
3.2. Absolute Time in CCNx . . . . . . . . . . . . . . . . . . 4 3.2. Absolute Time in CCNx
4. A Compact Time Representation with Logarithmic Range . . . . 5 4. A Compact Time Representation with Logarithmic Range
5. Protocol Integration of the Compact Time Representation . . . 7 5. Protocol Integration of the Compact Time Representation
5.1. Interest Lifetime . . . . . . . . . . . . . . . . . . . . 7 5.1. Interest Lifetime
5.2. Recommended Cache Time . . . . . . . . . . . . . . . . . 8 5.2. Recommended Cache Time
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.1. Normative References
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Test Vectors
Appendix B. Efficient Time Value Approximation . . . . . . . . . 11 Appendix B. Efficient Time Value Approximation
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses
1. Introduction 1. Introduction
CCNx is well suited for Internet of Things (IoT) applications CCNx is well suited for Internet of Things (IoT) applications
[RFC7927]. LoWPAN adaptation layers (e.g., [RFC9139]) confirm the [RFC7927]. Low-Power Wireless Personal Area Network (LoWPAN)
advantages of a space-efficient packet encoding for low-power and adaptation layers (e.g., [RFC9139]) confirm the advantages of a
lossy networks. CCNx utilizes absolute and delta time values for a space-efficient packet encoding for low-power and lossy networks.
number of functions. When using CCNx in resource-constrained CCNx utilizes absolute and delta time values for a number of
environments, it is valuable to have a compact representation of time functions. When using CCNx in resource-constrained environments, it
values. However, any compact time representation has to sacrifice is valuable to have a compact representation of time values.
accuracy or dynamic range. For some time uses this is relatively However, any compact time representation has to sacrifice accuracy or
straightforward to achieve, for other uses, it is not. As a result dynamic range. For some time uses, this is relatively
straightforward to achieve; for other uses, it is not. As a result
of experiments in bandwidth-constrained IEEE 802.15.4 deployments of experiments in bandwidth-constrained IEEE 802.15.4 deployments
[ICNLOWPAN], this document discusses the various cases of time [ICNLOWPAN], this document discusses the various cases of time
values, proposes a compact encoding for delta times, and updates values, proposes a compact encoding for delta times, and updates
[RFC8609] to utilize this encoding format in CCNx messages. [RFC8609] to utilize this encoding format in CCNx messages.
This document has received fruitful reviews by the members of the This document has received fruitful reviews by the members of the
research group (see the Acknowledgments section). It is the research group (see the Acknowledgments section). It is the
consensus of ICNRG that this document should be published in the IRTF consensus of ICNRG that this document should be published in the IRTF
Stream of the RFC series. This document does not constitute an IETF Stream of the RFC series. This document does not constitute an IETF
standard. standard.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document uses the terminology of [RFC8569] and [RFC8609] for This document uses the terminology of [RFC8569] and [RFC8609] for
CCNx entities. CCNx entities.
The following terms are used in the document and defined as follows: The following terms are used in the document and defined as follows:
byte: synonym for octet byte: synonym for octet
time value: a time offset measured in seconds time value: a time offset measured in seconds
time code: an 8-bit encoded time value as defined in [RFC5497] time code: an 8-bit encoded time value as defined in [RFC5497]
3. Usage of Time Values in CCNx 3. Usage of Time Values in CCNx
3.1. Relative Time in CCNx 3.1. Relative Time in CCNx
CCNx, as currently specified in [RFC8569], utilizes delta time for CCNx, as currently specified in [RFC8569], utilizes delta time for
only the lifetime of an Interest message (see sections 2.1, 2.2, only the lifetime of an Interest message (see Sections 2.1, 2.2,
2.4.2, 10.3 of [RFC8569]). It is a hop-by-hop header value, and is 2.4.2, and 10.3 of [RFC8569]). It is a hop-by-hop header value, and
currently encoded via the T_INTLIFE TLV as a 64-bit integer is currently encoded via the T_INTLIFE TLV as a 64-bit integer
([RFC8609] section 3.4.1). While formally an optional TLV, in all (Section 3.4.1 of [RFC8609]). While formally an optional TLV, every
but some corner cases every Interest message is expected to carry the Interest message is expected to carry the Interest Lifetime TLV in
Interest Lifetime TLV, and hence having compact encoding is all but some corner cases; hence, having compact encoding is
particularly valuable for keeping Interest messages short. particularly valuable to keep Interest messages short.
Since the current uses of delta time do not require both accuracy and Since the current uses of delta time do not require both accuracy and
dynamic range simultaneously, one can consider a logarithmic encoding dynamic range simultaneously, one can consider a logarithmic encoding
such as that specified in [IEEE.754.2019] and outlined in Section 4. such as that specified in [IEEE.754.2019] and as outlined in
This document updates _CCNx messages in TLV Format_ [RFC8609] to Section 4. This document updates CCNx messages in TLV format
permit this alternative encoding for selected time values. [RFC8609] to permit this alternative encoding for selected time
values.
3.2. Absolute Time in CCNx 3.2. Absolute Time in CCNx
CCNx, as currently specified in [RFC8569], utilizes absolute time for CCNx, as currently specified in [RFC8569], utilizes absolute time for
various important functions. Each of these absolute time usages various important functions. Each of these absolute time usages
poses a different challenge for a compact representation. These are poses a different challenge for a compact representation. These are
discussed in the following subsections. discussed in the following subsections.
3.2.1. Signature Time and Expiry Time 3.2.1. Signature Time and Expiry Time
_Signature Time_ is the time the signature of a content object was Signature Time is the time the signature of a Content Object was
generated (sections 8.2-8.4 [RFC8569]). _Expiry Time_ indicates the generated (see Sections 8.2-8.4 of [RFC8569]). Expiry Time indicates
expiry time of a content object (section 4 [RFC8569]). Both values the time after which a Content Object is considered expired
are content message TLVs and represent absolute timestamps in (Section 4 of [RFC8569]). Both values are content message TLVs and
milliseconds since the POSIX epoch. They are currently encoded via represent absolute timestamps in milliseconds since the POSIX epoch.
the T_SIGTIME and T_EXPIRY TLVs as 64-bit unsigned integers (see They are currently encoded via the T_SIGTIME and T_EXPIRY TLVs as
section 3.6.4.1.4.5 and 3.6.2.2.2 [RFC8609]). 64-bit unsigned integers (see Sections 3.6.4.1.4.5 and 3.6.2.2.2 of
[RFC8609], respectively).
Both time values could be in the past, or in the future, potentially Both time values could be in the past or in the future, potentially
by a large delta. They are also included in the security envelope of 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 the message. Therefore, it seems there is no practical way to define
an alternative compact encoding that preserves its semantics and an alternative compact encoding that preserves its semantics and
security properties; hence we don't consider it further as a security properties; therefore, this approach is not considered
candidate. further.
3.2.2. Recommended Cache Time 3.2.2. Recommended Cache Time
_Recommended Cache Time_ (RCT) for a content object (see section 4 Recommended Cache Time (RCT) for a Content Object (Section 4 of
[RFC8569]) is a hop-by-hop header stating the expiration time for a [RFC8569]) is a hop-by-hop header stating the expiration time for a
cached content object in milliseconds since the POSIX epoch. It is cached Content Object in milliseconds since the POSIX epoch. It is
currently encoded via the T_CACHETIME TLV as a 64-bit unsigned currently encoded via the T_CACHETIME TLV as a 64-bit unsigned
integer (see section 3.4.2 [RFC8609]). integer (see Section 3.4.2 of [RFC8609]).
A recommended cache time could be far in the future, but cannot be in A Recommended Cache Time could be far in the future, but it cannot be
the past and is likely to be a reasonably short offset from the in the past and is likely to be a reasonably short offset from the
current time. Therefore, this document allows the recommended cache current time. Therefore, this document allows the Recommended Cache
time to be interpreted as a relative time value rather than an Time to be interpreted as a relative time value rather than an
absolute time, since the semantics associated with an absolute time absolute time, because the semantics associated with an absolute time
value do not seem to be critical to the utility of this value. This value do not seem to be critical to the utility of this value. This
document therefore updates the recommended cache time with the document therefore updates the Recommended Cache Time with the
following rule set: following rule set:
* Use absolute time as per [RFC8609] * Use absolute time as per [RFC8609]
* Use relative time, if the compact time representation is used (see * Use relative time, if the compact time representation is used (see
Section 4 and Section 5) Sections 4 and 5)
If relative time is used, the time offset recorded in a message will 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 typically not account for residence times on lower layers (e.g., for
processing, queuing) and link delays for every hop. The recommended processing, queuing) and link delays for every hop. Thus, the
cache time can thus not be expressed as accurate as with absolute Recommended Cache Time cannot be as accurate as when absolute time is
time. This document targets low-power networks, where delay bounds used. This document targets low-power networks, where delay bounds
are rather loose, or do not exist. An accumulated error due to are rather loose or do not exist. An accumulated error due to
transmission delays in the range of milliseconds and seconds for the transmission delays in the range of milliseconds and seconds for the
recommended cache time is still tolerable in these networks, and does Recommended Cache Time is still tolerable in these networks and does
not impact the protocol performance. not impact the protocol performance.
Networks with tight latency bounds use dedicated hardware, optimized Networks with tight latency bounds use dedicated hardware, optimized
software routines, and traffic engineering to reduce latency software routines, and traffic engineering to reduce latency
variations. Time offsets can then be corrected on every hop to yield variations. Time offsets can then be corrected on every hop to yield
exact cache times. exact cache times.
4. A Compact Time Representation with Logarithmic Range 4. A Compact Time Representation with Logarithmic Range
This document uses the compact time representation of ICNLoWPAN (see This document uses the compact time representation described in
section 7 of [RFC9139]) that is inspired by [RFC5497] and "Information-Centric Networking (ICN) Adaptation to Low-Power
[IEEE.754.2019]. Its logarithmic encoding supports a representation Wireless Personal Area Networks (LoWPANs)" (see Section 7 of
ranging from milliseconds to years. Figure 1 depicts the logarithmic [RFC9139]) that was inspired by [RFC5497] and [IEEE.754.2019]. Its
nature of this time representation. logarithmic encoding supports a representation ranging from
milliseconds to years. Figure 1 depicts the logarithmic nature of
this time representation.
|| | | | | | | | | | | || | | | | | | | | | |
+-----------------------------------------------------------------+ +-----------------------------------------------------------------+
milliseconds years milliseconds years
Figure 1: A logarithmic range representation allows for higher Figure 1: A logarithmic range representation allows for higher
precision in the smaller time ranges and still supports large precision in the smaller time ranges and still supports large
time deltas. time deltas.
Time codes encode exponent and mantissa values in a single byte, but Time codes encode exponent and mantissa values in a single byte. In
in contrast to the representation in [IEEE.754.2019], time codes only contrast to the representation in [IEEE.754.2019], time codes only
encode non-negative numbers and hence do not include a separate sign encode non-negative numbers and hence do not include a separate bit
bit. Figure 2 shows the configuration of a time code: an exponent to indicate integer signedness. Figure 2 shows the configuration of
width of 5 bits, and a mantissa width of 3 bits. a time code: an exponent width of 5 bits, and a mantissa width of 3
bits.
<--- 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
Figure 2: A time code with exponent and mantissa to encode a Figure 2: A time code with exponent and mantissa to encode a
logarithmic range time representation. logarithmic range time representation.
The base unit for time values are seconds. A time value is The base unit for time values is seconds. A time value is calculated
calculated using the following formula (adopted from [RFC5497] and using the following formula (adopted from [RFC5497] and [RFC9139]),
[RFC9139]), where (a) represents the mantissa, (b) the exponent, and where (a) represents the mantissa, (b) the exponent, and (C) a
(C) a constant factor set to C := 1/32. constant factor set to C := 1/32.
Subnormal (b == 0): (0 + a/8) * 2 * C Subnormal (b == 0): (0 + a/8) * 2 * C
Normalized (b > 0): (1 + a/8) * 2^b * C Normalized (b > 0): (1 + a/8) * 2^b * C
The subnormal form provides a gradual underflow between zero and the The subnormal form provides a gradual underflow between zero and the
smallest normalized number. Eight time values exist in the subnormal smallest normalized number. Eight time values exist in the subnormal
range [0s,~0.0546875s] with a step size of ~0.0078125s between each range [0s,~0.0546875s] with a step size of ~0.0078125s between each
time value. This configuration also encodes the following convenient time value. This configuration also encodes the following convenient
numbers in seconds: [1, 2, 4, 8, 16, 32, 64, ...]. Appendix A numbers in seconds: [1, 2, 4, 8, 16, 32, 64, ...]. Appendix A
further includes test vectors to illustrate the logarithmic range. includes test vectors to illustrate the logarithmic range.
An example algorithm to encode a time value into the corresponding An example algorithm to encode a time value into the corresponding
exponent and mantissa is given as pseudo code in Figure 3. Not all exponent and mantissa is given as pseudocode in Figure 3. Not all
time values can be represented by a time code. For these instances, time values can be represented by a time code. For these instances,
the closest time code is chosen that is smaller than the value to a time code is produced that represents a time value closest to and
encode. smaller than the initial time value input.
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)
Figure 3: Algorithm in pseudo code. Figure 3: Algorithm in pseudocode.
As an example: No specific time code for 0.063 exists, but this For example, no specific time code for 0.063 exists. However, this
algorithm maps to the closest valid time code that is smaller, i.e., algorithm maps to the closest valid time code that is smaller than
exponent 1 and mantissa 0 (the same as for time value 0.0625). 0.063, i.e., exponent 1 and mantissa 0 (the same as for time value
0.0625).
5. Protocol Integration of the Compact Time Representation 5. Protocol Integration of the Compact Time Representation
A straightforward way to accommodate the compact time approach is to A straightforward way to accommodate the compact time approach is to
use a 1-byte length field to indicate this alternative encoding while use a 1-byte length field to indicate this alternative encoding while
retaining the existing TLV registry entries. This approach has retaining the existing TLV registry entries. This approach has
backward compatibility problems, but is still considered for the backward compatibility problems, but it is still considered for the
following reasons: following reasons:
* Both CCNx RFCs are experimental and not Standards Track, hence * Both CCNx RFCs ([RFC8569] and [RFC8609]) are Experimental and not
expectations for forward and backward compatibility are not as Standards Track; hence, expectations for forward and backward
stringent. "Flag day" upgrades of deployed CCNx networks, while compatibility are not as stringent. "Flag day" upgrades of
inconvenient, are still feasible. deployed CCNx networks, while inconvenient, are still feasible.
* The major use case for these compressed encodings are smaller- * The major use case for these compressed encodings are smaller-
scale IoT and/or sensor networks where the population of scale IoT and/or sensor networks where the population of
consumers, producers, and forwarders is reasonably small. consumers, producers, and forwarders is reasonably small.
* Since the current TLVs have hop-by-hop semantics, they are not * 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 covered by any signed hash and hence may be freely re-encoded by
any forwarder. That means a forwarder supporting the new encoding any forwarder. That means a forwarder supporting the new encoding
can translate freely between the two encodings. can translate freely between the two encodings.
* The alternative of assigning new TLV registry values does not * The alternative of assigning new TLV registry values does not
substantially mitigate the interoperability problems anyway. substantially mitigate the interoperability problems anyway.
5.1. Interest Lifetime 5.1. Interest Lifetime
The Interest Lifetime definition in [RFC8609] allows for a variable- The Interest Lifetime definition in [RFC8609] allows for a variable-
length lifetime representation, where a length of 1 encodes the length lifetime representation, where a length of 1 encodes the
linear range [0,255] in milliseconds. This document changes the linear range [0,255] in milliseconds. This document changes the
definition to always encode 1-byte Interest lifetime values in the definition to always encode 1-byte Interest Lifetime values in the
compact time value representation (Figure 4). compact time value representation (see Figure 4). For any other
length, Interest Lifetimes are encoded as described in Section 3.4.1
of [RFC8609].
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) /
/ /
+---------------+---------------+---------------+---------------+
Figure 4: Changes to the definition of the Interest Lifetime TLV. Figure 4: Changes to the definition of the Interest Lifetime TLV.
5.2. Recommended Cache Time 5.2. Recommended Cache Time
The Recommended Cache Time definition in [RFC8609] specifies an The Recommended Cache Time definition in [RFC8609] specifies an
absolute time representation that is of a length fixed to 8 bytes. absolute time representation that is of a length fixed to 8 bytes.
This document changes the definition to always encode 1-byte This document changes the definition to always encode 1-byte
Recommended Cache Time values in the compact relative time value Recommended Cache Time values in the compact relative time value
representation (Figure 5). representation (see Figure 5). For any other length, Recommended
Cache Times are encoded as described in Section 3.4.2 of [RFC8609].
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 /
/ /
+---------------+---------------+---------------+---------------+
Figure 5: Changes to the definition of the Recommended Cache Time Figure 5: Changes to the definition of the Recommended Cache Time
TLV. TLV.
The packet processing is adapted to calculate an absolute time from The packet processing is adapted to calculate an absolute time from
the relative time code based on the absolute reception time. On the relative time code based on the absolute reception time. On
transmission, a new relative time code is calculated based on the transmission, a new relative time code is calculated based on the
current system time. current system time.
6. IANA Considerations 6. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
7. Security Considerations 7. Security Considerations
This document makes no semantic changes to [RFC8569], nor to any of This document makes no semantic changes to [RFC8569], nor to any of
the security properties of the message encodings of [RFC8609], and the security properties of the message encodings described in
hence has the same security considerations as those two existing [RFC8609]; hence, it has the same security considerations as those
documents. Additional considerations need to be made in networks two documents. Careful consideration is needed for networks that
that deploy forwarders with support (updated forwarder) and without deploy forwarders with support (updated forwarder) and without
support (legacy forwarder) for this compact time representation: support (legacy forwarder) for this compact time representation:
Interest Lifetime: A legacy forwarder interprets a time code as an Interest Lifetime: A legacy forwarder interprets a time code as an
Interest lifetime between 0 and 255 milliseconds. This may lead Interest Lifetime between 0 and 255 milliseconds. This may lead
to a degradation of network performance, since Pending Interest to a degradation of network performance, since Pending Interest
Table (PIT) entries timeout quicker than expected. An updated Table (PIT) entries timeout quicker than expected. An updated
forwarder interprets short lifetimes set by a legacy forwarder as forwarder interprets short lifetimes set by a legacy forwarder as
time codes, thus configuring timeouts of up to 4 years. This time codes, thus configuring timeouts of up to 4 years. This
leads to an inefficient occupation of state space. leads to an inefficient occupation of state space.
Recommended Cache Time: A legacy forwarder considers a Recommended Recommended Cache Time: A legacy forwarder considers a Recommended
Cache Time with length 1 as a structural or syntactical error and Cache Time with length 1 as a structural or syntactical error and
it SHOULD discard the packet (section 10.3.9 [RFC8569]). it SHOULD discard the packet (Section 10.3.9 of [RFC8569]).
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.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
skipping to change at page 10, line 21 skipping to change at line 414
Networking (CCNx) Messages in TLV Format", RFC 8609, Networking (CCNx) Messages in TLV Format", RFC 8609,
DOI 10.17487/RFC8609, July 2019, DOI 10.17487/RFC8609, July 2019,
<https://www.rfc-editor.org/info/rfc8609>. <https://www.rfc-editor.org/info/rfc8609>.
8.2. Informative References 8.2. Informative References
[ICNLOWPAN] [ICNLOWPAN]
Gündoğan, C., Kietzmann, P., Schmidt, T., and M. Wählisch, Gündoğan, C., Kietzmann, P., Schmidt, T., and M. Wählisch,
"Designing a LoWPAN convergence layer for the Information "Designing a LoWPAN convergence layer for the Information
Centric Internet of Things", Computer Communications, Vol. Centric Internet of Things", Computer Communications, Vol.
164, No. 1, p. 114–123, Elsevier, December 2020, 164, No. 1, p. 114-123, Elsevier, December 2020,
<https://doi.org/10.1016/j.comcom.2020.10.002>. <https://doi.org/10.1016/j.comcom.2020.10.002>.
[IEEE.754.2019] [IEEE.754.2019]
Institute of Electrical and Electronics Engineers, C/MSC - IEEE, "Standard for Floating-Point Arithmetic", IEEE
Microprocessor Standards Committee, "Standard for Std 754-2019, DOI 10.1109/IEEESTD.2019.8766229, June 2019,
Floating-Point Arithmetic", June 2019,
<https://standards.ieee.org/content/ieee-standards/en/ <https://standards.ieee.org/content/ieee-standards/en/
standard/754-2019.html>. standard/754-2019.html>.
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value
Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
DOI 10.17487/RFC5497, March 2009, DOI 10.17487/RFC5497, March 2009,
<https://www.rfc-editor.org/info/rfc5497>. <https://www.rfc-editor.org/info/rfc5497>.
[RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I.,
Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
skipping to change at page 11, line 32 skipping to change at line 473
| 0xF8 | 67108864.0000000 | | 0xF8 | 67108864.0000000 |
+-----------+----------------------+ +-----------+----------------------+
| 0xFF | 125829120.0000000 | | 0xFF | 125829120.0000000 |
+-----------+----------------------+ +-----------+----------------------+
Table 1: Test Vectors Table 1: Test Vectors
Appendix B. Efficient Time Value Approximation Appendix B. Efficient Time Value Approximation
A forwarder frequently converts compact time into milliseconds to A forwarder frequently converts compact time into milliseconds to
compare Interest lifetimes and the duration of cache entries. On compare Interest Lifetimes and the duration of cache entries. On
many architectures, multiplication and division perform slower than many architectures, multiplication and division perform slower than
addition, subtraction, and bit shifts. The following equations addition, subtraction, and bit shifts. The following equations
approximate the formulas in Section 4, and scale from seconds into approximate the formulas in Section 4, and scale from seconds into
the milliseconds range by applying a factor of 2^10 instead of 10^3. 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%.
b == 0: 2^10 * a * 2^-3 * 2^1 * 2^-5 b == 0: 2^10 * a * 2^-3 * 2^1 * 2^-5
= a << 3 = a << 3
b > 0: (2^10 + a * 2^-3 * 2^10) * 2^b * 2^-5 b > 0: (2^10 + a * 2^-3 * 2^10) * 2^b * 2^-5
= (1 << 5 + a << 2) << b = (1 << 5 + a << 2) << b
Acknowledgments Acknowledgments
We would like to thank the active members of the ICNRG research group We would like to thank the active members of the ICNRG research group
for constructive thoughts. In particular, we thank Marc Mosko and for their constructive thoughts. In particular, we thank Marc Mosko
Ken Calvert for their valuable feedback on the encoding scheme and and Ken Calvert for their valuable feedback on the encoding scheme
the protocol integration. Special thanks also to Carsten Bormann for and protocol integration. Special thanks also go to Carsten Bormann
his constructive in-depth comments during the IRSG review. for his constructive in-depth comments during the IRSG review.
Authors' Addresses Authors' Addresses
Cenk Gündoğan Cenk Gündoğan
Huawei Technologies Duesseldorf GmbH Huawei Technologies Duesseldorf GmbH
Riesstrasse 25 Riesstrasse 25
D-80992 Munich D-80992 Munich
Germany Germany
Email: cenk.gundogan@huawei.com Email: cenk.gundogan@huawei.com
 End of changes. 50 change blocks. 
178 lines changed or deleted 169 lines changed or added

This html diff was produced by rfcdiff 1.48.