Status of This Memo

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.¶

This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related 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.¶

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 (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

CCNx is well suited for Internet of Things (IoT) applications [RFC7927]. Low-Power Wireless Personal Area Network (LoWPAN) adaptation layers (e.g., [RFC9139]) 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 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 [ICNLOWPAN], this document discusses the various cases of time values, proposes a compact encoding for delta times, and updates [RFC8609] to utilize this encoding format in CCNx messages.¶

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.¶

4. A Compact Time Representation with Logarithmic Range

This document uses the compact time representation described in "Information-Centric Networking (ICN) Adaptation to Low-Power Wireless Personal Area Networks (LoWPANs)" (see Section 7 of [RFC9139]) that was inspired by [RFC5497] and [IEEE.754.2019]. Its logarithmic encoding supports a representation ranging from milliseconds to years. Figure 1 depicts the logarithmic nature of this time representation.¶

|| |  |   |    |     |      |       |        |         |          |
+-----------------------------------------------------------------+
milliseconds                                                  years

Time codes encode exponent and mantissa values in a single byte. In contrast to the representation in [IEEE.754.2019], time codes only encode non-negative numbers and hence do not include a separate bit to indicate integer signedness. Figure 2 shows the configuration of a time code: an exponent width of 5 bits, and a mantissa width of 3 bits.¶

<---          one byte wide          --->
+----+----+----+----+----+----+----+----+
|      exponent (b)      | mantissa (a) |
+----+----+----+----+----+----+----+----+
  0    1    2    3    4    5    6    7

The base unit for time values is seconds. A time value is calculated using the following formula (adopted from [RFC5497] and [RFC9139]), where (a) represents the mantissa, (b) the exponent, and (C) a constant factor set to C := 1/32.¶

Subnormal (b == 0):

(0 + a/8) * 2 * C¶

Normalized (b > 0):

(1 + a/8) * 2^b * C¶

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, ...]. Appendix A includes test vectors to illustrate the logarithmic range.¶

An example algorithm to encode a time value into the corresponding exponent and mantissa is given as pseudocode in Figure 3. Not all time values can be represented by a time code. For these instances, a time code is produced that represents a time value closest to and smaller than the initial time value input.¶

 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)

For example, no specific time code for 0.063 exists. However, this algorithm maps to the closest valid time code that is smaller than 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

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:¶

• Both CCNx RFCs ([RFC8569] and [RFC8609]) are Experimental and not Standards Track; hence, expectations for forward and backward compatibility are not as stringent. "Flag day" upgrades of deployed CCNx networks, while inconvenient, are still feasible.¶

• 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.¶

• 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.¶

• The alternative of assigning new TLV registry values does not substantially mitigate the interoperability problems anyway.¶

                     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_CACHETIME          |           Length = 1          |
+---------------+---------------+---------------+---------------+
| COMPACT_TIME  |
+---------------+

6. IANA Considerations

This document has no IANA actions.¶

7. Security Considerations

This document makes no semantic changes to [RFC8569], nor to any of the security properties of the message encodings described in [RFC8609]; hence, it has the same security considerations as those two documents. Careful consideration is needed for networks that deploy forwarders with support (updated forwarder) and without support (legacy forwarder) for this compact time representation:¶

Interest Lifetime:

A legacy forwarder interprets a time code as an Interest Lifetime 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.¶

Recommended Cache Time:

A legacy forwarder considers a Recommended Cache Time with length 1 as a structural or syntactical error and it SHOULD discard the packet (Section 10.3.9 of [RFC8569]). Otherwise, a legacy forwarder interprets time codes as absolute time values far in the past, which impacts cache utilization.¶

Appendix A. Test Vectors

The test vectors in Table 1 show sample time codes and their corresponding time values according to the algorithm outlined in Section 4.¶

Appendix B. Efficient Time Value Approximation

A forwarder frequently converts compact time into milliseconds to compare Interest Lifetimes 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 Section 4, 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%.¶

b == 0:

2^10 * a * 2^-3 * 2^1 * 2^-5
= a << 3¶

b > 0:

(2^10 + a * 2^-3 * 2^10) * 2^b * 2^-5
= (1 << 5 + a << 2) << b¶

Acknowledgments

We would like to thank the active members of ICNRG for their constructive thoughts. In particular, we thank Marc Mosko and Ken Calvert for their valuable feedback on the encoding scheme and protocol integration. Special thanks also go to Carsten Bormann for his constructive in-depth comments during the IRSG review.¶

Authors' Addresses